객체 지향의 사실과 오해

인상싶은 내용

31쪽

외부의 도움을 무시한 채 모든 것을 스스로 처리하려고 하는 전지전능한 객체(god object)는 내부적인 복잡도에 의해 자멸하고 만다.

68쪽

소프트웨어 안에 구축되는 객체지향 세계는 현실을 모방한 것이 아니다. 현실의 모습을 조금 참조할 뿐 궁극적인 목적은 현실과 전혀 다른 새로운 세계를 창조하는 것이다. 또한 객체지향 세계는 현실의 추상화가 아니다. 오히려 객체지향 세계의 거리는 현실 속의 객체보다 더 많은 특징과 능력을 보유한 객체들로 넘쳐난다.

131쪽

이름에서 풍기는 늬앙스와는 달리 테스트-주도 개발은 테스트 작성이 아니다. 테스트는 단지 테스트-주도 개발을 통해 얻을 수 있는 별도의 보너스 같은 것이며, 실제 목적은 구체적인 코드를 작성해나가면서 역할, 책임, 협력을 식별하고 식별된 역할, 책임, 협력이 적합한지를 피드백 받는 것이다.

137쪽

테스트 주도 개발은 객체지향에 대한 깊이 있는 지식을 요구한다. 테스트를 작성하기 위해 객체의 메서드를 호출하고 반환값을 검증하는 것은 순간적으로 객체가 수행해야하는 책임에 관해 생각한 것이다. 테스트에 필요한 간접 입력 값을 제공하기 위해 스텁(stub)을 추가하거나 간접 출력 값을 검증하기 위해 목 개체(mock object)를 사용하는 객체와 협력해야 하는 협력자에 관해 고민한 결과를 코드로 표현한 것이다

161쪽

메시지를 전송하는 객체의 관점에서 자신이 전송하는 메시지를 수신할 수 있다면 협력하는 객체의 종류가 무엇인지는 중요하지 않다. 중요한 것은 메시지를 쉰하는 객체가 메시지의 의미를 이해하고 메시지를 전송한 객체가 의도한 대로 요청을 처리할 수 있는지의 여부다. … 재사용 가능하고 확장 가능한 객체지향 설계를 구축하기 위한 핵심적인 도구인 다형성은 개별 객체가 아니라 객체들이 주고 받는 메시지에 초점을 맞출 때 비로소 그 진가를 발휘하게 된다.

182쪽

설계라는 행위를 중요하게 만드는 것은 변경에 대한 필요성이다. 안타깝게도 변경을 피할 수 있는 방법은 없기 때문에 좋은 설계에 대한 압력 역시 피할수 없다. … 미래에 대비하는 가장 좋은 방법은 변경을 예측하는 것이 아니라 변경을 수용할 수 있는 선택의 여지를 설계에 마련해 놓는 것이다… 좋은 설계는 나중에라도 변경할 수 있는 여지를 남겨 좋는 설계다.

196쪽

유즈케이스는 단지 기능적 요구사항을 사용자의 목표라는 문맥을 중심으로 묶어 놓기 위한 정리기법일 뿐이다.

유즈케이스 안에는 영감을 넣을 수 있는 약간의 힌트만이 들어 있을 뿐이다.