[테스트 주도 개발로 배우는 객체지향 설계와 실천] 7장 객체 지향 설계의 달성

7장 객체 지향 설계의 달성

테스트 작성은 설계에 어떻게 도움이 되는가?

어떻게를 고려하기 전에 달성하고자 하는 바가 무엇인지를 기술하게 함
단위 테스트를 이해 가능한 상태로 유지하기 위해 단위 테스트의 범위를 제한함
의존성의 위치(의존성이 있는 객체와의 관계(?))를 알게 함
- 단위 테스트를 위한 객체를 만들려면 해당 객체의 의존성을 전달해야 함

값 타입을 사용하는데 이점은 무엇인가?

구체적인 타입의 사용으로 혼동을 피할 수 있다.
값의 개념을 나타내는 타입을 만들어 두면 행위를 추가하기에 적절한 장소가 되어 좀 더 객체 지향적인 접근법을 사용하는데 도움을 준다.

값 타입 객체는 어떻게 만들어지는가?

분해 : 큰 객체를 협력 객체의 그룹으로 나누기
- 복잡한 객체를 응집력 있는 기능 단위로 작은 협력 객체로 만들어 독립적인 단위 테스트를 작성하게 함
- 어떤 객체가 손쉽게 테스트할 수 없을 정도로 몸집이 크거나 테스트가 실패한 이유를 해석하기 어렵다면 해당 객체를 분해한다.
파생 : 객체가 필요로 하는 신규 서비스 정의와 해당 서비스를 제공하기 위한 새 객체 추가
- 객체에 행위를 추가하고 설계 원칙을 따르더라도 어떤 새로운 기능은 원칙에 속하지 않을 수도 있다.
-> 인터페이스를 만들어 객체 관점에서 필요한 서비스를 정의한다.
- 주문형 설계 : 어떤 클래스에서 제공 해야 할 기능을 밀어내지 않고 클라이언트의 요구 사항으로부터 인터페이스와 해당 인터페이스의 구현체를 현실로 끄집어내는 것
포장 : 관련 객체를 포함 객체로 감추기
- 객체의 테스트가 복잡해서 테스트를 준비할 수 없는 경우
- 코드를 적절한 상태에 두기엔 유동적인 부분이 많을 경우
- 전체는 부분의 합보다 단순해야 한다 규칙의 응용
- 함께 동작하는 관련 객체의 집합이 있을 경우 그것들을 하나로 포함하는 객체로 포장할 수 있다.
- 기존 집합의 복잡성을 추상화로 감춤
- 높은 수준에서 프로그래밍할 수 있다.
- 암시적인 개념을 구체적으로 만드는 과정의 좋은 효과
- 도메인을 좀 더 잘 이해하는 데 도움이 되는 이름을 개념에 부여
- 개념의 경계를 확인할 수 있음 -> 의존성의 범위를 명확하게 한정할 수 있음
- 단위 테스트를 정확하게 수행할 수 있음.

인터페이스는 언제 리팩토링해야 하는가?

인터페이스 간의 유사점과 차이점에 신경이 쓰이기 시작할 때 -> 비슷한 애들
- 인터페이스가 단일 개념을 표현하고 있으며, 병합될 수 있는지 살펴야 함
인터페이스를 구현하기 시작할 때

구현 계층, 선언 계층은 무엇인가? 왜 분리하는가?

구현 계층 : 이 계층에 속하는 객체가 이벤트에 어떻게 반응하는가
- 코드가 그것을 하려는 일을 어떻게 하는지 기술
선언적 계층 : 작은 편의성 메서드와 문법을 이용해 각 부분의 용도를 기술
- 코드가 하려는 일이 무엇인지 기술

스터디

무엇 때문에 프로젝트가 난항을 겪고 있는가?