객체지향의 사실과 오해 - 4장(역할, 책임, 협력)

요약: "개별적인 객체가 아닌 객체들 간 협력에 집중하자"

 

 

책임을 가진다는 것?

요청에 응답해야 한다면 책임을 가진 것이다. "커피를 달라는"요청에 응답해야하는 캐셔는 "커피를 제공해야하는" 책임을 가진 것이다.

또, "커피를 만들어달라는" 요청에 응답해야하는 바리스타는 "커피를 만들어야 하는" 책임이 있는 것이다.
책임은 객체에 의해 정의되는 응집도 있는 행위의 집합이다.

 

하는 것과 아는 것(크레이크 라만)
책임은 하는 것과 아는 것으로 분류할 수 있다.
하는 것은 객체를 생성하거나 특정 행위를 하는 것이 될 수도 있고, 다른 객체가 무엇을 하도록 할 수도 있다.
아는 것은 개인적인 정보에 대해 알 수도, 관련 객체에 대해 알 수도, 자신이 유도하거나 계산할 수 있는 것을 알 수도 있다.

책임은 객체의 공용 인터페이스를 구성한다. 아는 것을 제공할 수도 있고 어떤 서비스를 제공 해줄 수 있다.

 

 

설계에서 중요한 것은명확한 책임을적절한 객체에게 주는 것이다.

 

역할

이때, 협력 내에서 책임을 수행하는 객체가 대체될 수 있다면?
역할은 책임의 집합이다. 공용 인터페이스를 통해 단순성(복잡한 구현 내용은 숨긴다.), 유연성(구현체를 언제든지 갈아끼울 수 있다.),

재사용성(어디서든 다시 사용될 수 있다)을 획득할 수 있다.

 

역할의 대체 가능성은 행위 호환성을, 행위 호환성은 동일한 책임의 수행을 의미한다

역할이 대체 가능하다?
역할을 수행할 수 있는 객체라면 누구든 올 수 있다라는 뜻!

 

인상깊었던 말

먼저 (1)협력을 정의하고 (2)필요한 책임을 결정하고 (3)객체에 책임을 할당하라

 

 

중요한 개념

[책임 주도 설계]
시스템의 책임을 객체의 책임으로 분할하고 협력자를 찾아 협력자에게 또 다른 책임을 할당하며 설계한다.
책임의 흐름으로 설계를 하는 것.

 

[디자인패턴]
ex) Composite Pattern

 

[테스트 주도 설계]
테스트 주도 설계는 개발을 위한 것이 아닌 설계를 위한 것이다.
역할, 책임, 협력의 관점에서 객체를 바라보지 않으면 무의미하다.