객체지향의 사실과 오해 4장 정리

 

본 글은 스터디 내에서 객체지향의 사실과 오해 - 역할, 책임, 협력 관점에서 본 객체지향을 읽고 정리한 글입니다.

---

 

객체지향 설계의 전체적인 품질을 결정하는 것은 개별 객체의 품질이 아니라 여러 객체들이 모여 이뤄내는 협력의 품질이다.

 

협력 

협력은 다수의 연쇄적인 요청과 응답의 흐름으로 구성된다

 

책임

어떤 객체가 어떤 요청에 대해 대답해 줄 수 있거나 적절한 행동을 할 의무가 있는 경우 객체가 책임을 가진다고 말한다.

 

책임의 분류

객체의 책임은 객체가 무엇을 알고 있는가와 무엇을 할 수 있는가로 구성된다.

 

메시지 전송 : 객체가 다른 객체에게 주어진 책임을 수행하도록 요청을 보내는 것

책임이란 객체가 협력하기 위해 수행하는 행위를 상위 수준에서 개략적으로 서술 -> 

책임 결정후 실제 메시지로 변환할 때는 책임이 여러 메시지로 분할됨.

 

역할: 역할(role)을 사용하면 세 가지 협력을 모두 포괄할 수 있는 하나의 협력으로 추상화할 수 있다.

동일한 역할을 수행하는 객체들이 동일한 메시지를 수신할 수 있기 때문에 역할 중요.

단순성, 유연성, 재사용성을 뒷받침함.

 

협력의 추상화:

객체의 타입과 역할 사이에는 일반화/특수화 관계가 성립함.

 

객체의 모양을 결정하는 협력:

클래스와 데이터는 협력과 책임의 집합이 결정된 후에야 무대 위에 등장할 수 있다.

객체가 가져야 하는 상태와 행위에 대해 고민하기 전에 그 객체가 참여할 문맥인 협력을 정의하라.

 

책임-주도-설계(Responsibility-Driven Design) : 협력에 필요한 책임들을 식별하고, 적합한 객체에게 책임을 할당하는 방식으로 애플리케이션 설계

 

->  시스템의 책임을 객체의 책임으로 변환하고, 각 객체가 책임을 수행하는 중에 필요한 정보나 서비스를 제공해줄 협력자를 찾아, 책임을 할당하는 순차적인 방식으로 구축

 

디자인 패턴(Design Pattern): 전문가들이 반복적으로 사용하는 해결 방법을 정의해 놓은 설계 템플릿의 모음

-> 책임-주도 설계의 결과를 표현

 

COMPOSITE 패턴: 전체와 부분을 하나의 단위로 추상화해야 하는 경우에 사용할 수 있는 패턴

 

테스트-주도 개발(Test-Driven Development): 테스트를 먼저 작성하고 테스트를 통과하는 구체적인 코드를 추가하면서 애플리케이션을 완성해가는 방식

-> 테스트가 아니라 설계를 위한 기법 (*핵심은 테스트 작성이 아니다.)

-> 실제 목적은 구체적 코드를 작성해나가면서 역할, 책임, 협력을 식별하고 적합한지 피드백

기본 흐름: 실패하는 테스트를 작성하고, 테스트를 통과하는 가장 간단한 코드를 작성한 후 리팩터링을 통해 중복 제거

TDD  통해 작동하는 깔끔한 코드(clean code that works)를 얻을 수 있음.

 

협력 안에서 객체의 역할과 책임이 무엇이고, 클래스와 같은 장치로 구현되는 방식에 대한 감각을 갖춰야만 효과적인 테스트 작성 가능.

 

테스트-주도 개발은 테스트를 작성하기 위해 객체의 메서드를 호출하고, 반환 값을 검증하는 것은 객체가 수행해야 하는 책임에 관해 생각한 것

테스트에 필요한 간접 입력 값을 제공하기 위해 스텁(stub)을 추가하거나 간접 출력 값을 검증하기 위해 목 객체(mock object)를 사용하는 것은 객체와 협력해야 하는 협력자에 관해 고민한 결과를 코드로 표현 한 것