[TDD] 28~32장
28장 초록 막대 패턴
가짜로 구현하기(진짜로 만들기 전까지만)
실패하는 테스트를 만든 후 첫 번째 구현은 상수를 반환하게 하라. 일단 테스트가 통과하면 단계적으로 상수를 변수를 사용하는 수식으로 변형한다.
삼각측량
예가 2개 이상일 때에만 추상화를 하면 최대한 보수적으로 추상화 과정을 테스트로 만들어 낼 수 있다. 어떤 계산을 어떻게 해야 올바르게 추상화할 것인지에 대해 정말 감잡기 어려울 때에만 삼각 측량을 쓰며, 그 외의 경우에는 명백한 구현이나 가짜로 구현하기에 의존하는 것이 좋다.
명백한 구현
‘제대로 동작하는’을 푸는 동시에 ‘깨끗한 코드’를 해결하려는 것은 한번에 하기에는 너무 많은 일일 수 있다. 그렇다면 우선 ‘제대로 동작하는’ 으로 되돌아가 그걸 해결하고, 그 후에 ‘깨끗한 코드’를 느긋하게 해결하자.
29장 xUnit 패턴
단언 (assertion)
테스트가 잘 동작하는지 확인은 boolean수식을 작성해 프로그램이 자동으로 코드가 동작하는지에 대한 판단을 수행하도록 하자
30장 디자인 패턴
값 객체
내가 가진 객체를 다른 사람에게 빌려줬는데, 나도 모르는 사이에 다른 사람이 그 객체의 데이터를 변경하였을 때의 해결방법은?
- 현재 가지고 있는 객체에 대한 참조를 외부에게 절대 알리지 않는 법. 그대신 복사본만 제공한다. 이 방법의 단점은 수행시간이나 메모리 측면에서 효울적이지 않을 수 있다. 또한 공유 객체의 상태 변화를 공유하고 싶은 경우에는 사용할 수 없다. (getter, setter)
- 옵저버 패턴. 의존하는 객체에 자기를 등록해 놓고, 객체의 상태가 변하면 통지를 받는다. 옵저버 패턴은 제어 흐름을 이해하기 어렵게 만들 수 있고, 의존성을 설정하고 제거하기 위한 로직이 지저분해질 수 있다.
- ‘시간의 흐름에 따라 변하는 상태’를 제거한다. static final로 선언해버려!
템플릿 메서드
상위 클래스에서는 다른 메서드를 호출하는 내용으로만 이루어진 메서드를 만들고, 하위 클래스에서는 이 각각의 메서드를 서로 다른 방식으로 구현하는 것. 템플릿 메서드는 초기 설계에 의해 얻어지는 것 보다는 경험에 의해 발견되는 것이 좋다.
팩토리 메서드
객체만 생성하는 메서드. 메서드가 생성자처럼 생기지 않았지만 객체를 만든다는 사실을 기억하고 있어야 하기 때문에 불편하다.
static Dollar dollar(int amount){
return new Dollar(amount);
}31장 리팩토링
차이점 일치시키기
비슷해 보이는 두 코드 조각을 합치려면 두 코드가 단계적으로 닮아가게끔 수정한다. 이 둘이 완전히 동일해지면 둘을 합친다.
인터페이스 추출하기
공통된 오퍼레이션을 담고 있는 인터페이스를 만들자
메서드 옮기기
메서드를 원래 있어야 할 장소로 옮기려면 어울리는 클래스에 메서드를 추가해주고 그것을 호출하면 된다. (p.302)
장점
- 코드에 대한 깊은 이해가 없더라도 언제 이 리팩토링이 필요한지 쉽게 알아낼 수 있다. 다른 객체에 대한 두 개 이상의 메시지를 보내는 코드를 볼 때마다 메서드 옮기기를 해주면 된다.
- 리팩토링 절차가 빠르고 안전하다.
32 TDD 마스터하기
는 그냥 가볍게 읽고 넘어가면 될거 같네용
