2.7 - 문서를 작성하는 대신 테스트를 만드세요2.8 - 모의 객체 대신 페이크 객체를 사용하세요2.9 - 인터페이스를 짧게 유지하고 스마트를 사용하세요스마트 클래스 예제.. 뭐가 있지..?
2.7 - 문서를 작성하는 대신 테스트를 만드세요
- 코드를 문서화 하기 전에 코드를 깔끔하게 짜는 거에 우선순위를 둬라
- 클래스 이름, 메서드 이름, 설계 자체가 엉망일 경우 문서화가 필수 지만 이런 상황때문에 더욱 코드를 깔끔하게 작성하자.
- 이 부분도 유지보수성을 강조하는 것 같았다.
- 항상 코드를 작성할 때 코드를 읽게 될 사람이 비즈니스 도메인, 프로그래밍 언어, 디자인 패턴, 알고리즘을 거의 이해 못하는 주니어 프로그래머라고 가정해야 한다. (나 아닌가..?)
- 이상적인 코드는 스스로를 설명하기 때문에 어떠한 추가 문서도 필요하지 않는다.
- 클래스가 어떤 일을 하고 메서드가 어떤 목적으로 행위하는지를 신경쓰고 작성하자.
- 깔끔하게 코드를 작성한다는 말에는 “단위테스트"도 함께 만든다는 의미가 포함되어 있다고 한다.
- 결국 깔끔하고 유지보수 가능한 단위 테스트를 추가하면 클래스를 더욱 깔끔하게 만들 수 있고 유지보수성을 강조하고 있는데 TDD 방식의 개발을 이야기 하는 것 같았다.
2.8 - 모의 객체 대신 페이크 객체를 사용하세요
- 페이크 객체를 사용하면 단위테스트가 깨지지 않고 테스트가 가능하다.
- 모킹대신 페이크 객체를 사용하도록 하자.
- 모킹은 클래스 구현과 내부 세부사항을 테스트와 결합시킨다.
- 페이크 클래스를 사용하면 테스트를 유지보수 좋게 만들 수 있다.
- 클래스 사이의 의사소통 방식에 대해서는 신경 쓸 필요가 없다.
- 페이크 클래스의 또하나의 장점은 인터페이스의 설계에 관해 더 깊이 고민하도록 해준다.
- 페이크 클래스를 만들다보면 필연적으로 인터페이스의 작성자 뿐만 아니라 사용자 관점에서도 고민하게 되며 인터페이스를 다른 각도에서 바라보고 테스트 리소스를 사용해서 사용자와 동일한 기능을 구현하게 된다.
2.9 - 인터페이스를 짧게 유지하고 스마트를 사용하세요
- 올바르게 설계된 견고하고, 응집도가 높은 클래스는 적은 수의 public 메서드만 포함한다.
- 클래스를 작게 유지하는것이 중요한 만큼 인터페이스도 작게 유지하는것 또한 아주 중요하다.
- 클래스가 다수의 인터페이스를 구현하기 때문이다.
- 인터페이스가 너무 많은것을 요구한다면 설계 관점에서는 좋지 못하다 그 이유는 단일 책임 원칙을 위반하도록 부추기며 응집도가 낮은 클래스를 만들게 된다.
- 스마트 클래스를 사용하면 인터페이스를 짧게 만들고 스마트 클래스를 인터페이스와 함께 배포함으로써 공통 기능을 추출하고 코드 중복을 피할 수 있다.
- 데코레이터 방법과 유사하다. 차이점으로 데코레이터는 이미 존재하는 메서드를 더 강력하게 만든다.
interface Exchange { float rate(String origin, String target); final class Fast implements Exchange { private final Exchange origin; @Override public float rate(String source, String target) { final float rate; if (source.equals(target)) { rate = 1.0f; } else { rate = this.origin.rate(source, target); } return rate; } public float toUsd(String source) { return this.origin.rate(source, "USD"); } } }