출처 : 오브젝트 (조영호 저)
책임을 할당하는 작업이 응집도와 결합도 같은 설계 품질과 깊이 연관돼 있다는 것이다. (SOLID원칙에 의하면, 단일책임원칙은 높은 응집도와 낮은 결합도를 만들어 낸다)
결합도와 응집도를 합리적인 수준으로 유지하려면 객체의 상태가 아니라 객체의 행동에 초점을 맞춰야 한다.
캡슐화
변경될 가능성이 높은 부분을 구현이라 하고 상대적으로 안정적인 부분을 인터페이스라 한다. 캡슐화는 외부에서 알 필요가 없는 부분을 감춤으로써 대상을 단순화하는 추상화의 종류다. 즉, 불안정한 구현 세부사항을 안정적인 인터페이스 뒤로 캡슐화 하는 것이다. 캡슐화가 중요한 이유는 불안정한 부분과 안정적인 부분을 분리해서 변경의 영향을 통제할 수 있기 때문이다.
응집도와 결합도
응집도는 모듈에 포함된 내부 요소들이 연관돼 있는 정도를 나타낸다. 결합도는 의존성의 정도를 나타내며 다른 모듈에 대해 얼마나 많은 지식을 갖고 있는지를 나타내는 척도이다. 높은 응집도와 낮은 결합도를 추구해야 하는 것은 그것이 설계를 변경하기 쉽게 만들기 때문이다.
캡슐화의 정도가 응집도와 결합도에 영향을 미친다. 캡슐화를 지키면 모듈 안의 응집도는 높아지고 모듈 사이의 결합도는 낮아진다.
데이터 중심 설계의 문제점
데이터 중심의 설계에서는 객체가 포함해야 하는 데이터에 집중한다.
객체 내부 상태에 대한 정보가 get, set으로 노출되므로 모든 정보를 캡슐화하지 못한다. 캡슐화의 원칙을 어기게 된 근본적인 원인은 책임이 아니라 데이터에 초점을 맞췄기 때문이다.
데이터 중심설계에서는 service에서 모든 객체에 의존하고 모든 제어 로직을 가지고 있게 되기 때문에 하나의 제어 객체가 다수의 데이터 객체에 강하게 결합된다. 이 결합도로 인해 어떤 데이터 객체를 변경하더라도 제어 객체를 함께 변경할 수 밖에 없다.
제어로직 하나의 객체에 뭉쳐 놓았기 때문에 하나의 요구 사항 변경을 반영하기 위해 동시에 여러 모듈을 수정해야 한다.
상태와 행동을 객체라는 하나의 단위로 묶는 이유는 객체 스스로 자신의 상태를 처리할 수 있게 하기 위해서다.
객체를 설계할 때 다음의 2가지 질문을 해야 한다.
- 이 객체가 어떤 데이터를 포함해야 하는가?
- 이 객체가 데이터에 대해 수행해야 하는 오퍼레이션은 무엇인가?
데이터 중심의 사례가 변경에 취약한 이유는 두가지다.
-
본질적으로 너무 이른 시기에 데이터에 관해 결정하도록 강요한다.
-
협력이라는 문맥을 고려하지 않고 객체를 고립시킨 채 오퍼레이션을 결정한다.
데이터 중심 설계에서 객체는 그저 단순한 데이터의 집합체일 뿐이다. getter, setter는 public 속성과 큰 차이가 없기 때문에 객체의 캡슐화는 완전히 무너진다.
데이터를 먼저 결정하고 데이터를 처리하는 오퍼레이션을 나중에 결정하는 방식은 구현을 캡슐화하는 데 실패하고 코드는 변경에 취약해진다.
올바른 객체지향 설계의 무게 중심은 항상 객체의 내부가 아니라 외부에 맞춰져 있어야 한다. 객체 내부의 어떤 상태를 가지고 어떻게 관리하는 가는 부가적인 문제다. 중요한 것은 객체가 다른 객체와 협력하는 방법이다.
데이터 중심 설계의 초점은 객체의 외부가 아니라 내부로 향한다. 객체의 구현이 이미 결정된 상태에서 다른 객체와의 협력방법을 고민하기 때문에 이미 구현된 객체의 인터페이스를 억지로 끼워맞출 수 밖에 없다. 이것이 변경에 유연하게 대처하지 못한 이유이다.
