[독서] 객체지향의 사실과 오해

책의 핵심 내용 정리

행동이 상태를 결정한다.

초보자들은 먼저 객체에 필요한 상태가 무엇인지를 결정하고 그 상태에 필요한 행동을 결정한다. 상태를 먼저 결정하고 행동을 나중에 결정하는 방법은 설계에 나쁜 영향을 끼친다. 객체가 적합한지를 결정하는 것은 그 객체의 상태가 아니라 행동이다. 애플리케이션 안에서 어떤 행동을 원하느냐가 어떤 객체가 적합한지를 결정한다.

상태를 먼저 결정할 경우

1. 상태를 먼저 결정할 경우 캡슐화가 저해된다. 상태에 초점을 맞출경우 상태가 객체 내부로 깔끔하게 캡슐화되지 못하고 공용 인터페이스에 그대로 노풀될 확률이 높아진다.
2. 객체를 협력자가 아닌 고립된 섬으로 만든다. 상태를 먼저 고려할 경우, 협력이라는 문맥에서 멀리 벗어난 채 객체를 설계함으로써 자연스럽게 협렵에 적합하지 못한 객체를 창조하게 된다.
3. 객체의 재사용성이 저해된다. 상태에 초점을 맞춘 객체는 다양한 협력에 참여하기 어렵기때문에 재사용성이 저하될 수 밖에 없다.

책임-주도-설계(Responsibility-Driven-Design, RDD)

협력안에서 객체의 행동은 객체가 협력에 참여하면서 완수해야하는 책임을 의미한다. 객체지향 설계는 적절한 책임을 적절한 객체에게 할당하면서 메세지를 기반으로 협력하는 객체들의 관계를 발견하는 과정이다. 따라서 어떤 책임이 필요한가를 결정하는 과정이 전체 설계를 주도해야한다. 책임-주도-설계는 책임을 완수하기위해 협력하는 객체들을 이용해 시스템을 설계하는 방법으로, 협력이라는 문맥안에서 객체의 행동을 생각하도록 도움으로써 응집도 높고 재사용 가능한 객체를 만들 수 있게 한다. 

데이터-주도-설계(Data-Driven-Design, DDD)

메세지가 아니라 데이터를 중심으로 객체를 설계하는 방식은 객체의 내부 구조를 객체 정의의 일부로 만들기때문에 객체의 자율성을 저해한다. 객체의 내부 구조는 감춰져야한다. 

'어떻게'가 아니라 '무엇'을

자율적인 책임의 특징은 '어떻게(how)'해야하는가가 아니라 '무엇(what)'을 해야하는가를 설명하는 것이다. '증언'한다라는 책임은 모자 장수가 협력을 위해 '무엇'을 해야하는지는 결정하지만 '어떻게'해야하는지에 대해서는 전혀 언급하지않는다. 증언할 방법은 모자 장수가 자율적으로 선택할 수 있다. 

책임을 자율적으로 만들어라

자율적인 책임은,

1. 자율적인 책임은 협력을 단순하게 만든다.
2. 객체의 외부와 내부를 명확하게 분리한다.
3. 책임을 수행하는 내부적인 방법을 변경하더라도 외부에 영향을 미치지않는다.
4. 협력의 대상을 다양하게 선택할 수 있는 유연성을 제공한다. 
5. 객체가 수행하는 책임이 자율적일수록 객체의 역할을 이해하기 쉬워진다. 

유스케이스(Use case)

사용자의 목표를 달성하기 위해 사용자와 시스템 간에 이뤄지는 상호작용의 흐름을 텍스트로 정리한 것을 유스케이스라고 한다. 유스케이스의 가치는 사용자들의 목표를 중심으로 시스템의 기능적인 요구사항들을 이야기 형식으로 묶을 수 있다는 점이다. "사용자 목표가 유스케이스의 핵심이다. 유스케이스는 공통의 사용자 목표를 통해 강하게 연관된 시나리오의 집합이다.(by Martin Fowler)"

유스케이스는,

1. 사용자와 시스템 간의 상호작용을 보여주는 텍스트다.
2. 하나의 시나리오가 아니라 여러 시나리오들의 집합이다.
3. 단순한 feature 목록과 다르다. feature는 시스템이 수행해야하는 기능의 목록을 단순하게 나열한 것이다. 반면 유스케이스는 이야기를 통해 연관된 기능들을 함께 묶는다. 
4. 사용자 인터페이스와 관련된 세부 정보를 포함하지 말아야 한다.
5. 내부 설계와 관련된 정보를 포함하지 않는다.

유스케이스 예시

유스케이스명: 중도 해지 이자액을 계산한다.

일차 액터: 예금주

주요 성공 시나리오:
 1. 예금주가 정기예금 계좌를 선택한다.
 2. 시스템은 정기예금 계좌 정보를 보여준다.
 3. 예금주가 금일 기준으로 예금을 해지할 경우 지급받을 수 있는 이자 계산을 요청한다.
 4. 시스템은 중도 해지 시 지급받을 수 있는 이자를 계산한 후 결과를 사용자에게 전달한다.
 
 확장:
  3a. 사용자는 해지 일자를 다른 일자로 입력할 수 있다.

인터페이스와 구현을 분리해라(ISP, Interface Segregation Principle)

명세 관점은 클래스의 안정적인 측면을 드러내야한다. 구현 관점은 클래스의 불안정한 측면을 드러내야한다. 명세 관점이 설계를 주도하게하면 설계의 품질이 향상될 수 있다. 캡슐화를 위반해서 구현을 인터페이스 밖으로 노출해서도 안되고 인터페이스와 구현을 명확하게 분리하지 않고 흐릿하게 섞어놓아서도 안된다.