복습 및 요약

4장은 1~3장과 달리 데이터 중심으로 프로그램을 설계했을 때 나타나는 문제점들에 대해 생각해보며 데이터 중심이 아닌 역할 및 협력을 중심으로하는 사고의 효용을 드러낸다. 데이터 중심 설계의 단점은 어떤 것이 있을까? 데이터 중심 설계는 기존의 절차형 프로그래밍에서 자주 사용하던 방식으로 클래스 및 객체는 단순히 데이터를 저장하는 용도로 사용되고 프로세스에서 이러한 데이터의 값을 제어하는 방식을 취한다. 1장에서 리팩토링 하기 전의 상태가 데이터 중심설계와 비슷하다고 할 수 있다. 이러한 설계에서 객체는 단순히 데이터를 전달하는 역할만을 하기 때문에 객체 내부의 상태와 행위에 대해서 (행위가 존재하지 않을 지도 모른다) 외부로 가능한 많이 노출하고자 한다. 이렇게 설계된 프로그램의 단점은 아래와 같다.

• 높은 결합도
  • 프로세스영역은 모든 객체의 내부 구현을 가져와서 처리하는 방식이기 때문에 모든 객체와 강하게 결합되고 이는 결국 수정에 있어서 하나의 변경 그 이상의 변경사항을 가져오는 결과를 낳는다.
• 낮은 응집성
  • 객체는 단순히 데이터를 전달하는 역할로서만 의미를 가지기 때문에 객체 자신이 가지고 있는 상태와 관련이 있는 행동을 가지지 않는다. 또한 역할이라는 것이 단순히 데이터로서만의 역할이기 때문에 관련된 로직이라 하더라도 객체 자체가 가지고 있는 것이 아니라 이를 처리하는 프로세스가 가지고 있기 때문에 응집성이 낮다.
• 캡슐화 위반
  • 객체는 변경될 수 있는 불안한 부분은 내부로 숨기고 외부에는 변경되지 않을 것 같고 메세지를 위한 소통의 방법으로 공용인터페이스만을 노출해야한다. 하지만 데이터 중심 설계에서는 객체 내부의 데이터를 모두 외부에 공용 인터페이스의 형태로 제공하고 있기 때문에 스스로에 대한 제어권이 없고 외부에서 값을 자유롭게 변경할 수 있다. 이는 필요한 부분만을 노출하고 내부 구현은 숨겨야하는 캡슐화를 위반하고 있는 것이다.

위의 단점은 모두 객체의 캡슐화를 위반하면서 동시적으로 발생하는 문제점이다. 캡슐화를 통해 객체는 변경될 수 있는 부분은 내부로 감추고 변경되지 않을 것 같은 부분만을 공용 인터페이스로 노출하는데 캡슐화를 위반하는 경우 변경사항에 대해서 데이터를 담당하는 그 객체와 객체를 이용하고 있는 프로세스 모두에서 수정을 필요로 하기 때문이다. 물론 이러한 캡슐화를 일부 수정하여 변경할 수 있다. 하지만 이 경우에도 데이터 중심 설계는 객체의 역할에 초점을 두는 것이 아니라 상태에 초점을 맞추고 있기 때문에 지정된 상태에 국한된 즉 역할에 충실하기 위한 객체가 아니라 상태가 처리할 수 있는 부분에 초점을 맞춰 개발할 수 밖에 없다.

데이터 중심의 설계의 단점

객체를 하나의 데이터로 간주하고 가져야할 상태와 데이터만을 명시한다. 이 후 외부에서 값을 가져갈 수 있도록 데이터에 대해서 전부 외부 인터페이스로 노출하고 심지어는 더 많은 것을 외부로 노출하고자 한다 왜냐하면 단순히 데이터로써의 역할만을 담당하는 부분이기때문에 사용할 수 있는 범위를 늘리기 위해서.

• 높은 결합도
• 낮은 응집성
• 캡슐화 위반

캡슐화란 결국 각 객체가 자신이 가지고 있는 상태와 구현을 숨기고 외부에 특정 인터페이스만을 노출함으로써 불완전한 부분을 객체가 담당하는 것이다. 캡슐화를 하게 되면 자연스럽게 응집성은 높아지고 결합도는 낮아지는데 이유는 객체가 가지고 있는 행동과 상태에 집중하여 내부구현을 담당하게 되고 외부에서는 객체가 외부적으로 보여주는 인터페이스만을 사용할 수 있기 때문에 객체는 자율적존재가 되고 외부는 객체 데이터 하나하나에 의존하는 것이 아니라 얻고싶은 메세지의 결과를 반환하는 인터페이스에만 의존하는 관계가 형성된다. 따라서 변경이 발생하더라도 내부로직을 통해 인터페이스의 반환값을 제대로 설정한다면 변경해야 할 부분은 단하나 캡슐화된 코드일 뿐이다.