책임 중심의 설계

"이 객체가 수행해야 하는 책임은 무엇인가"를 결정한 후에 "이 책임을 수행하는데 필요한 데이터는 무엇인가"를 결정한다.

책임은 객체의 입장이 아니라 객체가 참여하는 협력에 적합해야 한다.

메시지가 클라이언트의 의도를 표현한다.

• 클라이언트는 단지 임의의 객체가 메시지를 수신할 것이라는 사실을 믿고 자신의 의도를 표현한 메시지를 전송할 뿐이다.

• 그리고 메시지를 수신하기로 결정된 객체는 메시지를 처리할 '책임'을 할당 받게 된다.

여러 설계가 있을 경우 높은 응집도와 낮은 결합도를 얻을 수 있는 설계가 있다면 그 설계를 선택해야 한다.

클래스 개선

• 인스턴스 변수가 초기화되는 시점을 살펴보는 것이다.
  • 응집도가 높은 클래스는 인스턴스를 생성할 때 모든 속성을 함께 초기화한다.
  • 반면 응집도가 낮은 클래스는 객체의 속성 중 일부만 초기화하고 일부는 초기화되지 않은 상태로 남겨진다.
  • 따라서 함께 초기화되는 속성을 기준으로 코드를 분리해야 한다.
• 메서드들이 인스턴스 변수를 사용하는 방식을 살펴보는 것이다.
  • 모든 메서드가 객체의 모든 속성을 사용한다면 클래스의 응집도는 높다고 볼 수 있다.
  • 반면 메서드들이 사용하는 속성에 따라 그룹이 나뉜다면 클래스의 응집도가 낮다고 볼 수 있다.
  • 속성 그룹과 해당 그룹에 접근하는 메서드 그룹을 기준으로 코드를 분리해야 한다.

클래스 응집도 판단하기

1. 클래스가 하나 이상의 이유로 변경돼야 한다면 응집도가 낮은 것이다. 변경의 이유를 기준으로 클래스를 분리하자.
2. 클래스의 인스턴스를 초기화하는 시점에 경우에 따라 서로 다른 속성들을 초기화하고 있다면 응집도가 낮은 것이다. 초기화되는 속성의 그룹을 기준으로 클래스를 분리하자.
3. 메서드 그룹이 속성 그룹을 사용하는지 여부로 나뉜다면 응집도가 낮은 것이다. 이들 그룹을 기준으로 클래스를 분리하자.

POLYMORPHISM(다형성) 패턴

polymorphism 패턴은 객체의 타입을 검사해서 타입에 따라 여러 대안들을 수행하는 조건적인 논리를 사용하지 말라고 경고한다. (if ~ else 또는 switch ~ case 등의 조건 논리)
대신 다형성을 이용해 새로운 변화를 다루기 쉽게 확장하자.

변경과 유연성

현재 설계에서 할인 정책코드가 상속을 사용했다면?
실행 중에 영화의 할인 정책을 변경하기 위해서는 새로운 인스턴스를 생성한 후 필요한 정보를 복사해야 한다.
또한 변경 전후의 인스턴스가 개념적으로는 동일한 객체를 가리키지만 물리적으로 서로 다른 객체이기 때문에 식별자의 관점에서 혼란스러울 수 있다.

즉 새로운 할인 정책이 추가될 때마다 인스턴스를 생성하고, 상태를 복사하고, 식별자를 관리하는 코드를 추가하는 일은 번거로울뿐만 아니라 오류가 발생하기도 쉽다.

해결 방법은 상속 대신 합성을 사용하는 것이다.

긴 메서드는 다양한 측면에서 코드의 유지 보수에 부정적인 영향을 미친다. (강한 결합, 낮은 응집도)

• 어떤 일을 수행하는지 한눈에 파악하기 어렵기 때문에 코드를 전체적으로 이해하는 데 너무 많은 시간이 걸린다.
• 하나의 메서드 안에서 너무 많은 작업을 처리하기 때문에 변경이 필요할 때 수정해야 할 부분을 찾기 어렵다.
• 메서드 내부의 일부 로직만 수정하더라도 메서드의 나머지 부분에서 버그가 발생할 확률이 높다.
• 로직의 일부만 재사용하는 것이 불가능하다.
• 코드를 재사용하는 유일한 방법은 원하는 코드를 복사해서 붙여넣는 것뿐이므로 코드 중복을 초래하기 쉽다.

이런 경우 로직의 흐름을 이해하기 위해 주석이 필요한 경우가 대부분이다. 주석을 추가하는 대신 메서드를 작게 분해해서 각 메서드의 응집도를 높여라.

1. 메서드가 잘게 나눠져 있을 때 다른 메서드에서 사용될 확률이 높다.
2. 고수준의 메서드를 볼 때 일련의 주석을 읽는 것 같은 느낌이 들게 할 수 있다. 또한 메서드가 잘게 나눠져 있을 때 오버라이딩하는 것도 훨씬 쉽다.

작은 메서들로 분해하면 전체적인 흐름을 이해하기도 쉽고 단 하나의 이유에 의해서만 변경된다.

객체를 자율적으로 만들자

자신이 소유하고 있는 데이터를 자기 스스로 처리하도록 만드느 것이 자율적인 객체를 만드는 지름길이다.
데이터를 사용하는 메서드를 데이터를 가진 클래스로 이동시키고 나면 캡슐화와 높은 응집도, 낮은 결합도를 가지는 설계를 얻게 된다.