역할, 책임, 협력
가장 중요한 것은 책임이다.
객체들이 수행할 책임이 적절하게 할당되지 못한 상황에서는 원활한 협력도 기대할 수 없을 것이다.
역할은 책임의 집합이기 때문에 책임이 적절하지 못하면 역할 역시 협력과 조화를 이루지 못한다.
결국 책임이 객체지향 애플리케이션 전체의 품질을 결정하는 것이다.
- 객체지향 설계의 핵심은 책임이다.
- 책임을 할당하는 작업이 응집도와 결합도 같은 설계 품질과 깊이 연관돼 있다.
설계 트레이드오프
캡슐화
변경될 가능성이 높은 부분을 '구현'이라고 부르고 상대적으로 안정적인 부분을 '인터페이스'라고 부른다는 사실을 기억하자.
캡슐화는 외부에서 알 필요가 없는 부분을 감춤으로써 대상을 단순화하는 추상화의 한 종류다.
오직 설계 과정 동안 캡슐화를 목표로 인식할 때만 좋은 객체지향 설계를 할 수 있다.
설계가 필요한 이유는 요구사항이 변경되기 때문이고,
캡슐화가 중요한 이유는 불안정한 부분과 안정적인 부분을 분리해서 변경의 영향을 최소화할 수 있기 때문이다.
캡슐화는 우리를 좋은 코드로 안내하기 때문에 가장 중요한 제1원리다.
응집도, 결합도
응집도와 결합도는 변경과 관련이 깊다. 이는 캡슐화의 정도가 응집도와 결합도에 영햐을 미친다.
캡슐화를 지키면 모듈 안의 응집도는 높아지고 모듈 사이의 결합도는 낮아진다.
캡슐화 위반
public class Movie {
private Money fee;
public Money getFee() {
return fee;
}
public void setFee(Money fee) {
this.fee = fee;
}
}위 코드는 캡슐화를 잘 지킨걸까? 아니다
getFee 메서드와 setFee 메서드는 Movie 내부에 Money 타입의 fee라는 이름의 인스턴스 변수가 존재한다는 사실을 퍼블릭 인터페이스에 노골적으로 드러낸다.
Movie가 캡슐화의 원칙을 어기게 된 근본적인 원인은 객체가 수행할 책임이 아니라 내부에 저장할 데이터에 초점을 맞췄기 때문이다.
높은 결합도
객체 내부의 구현이 객체의 인터페이스에 드러난다는 것은 클라이언트가 구현에 강하게 결합된다는 것을 의미한다. 강하게 결합되어있으면 한쪽에서 코드 수정 시 다른 쪽에 전부 영향을 미칠 가능성이 높다.
데이터 중심의 설계는 전체 시스템을 하나의 거대한 의존성 덩어리로 만들어 버리기 때문에 어떤 변경이라도 일단 발생하고 나면 시스템 전체가 요동칠 수밖에 없다.
데이터 중심 설계 대신 책임 주도 설계로 항상 고민하자!
SRP(단일 책임 원칙) - 클래스는 단 한 가지의 변경 이유만 가져야 한다.
캡슐화를 지켜라
객체는 자신이 어떤 데이터를 가지고 있는지를 내부에 캡슐화하고 외부에 공개해서는 안된다.
객체는 스스로의 상태를 책임져야 하며 외부에서는 인터페이스에 정의된 메서드를 통해서만 상태에 접근할 수 있어야 한다.
즉 협력이라는 문맥 안에서 메시지를 추상화 시켜 인터페이스 분리 원칙을 지키자!
캡슐화는 변경될 수 있는 어떤 것이라도 감추는 것을 의미한다.
설계에서 변하는 것이 무엇인지 고려하고 변하는 개념을 캡슐화해야 한다.
정리하면 캡슐화란 변하는 어떤 것이든 감추는 것이다. 그게 무엇인지는 상관없다.
스스로 자신의 데이터를 책임지는 객체
상태와 행동을 객체라는 하나의 단위로 묶은 이유는 객체 스스로 자신의 상태를 처리할 수 있게 하기 위해서다.
객체는 단순한 데이터 제공자가 아니다.
객체 내부에 저장되는 데이터보다 객체가 협력에 참여하면서 수행할 책임을 정의하는 오퍼레이션이 더 중요하다!
데이터 중심 설계의 문제점
- 데이터 중심의 설계는 본질적으로 너무 이른 시기에 데이터에 관해 결정하도록 강요한다.
- 데이터 중심의 설계에서는 협력이라는 문맥을 고려하지 않고 객체를 고립시킨 채 오퍼레이션을 결정한다.
즉 객체의 책임을 생각하지 않고 그냥 데이터 중심적으로 설계를 한거다.
데이터는 구현의 일부라는 사실을 명심하자.
우리가 왜 설계를 하는가? 요구사항이 변경되기 때문이지 않는가? 설계 후 구현을 해야하는데 데이터 중심 설계는 무작정 구현을 먼저하는게 문제인거다.
데이터 중심 설계는 객체의 내부 구현이 객체의 인터페이스를 어지럽히고 객체의 응집도와 결합도에 나쁜 영향을 미치기 때문에 변경에 취약한 코드를 낳게 된다.
데이터를 먼저 설계하면 객체 본연의 메시지를 잃게 만든다.
즉 객체를 고립시킨다. (객체가 혼자가 되는 것이다.)
또한 객체의 구현이 이미 결정된 상태에서 다른 객체와의 협력 방법을 고민하기 때문에 이미 구현된 객체의 인터페이스를 억지로 끼워맞출 수밖에 없다.
객체지향이 무엇인가? 협력하는 객체들의 공동체를 구축한다는 것이다.
협력이라는 문맥 안에서 필요한 책임을 결정하고 이를 수행할 적절한 객체를 결정하는 것이 가장 중요하다.
