[오브젝트] 4장. 설계 품질과 트레이드 오프

- 역할, 책임, 협력 중 책임이 가장 중요하다. 책임이 객체지향 애플리케이션의 품질을 결정한다.

- 객체들이 수행할 책임이 적절하게 할당되지 못한 상황에서는 원활한 협력도 기대할 수 없을 것이다. 역할은 책임의 집합이기 때문에 책임이 적절하지 못하면 역할 역시 협력과 조화를 이루지 못한다.

---

객체지향 설계 - 응집도와 결합도 그리고 캡슐화

- 객체지향 설계란 올바른 객체에게 올바른 책임을 할당하면서 낮은 결합도와 높은 응집도를 가진 구조를 창조하는 행동

응집도

: 모듈에 포함된 내부 요소들이 연관돼 있는 정도. 모듈 내의 요소들이 하나의 목적을 위해 긴밀하게 협력한다면 그 모듈은 높은 응집도를 가진다.

• 객체지향의 관점에서 응집도는 객체 또는 클래스에 얼마나 관련 높은 책임들을 할당했는지를 나타낸다.
• 변경의 관점에선 변경이 발생할 때 모듈 내부에서 발생하는 변경의 정도를 나타낸다.
• 하나의 변경을 수용하기 위해 한 모듈의 전체가 함께 변경되면 응집도가 높지만, 다수의 모듈이 함께 변경돼야 한다면 응집도가 낮은 것.

 

결합도

: 다른 모듈과의 의존성의 정도. 다른 모듈에 대해 얼마나 많은 지식을 갖고 있는지를 나타내는 척도.

• 객체지향의 관점에서 결합도는 객체 또는 클래스가 협력에 필요한 적절한 수준의 관계만을 유지하고 있는지를 나타낸다.
• 변경의 관점에선 한 모듈이 변경되기 위해서 다른 모듈의 변경을 요구하는 정도.
• 결합도가 높을수록 변경해야 하는 모듈의 수가 늘어나 변경이 어렵다.

- 좋은 설계란 높은 응집도와 낮은 결합도를 가진 모듈로 구성된 설계 -> 오늘의 기능을 수행하면서 내일의 변경을 수용할 수 있는 설계.

 

캡슐화 :

: 객체지향 설계의 핵심. 변경 가능성이 높은 부분을 객체 내부로 숨기는 추상화 기법.

- 캡슐화를 지키면 모듈 안의 응집도는 높아지고, 모듈 사이의 결합도는 낮아진다. 따라서 응집도와 결합도를 고려하기 전에 먼저 캡슐화를 향상시키기 위해 노력하라.

- 캡슐화란 변할 수 있는 어떤 것이라도 감추는 것이다. 그것이 무엇이든 구현과 관련된 것이라면 말이다.

- 데이터 중심의 설계는 캡슐화를 위반하고 객체의 내부 구현을 인터페이스의 일부로 만든다. 반면 책임 중심의 설계는 객체의 내부 구현을 안정적인 인터페이스 뒤로 캡슐화한다.

- 속성의 가시성을 private로 설정했다고 해도 접근자(getter)와 수정자(setter)를 통해 속성을 외부로 제공하고 있다면 캡슐화를 위반하는 것이다.

---

객체를 설계할 때 필요한 2가지 질문

• 이 객체가 어떤 데이터를 포함해야 하는가?
• 이 객체가 데이터에 대해 수행해야 하는 오퍼레이션은 무엇인가?

-> 두 질문을 조합하면 객체의 내부 상태를 저장하는 방식과 저장된 상태에 대해 호출할 수 있는 오퍼레이션의 집합을 만들 수 있다. 다시 말해 새로운 데이터 타입을 만들 수 있는 것이다.

---

데이터 중심 설계의 문제점

• 객체의 행동보다는 상태에 초점을 맞춘다.
• 객체를 고립시킨 채 오퍼레이션을 정의하도록 만든다.