[오브젝트] 9일차

p.108 ~ p.117

설계 트레이드오프

캡슐화

객체를 사용하면 변경 가능성이 높은 부분-구현-을 내부에 숨기고 외부에는 상대적으로 안정적인 부분-인터페이스- 만 공개함으로써 변경의 여파를 통제할 수 있다.

객체지향 프로그래밍을 통해 전반적으로 얻을 수 있는 장점은 오직 설계 과정 동안 캡슐화를 목표로 인식할 때만 달성될 수 있다.

캡슐화가 중요한 이유는 불안정한 부분과 안정적인 부분을 구분함으로써 변경의 영향을 통제하고 이는 변경의 관점에서 설계의 품질을 판단하는 요소가 된다. → 캡슐화는 변경으로부터 자유로운 프로그램을 만들기 때문

응집도와 결합도

응집도는 모듈이 포함된 내부 요소들이 연관되어 있는 정도를 의미한다.
모듈 내 요소들이 동일한 목적을 갖고 협력한다면 응집도가 높은 것이고 서로 목적이 다르다면 응집도가 낮은 것이다.
객체지향의 관점에서 응집도는 객체 또는 클래스에 얼마나 관련 높은 책임을 할당했는지 나타낸다.

결합도는 의존성의 정도를 의미한다.
어떤 모듈이 다른 모듈이 대한 정보가 많다면 결합도가 높은 것이고 꼭 필요한 정보만 있다면 낮은 결합도이다.
객체지향의 관점에서 결합도는 객체 또는 클래스가 협력에 필요한 적절한 수준의 관계만을 유지하고 있는지 나타낸다.

객체 지향 관점에서 좋은 설계는 높은 응집도와 낮은 결합도를 가진 설계이다. 그 이유는 설계를 변경하기 쉽게 만들기 때문. 응집도가 높은 경우 요구사항이 변경될 때 수정할 변경의 대상과 범위가 명확해진다. 결합도가 낮을 경우 한 모듈이 변경되기 위해서 다른 모듈의 변경을 요구하는 정도가 낮아지는 것이기 때문에 함께 변경해야 하는 모듈의 수가 줄어든다.

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

데이터 중심 설계의 문제점

데이터 중심의 설계는 캡슐화를 위반하고 책임 중심 설계에 비해 응집도가 낮고 높은 객체를 양산한다.

캡슐화 위반

데이터 중심으로 설계한 클래스는 접근자와 수정자를 통해 객체 내부의 상태에 접근한다. 접근자와 수정자에 과도한 의존하는 방식을 추측에 의한 설계 전략이라고 부른다.
이 방식은 객체가 사용될 협력을 고려하지 않고 객체가 다양한 상황에서 사용될 것이라는 추측을 기반으로 설계하는 것이기 때문에 결국 객체의 내부를 드러내는 메서드를 추가하게 된다. 이는 결과적으로 내부 구현의 노출로 이어져 캡슐화의 원칙을 위반하는 설계로 이어진다.

높은 결합도

데이터 중심 설계는 여러 데이터 객체들을 사용하는 제어 로직이 특정 객체 안에 집중되기 떄문에 하나의 제어 객체가 다수의 데이터 객체에 강하게 결합된다. → 변경에 취약

낮은 응집도

변경의 이유가 서로 다른 코드가 하나의 모듈에 뭉쳐있기 때문에 요구사항의 변경과 추가가 다른 요구사항에도 영향을 미치게 된다.

단일 책임 원칙

클래스는 단 한 가지의 변경 이유만 가져야 한다는 것이다. 단일 책임 원칙은 클래스의 응집도를 높일 수 있는 설계원칙이다. 여기서 책임은 변경의 이유이고, 객체지향에서의 책임보다 더 큰 개념이다.