[오브젝트] 4장_설계 품질과 트레이드오프
훌륭한 설계란, 합리적인 비용 안에서 변경을 수용할 수 있는 구조를 만드는 것이다.
적절한 비용 안에서 쉽게 변경할 수 있는 설계는, 응집도가 높고 서로 느슨하게 결합되어 있다.
결합도와 응집도를 합리적인 수준으로 유지할 수 있는 원칙은, 객체의 행동에 초점을 맞추는 것이다.
캡슐화
상태와 행동을 하나의 객체 안에 모으는 이유는 객체의 내부 구현을 외부로부터 감추기위해서다.
변경될 가능성이 높은 것을 구현, 상대적으로 안정적인 것을 인터페이스라고 한다.
캡슐화란, 변경 가능성이 높은 것을 객체 내부로 숨기는 추상화 기법이다.
응집도
응집도는 모듈에 포함된 내부 요소들이 연관되어 있는 정도이다.
객체 지향 관점에서는, 객체 또는 클래스에 얼마나 관련 높은 책임들을 할당했는지이다.
응집도가 높은 설계에서는, 하나의 요구사항 변경을 반영하기 위해 오직 하나의 모듈만 수정하면 된다.
응집도가 낮은 설계에서는, 하나의 원인에 의해 변경해야 하는 부분이 다수의 모듈에 분산되어 있기 때문에 여러 모듈을 동시 수정해야한다.
결합도
결헙도는 의존성의 정도이다.
다른 모듈에 대해 얼마나 많은 지식을 갖고 있는지를 나타내는 척도이다.
내부 구현을 변경하면 이것이 다른 모듈에 영향을 미치는 경우 두 모듈 사이의 결합도가 높다고 말한다.
반면, 퍼블릭 인터페이스를 수정했을 때만 다른 모듈에 영향을 미치면 결합도가 낮다고 말한다.
그래서 구현이 아닌 인터페이스에 의존하도록 코드를 작성해야 낮은 결합도를 얻을 수 있다.
이것이 인퍼페이스에 대해 프로그래밍 하라 이다.
데이터 중심 설계의 문제점
데이터 중심 설계는 변경에 취약하다. 이유는,
- 너무 이른시기에 데이터를 결정하도록 강요한다.
- 협력이라는 문맥을 고려하지 않고 객체를 고립시킨 채 오퍼레이션을 결정한다.
데이터 중심 설계는 객체의 행동보다, 상태에 초점을 맞춘다.
데이터 중심 관점에서 객체는 그저 단순한 데이터의 집합이다.
그래서, 접근자와 수정자를 과도하게 추가하여 객체의 캡슐화가 무너진다.
데이터를 먼저 결정하고 데이터를 처리하는 데 필요한 오퍼레이션을 나중에 결정하면,
데이터에 관한 지식이 객체의 인터페이스에 드러난다.
결과적으로, 객체의 인터페이는 구현을 캡슐화 하는데 실패하고 코드는 변경에 취약해진다.
데이터 중심 설계는 객체를 고립시킨 채 오퍼레이션을 결정한다.
객체의 구현이 이미 결정된 상태에서 다른 객체와의 협력 방법을 고민하면,
이미 구현된 객체의 인터페이스를 억지로 끼워넣게 된다.
협력의 문맥 안에서 필요한 책임을 결정하고 이를 수행할 적절한 객체를 결정하는 것이 가장 중요하다.
설계의 중심이 객체의 내부가 아니라 외부에 맞추어져 있어야한다.
오브젝트 <조영호>