객체지향 커뮤니티에서는 오랜 기간동안 좋은 설계의 특징을 판단할 수 있는 기준에 관한 다양한 논의가 있어왔다.
캡슐화
객체를 사용하면 변경 가능성이 높은 부분은 내부에 숨기고 외부에는 상대적으로 안정적인 부분만 공개함으로써 변경의 여파를 통제할 수 있다.
변경될 가능성이 높은 부분을 구현이라 하고 상대적으로 안정적인 부분을 인터페이스라 한다.
객체지향 설계의 가장 중요한 원리는 불안정한 구현 세부사항을 안정적인 인터페이스 뒤로 캡슐화 하는 것이다.
설계가 필요한 이유는 요구사항이 변경되기 때문이고, 캡슐화가 중요한 이유는 불안정한 부분과 안정적인 부분을 분리해서 변경의 영향을 통제할 수 있기 때문이다.
응집도
모듈에 포함된 내부 요소들이 연관되어 있는 정도를 나타낸다.
모듈 내의 요소들이 하나의 목적을 위해 긴밀하게 협력한다면 그 모듈은 높은 응집도를 가진다.
변경의 관점에서 응집도란 변경이 발생할 때 모듈 내부에서 발생하는 변경의 정도로 측정할 수 있다.
결합도
의존성의 정도를 나타내며 다른 모듈에 대해 얼마나 많은 지식을 갖고 있는지를 나타내는 척도다. 어떤 모듈이 다른 모듈에 대해 너무 자세한 부분까지 알고 있다면 높은 결합도를, 꼭 필요한 지식만 알고있다면 낮은 결합도를 가진다.
변경의 관점에서 결합도는 한 모듈이 변경되기 위해서 다른 모듈의 변경을 요구하는 정도로 측정할 수 있다.
일반적으로 변경될 확률이 매우 적은 안정적인 모듈에 의존하는 것은 아무런 문제도 되지 않는다. 표준 라이브러리에 포함된 모듈이나 성숙단계에 접어든 프레임워크에 의존하는 경우가 여기에 속한다.
캡슐화를 지키면 모듈안의 응집도는 높아지고 모듈간의 결합도는 낮아진다.
응집도와 결합도를 고려하기 전에 먼저 캡슐화를 향상시키기 위해 노력하라.
추측에 의한 설계전략
접근자와 수정자에 과도하게 의존하는 설계방식을 추측에 의한 설계전략이라 부른다.
이 전략은 객체가 사용될 협력을 고려하지 않고 객체가 다양한 상황에서 사용될 수 있을 것이라는 막연한 추측을 기반으로 설계를 진행한다.
따라서 프로그래머는 내부 상태를 드러내는 메서드를 최대한 많이 추가해야한다는 압박에 시달릴 수 밖에 없고 결과적으로 내부 구현이 퍼블릭 인터페이스에 그대로 노출될 수밖에 없다.
그 결과, 캡슐화의 원칙을 위반하는 변경에 취약한 설계를 얻게 된다.
데이터 중심 설계의 문제점
객체의 행동보다는 상태에 초점을 맞춘다
데이터 중심의 설계는 "이 객체가 포함해야 하는 데이터가 무엇인가?" 에서 시작한다. 때문에 너무 이른시기에 내부 구현에 초점을 맞추게 한다.
데이터 중심의 관점에서 객체는 그저 단순한 데이터의 집합체일 뿐이다. 이로 인해 접근/수정자를 과도하게 추가하게 되고 이 데이터 객체를 사용하는 절차를 분리된 별도의 객체 안에 구현하게 된다.
접근/수정자는 public 속성과 큰 차이가 없기 때문에 객체의 캡슐화는 완전히 무너질 수밖에 없다.
데이터를 먼저 결정하고 데이터를 처리하는데 필요한 오퍼레이션을 나중에 결정하는 방식은 데이터에 관한 지식이 객체의 인터페이스에 고스란히 드러나게 된다.
결과적으로 구현을 캡슐화 하는데 실패하고 변경에 취약해진다.
객체를 고립시킨 채 오퍼레이션을 정의하도록 만든다
데이터 중심 설계에서 초점은 객체의 외부가 아니라 내부로 향한다.
실행 문맥에 대한 깊이있는 고민 없이 객체가 관리할 데이터의 세부 정보를 먼저 결정한다.
객체의 구현이 이미 결정된 상태에서 다른 객체와의 협력방법을 고민하기 때문에 이미 구현된 객체의 인터페이스를 억지로 끼워맞출 수밖에 없다.
