응집도
응집도는 모듈에 포함된 내부 요소들이 연관되어 있는 정도이다. 모듈 내 요소들이 하나의 목적을 위해 긴밀하게 협력한다면 그 모듈은 높은 응집도를 가진 것이다. 객체지향의 관점에서 응집도는 객체에 얼마나 관련이 있는 책임들이 할당 되었는지를 나타낸다.
결합도
결합도는 의존성의 저정도로 한 모듈이 다른 모듈에 대해 얼마나 많은 지식을 가지고 있는지를 나타낸다. 어떤 모듈이 다른 모듈에 대해 너무 자세히 알고 있다면 두 모듈의 결합도는 높다고 할 수 있다. 객체지향의 관점에서 객체들끼리는 꼭 필요한 정보만을 알고 있는 것이 좋다.
데이터 중심 설계
데이터 중심 설계는 객체를 설계할 때 상태, 즉 필요로 하는 데이터를 먼저 설계하게 된다. 이렇게 하면 아래와 같은 단점이 발생한다.
- 객체간의 응집도가 낮아진다. 코드는 작성한 그 순간부터 수정이 필요하게 되는데, 새로운 분기, 기능을 추가하기 위해 다른 비즈니스 로직과 객체를 둘 다 수정하는 일이 생긴다. 또 이 객체에 다양한 기능을 추가하면 추가할 수록 응집도가 낮은 객체가 된다.
- 데이터 중심 설계는 캡슐화를 위반하고 객체의 내부구현을 인터페이스의 일부로 만들게 된다. 반면 책임 중심설계는 객체의 내부 구현을 안정적인 인터페이스 뒤로 캡슐화 한다.
- 너무 이른 시기에 데이터에 대해 고민하게 만들어 객체를 고립시킨 채 오퍼레이션을 정의하게 만든다. 협력은 객체와 객체 사이의 상호작용인데, 데이터 중심설계는 객체의 초점이 외부가 아니라 내부로 향하게 된다.
getter, setter
getter와 setter의 사용을 지양하자는 말이 많았지만 정확히 왜 그런지 이해할 수도 설명할 수도 없었다. 하지만 오브젝트를 읽으면 왜 getter, setter를 지양하는지 왜 getter, setter를 설정하게 되는지도 알 수 있었다.
데이터 중심 설계를 하면 데이터에 접근하기 위해 getter, setter를 선언하게 된다. 이렇게 하면
- getter, setter를 과도하게 사용하여 이를 비즈니스 로직에 넣는다고 하자. 만약 한 객체의 프로퍼티(상태)의 타입을 바꾸면 getter의 반환타입도 수정이 된다. 결국 이 getter가 사용된 모든 비즈니스 로직을 바꿔야 하고, 이 객체가 다른 비즈니스 로직에 강하게 결합되어 시스템 전체가 흔들리는 일이 생긴다.
- 속성의 가시성을 private로 설정했다고 해도 getter, setter를 통해 속성을 외부로 제공하고 있다면 캡슐화를 위반하는 것이다. 메서드는 하나의 값을 반환하거나 수정하는 것이 아닌 객체가 책임져야 하는 무언가를 수행해야 한다.
- getter, setter는 객체의 데이터를 public으로 두는것과 다름이 없다. 즉 캡슐화를 어기가 된다. 또 getter, setter를 다른 로직에서 사용함으로서 결합도에 나쁜 영향을 준다.
자율적인 객체
자율적인 객체를 만들기 위해서는 캡슐화가 1순위이다. 변경이 많을 것 같은 부분을 캡슐화하면 대부분의 변경 사항에서 자유로워질 수 있다. 데이터 중심 설계가 낮은 응집도, 높은 결합도를 가지는 가장 큰 이유는 캡슐화의 원칙을 위반하기 때문이다.
상태와 행동을 하나의 객체로 묶는 이유는 객체가 스스로 자신의 상태를 처리할 수 있게 하기 위해서이다. 이렇게 해야 응집도가 높아진다. 객체는 단순한 데이터 제공자가 아니다. 데이터보다 객체가 협력에 참여하며 수행할 책임을 정의하는 오퍼레이션이 더 중요하다.