성장을 지속하기 위해 노력하기

미션 해결을 통해 요구사항들의 의미와 프로그래밍의 정수를 최대한 파악하고 음미해본다.

1.. 단순화 되어 있는 문제들의 기능별 변경 가능성(ex - 입출력.. )을 고려하여 정의한다.

1. 변경 가능성이 높은 경우 인터페이스를 사용하고, 그 이외에는 불필요한 복잡도 증가를 고려한다. 2.. 기능을 정의한 인터페이스를 사용하여 프로그래밍 한다.
2. 인터페이스는 최초 설계 단계에서 도출하지 않고, 진행과정에서 발견된 새로운 추상 개념을 통해 점진적으로 도출한다.
3. 변경의 유연함을 보장하기 위해 변경 가능서이 높은 기능에서 추상화를 시작하는 것에 도전한다. 3.. 단위 테스트를 왜 사용하는 것인지, 의미를 음미함으로써 필요성을 깨닫는다.
4. 구현할 코드에 대한 테스트 작성 -> 작성한 테스트를 통과하는 코드를 점진적으로 완성
5. 자연스럽게 아직 완성하기 힘든 구현때문에 테스트 할 수 없는 경우에 도달
6. 테스트 할 수 없는 경우를 별도의 인터페이스로 분리하여 진행
7. 분리된 인터페이스는 테스트 대상이 되는 클래스와 구분되는 책임을 가지게 됨 -> 새로운 책임을 갖는 객체를 도출
8. 새로운 책임을 갖는 객체를 도출
9. OOP 속에서 객체는 각각 알맞은 책임을 할당하고 각 객체가 주고받는 메시지를 정의하는 과정이므로 테스트 주도 개발은 OOP 설계 유도에 좋은 방식임을 알 수 있다. OOP 본질 고민하기
10. 이름 짓기의 의미를 고민한다.
11. 프로그래밍이란 각 객체를 주고받는 함수들의 연산 과정이라고 가정한다.
12. 연산이 되풀이 되는 방법을 간추려 이름을 붙이고, 문제를 해결하는 눈높이에 맞춰진 표현 수단을 곧바로 만들어 쓰기 위해 프로그래밍 언어에 함수를 생성하는 기능이 들어있는 것 아닐까..
13. 되풀이 되는 연산을 요약하여 정의하는 것에 집중하고, 문제 해결과정의 표현력을 최대한 끌어올린다.
14. 간추리고 요약하는 것은 내부적인 해결 방법을 더 명확하고 훤하게 드러낸다는 것을 깨달을 수 있도록 노력한다.
15. 또렷이 계산 방법이 드러나고 쓸모있는 것이 분리되도록 함수를 구현한다.
16. 프로그램의 의미를 고민한다.

• 프로그래밍의 공통 특징은 다음과 같다.

변수엔 이름이 붙을 수 있다.함수의 인자로 쓸 수 있다.함수의 결과로 만들어 질 수 있다.데이터 구조 속에 집어넣을 수 있다..

• 현실 세계의 복잡한 현상을 컴퓨터 계산으로 흉내내어 연산 도구를 만든다.
• 각 도구들을 조립하고 변수와 함수를 요약하여 정의한다.
• 복잡한 현상들의 성질들을 변수로 치환하여 연산하는 과정을 통해 문제 해결에 적용한다.

1. 람다, 스트림을 통해 콘덴트를 1로 줄여본다.
2. 함수가 한가지만 해야 하는 이유, 왜 짧으면서도 한가지만 하기 위해 함수 분리를 많이 해야하는지에 대해 고민한다.
   1. 추상화 수준을 각 하나로 일치 시키기 위해 (한 함수 내 추상화 수준을 섞으면 특정 표현이 근본 개념인지 아니면 세부사항인지 구분하기 어렵다.)
   2. 내려가기 규칙 : 한 함수 다음엔 추상화 수준이 한 단계 낮은 함수 -> 위에서 아래로 ㅡ프로그램을 읽으면 함수 추상화 수준이 한 번에 한 단계씩 낮아진다
   3. 큰 개념을 다음 추상화 수준에서 여러 단계로 나눠 수행하기 위해
   4. 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다.
3. 일급 컬렉션이 필요한 이유에 대해 고민하기
   1. Lotto 클래스를 주의깊게 들여다보기
   2. 이동욱님 블로그 - 클릭하여 학습하기
   3. tecoble - 클릭하여 학습하기
4. JAVA Enum 필요한 이유에 대해 고민하기
   1. 객체간 책임의 분리
      1. 코드레벨에서 많은 것을 검증과 확인이 가능해야 좀 더 유지보수하기가 쉬울 수 있다? -> enum으로 조금이나마 답답함을 해소할 수 있다면?
   2. 약속의 jojoldu님
   3. tecoble
5. 객체지향 체조원칙에 대해 고민하기
   1. 좋은 블로그
   2. 블로그 샤인
6. 단위 테스트 사용해보기
   1. 역시 jojoldu님
   2. 테스트 하기 좋은 코드 시리즈
   3. Junit5 학습기 시리즈
7. static 사용 시 생기는 문제에 대해 고민해보기 2주차 피어리뷰 내용 : 무조건 적인 static 선언 보다는 이를 인스턴스 변수, 인스턴스 메서드만으로 바꿔보시면 좋을 거 같아요. static 사용 시 객체 간 공유 문제ㄹ 공유하여 인스턴스 객체를 활용할 것
8. 꼭 읽어라 꼭! 꼭!! 꼭!!!
9. static 다시 알아보기
10. static vs 인스턴스 의미 파악하기
11. static 사용 시 문제점
12. static을 사용하면 안 되는 이유
13. 관심사를 분리 이유에 대해 고민해보기, 특정한 패턴만이 최선인지까지 고민해보기
    1. 필요한 부분만 쉽게 수정하는 방법 - MVC는 왜 생겨난걸까?
    2. MVC의 본질
    3. 관심사의 분리
       1. 인간의 뇌는 한번에 하나씩밖에 처리하지 못한다.
       2. 인간은 잘 묶여있는 덩어리(Chunk)를 더 잘 기억한다.
       3. 협업과 의사소통은 비싸다
       4. 피자 두 판의 법칙
14. 생성자 주입, this 고민하기
    1. 인스턴스를 생성할 때 지정
    2. 클래스와 동일한 이름의 메소드를 호출하도록 약속되어 있음
    3. 클래스가 인스턴스화 될 때 실행되어야 할 코드를 생성자 안에 정의하는 것을 통해 초기화 가능
    4. 클래스가 인스턴스화 될 때 구분자를 통해 매개변수를 생성자의 인자로 넘겨받는다
    5. 생성자에 지정된 매개변수는 new () 연산자를 통해 해당 클래스의 인스턴스 변수로 대입된다.
    6. 생성자는 static, return 데이터 타입을 지정하지 않는다. 오로지 자신의 클래스 타입만 지정된다.
    7. 생성자 자신의 클래스에서 인스턴스 변수가 지정되지 않으면 아무것도 실행되지 않는다. 그렇기 때문에 this를 사용한다.
    8. this는 클래스 자신의 인스턴스를 가리킨다.
    9. this는 클래스 자신의 인스턴스 변수, = 연산자에 대입되는 변수는 생성자를 통해 주입되는 매개변수
15. 의존성 주입! DI 고민하기
    1. 사용할 객체를 직접 생성할 경우, 클래스에 대한 의존 발생 -> 단일 책임, 개방 폐쇄, 의존관계 역전 원칙 위반
    2. 필요한 객체를 직접 생성하거나 찾지 않고 외부에서 넣어주는 방식으로 해결 (의존성 주입)
    3. __외부에서 사용할 객체를 전달받을 수 있는 생성자를 추가하는 방법을 제공하는 것__을 의미한다.
    4. 4.생성자를 이용해서 의존 객체를 전달받도록 구현하면

생성자와 this를 제대로 아는 것인가?

B 클래스에서 A클래스의 기능 사용 시, new ()연산자에 들어가는 매개변수가 A 클래스의 인스턴스 변수에 대입되는 것 맞을까요?

public class A {

    private 데이터타입 instance;
    private 데이터타입 instance;

    public A (데이터타입 parameter) {

        this.instance = parameter;

    }
public class B {
	private B instance;

	public B ( A parameter ) {
		this.instance = parameter;
	}
}

과연 누가 외부 객체를 초기화 해줄것인가?