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

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

 

객체지향 설계의 핵심은 책임이다.

책임을 할당하는 작업이 응집도와 결합도 같은 설계 품질과 깊이 연관되어 있다.

 

훌륭한 설계: 합리적인 비용 안에서 변경을 수용할 수 있는 구조를 만드는 것.

 

 

데이터 주도 설계

 

4장에서는 잘못된 설계 방법인 데이터 주도 설계(Data-Driven Design)를 통해 통찰을 준다.

 

데이터 주도 설계의 한계

1. 객체의 상태는 구현에 속하므로 변하기 쉽다.

2. 구현에 관한 세부사항이 인터페이스에 스며들어 캡슐화의 원칙이 무너진다.

3. 상태 변경은 인터페이스의 변경을 불러오고, 이는 변경에 취약하다는 뜻이다.

 

책임을 결정하기 전에 이 객체가 포함해야 하는 데이터는 무엇인가?라는 질문이 반복된다면,

이는 데이터 중심 설계에 매몰되어 있을 확률이 높다.

 

 

데이터 주도 설계 과정

1. 데이터를 준비한다.

2. 캡슐화를 위해 접근자(Getter)와 수정자(Setter)를 추가한다.

 

 

설계 트레이드오프

세 가지 설계 품질 척도에 대해 알아보자.

설계 품질 척도
1. 캡슐화
2. 응집도
3. 결합도

 

 

1. 캡슐화

1) 변경 가능성이 높은 부분(구현)은 내부에 숨기고, 외부에는 상대적으로 안정된 부분(인터페이스)만 공개하는 방법.

-> 이를 통해 변경의 여파를 통제한다.

2) 외부에서 알 필요가 없는 부분을 감춤으로써 대상을 단순화하는 추상화의 한 종류이다.

 

 

2. 응집도(Cohesion)

정의: 모듈이 포함된 내부 요소들이 연관돼 있는 정도

모듈 내의 요소들이
하나의 목적을 위해 긴밀하게 협력한다면? => 높은 응집도
서로 다른 목적을 추구한다면? => 낮은 응집도

 

 

변경의 관점에서 보면, 변경이 발생할 때 모듈 내부에서 발생하는 변경의 정도

하나의 변경을 수용하기 위해
모듈 전체가 함께 변경된다면? => 높은 응집도
모듈의 일부만 변경된다면? => 낮은 응집도

 

 

응집도가 높을수록 변경의 대상과 범위가 명확해져 코드의 변경이 쉽다.

변경을 반영하기 위해 오직 하나의 모듈만 수정하면 된다.

 

3. 결합도(Coupling)

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

어떤 모듈이 다른 모듈에 대해
너무 자세한 부분까지 안다면? => 높은 결합도
꼭 필요한 부분만 안다면? => 낮은 결합도

 

 

변경의 관점에서 보면, 한 모듈이 변경되기 위해서 다른 모듈의 변경을 요구하는 정도

모듈 하나를 변경했을 때,
많은 수의 모듈이 여향을 받는다면? => 높은 결합도
적은 수의 모듈이 영향을 받는다면? => 낮은 결합도

내부 구현을 변경했을 때 다른 모듈에도 영향을 미칠 경우? => 높은 결합도
퍼블릭 인터페이스를 수정했을 때만 다른 모듈에 영향을 미칠경우? => 낮은 결합도

 

응집도와 결합도는 변경과 관련이 깊다!

 

 

데이터 주도 설계의 문제점

1. 캡슐화 위반

접근자와 수정자 메서드: 객체 내부의 상태에 대한 어떤 정보도 캡슐화 하지 못한다!

 

접근자와 수정자 메서드에 과도하게 의존하는 설계를 추측에 의한 설계 전략이라고 한다.

이는 객체가 최대한 다양한 상황에서 사용될 수 있을 것이라는 막연한 추측을 기반으로 하기 때문이다.

 

2. 높은 결합도

어떤 변경이든 시스템 전체의 요동을 불러온다.

 

3. 낮은 응집도

1. 어떤 코드를 수정한 후 아무런 상관도 없던 코드에 문제가 발생한다.

2. 하나의 요구사항이 변경될 경우 동시에 여러 모듈을 수정해야 한다.

 

단일 책임 원칙(Single Responsibility Principle, SRP)

응집도와 관련된 원칙으로
쉽게 말하면, 클래스는 단 한 가지의 변경의 이류만을 가져야 한다는 뜻이다.

 

데이터 주도 설계가 변경에 취약한 이유

1. 너무 이른 시기에 데이터에 관해 결정하도록 강요한다.

2. 협력이라는 문맥을 고려하지 않고 객체를 고립시킨 채 오퍼레이션을 결정한다.

=> 이미 구현된 객체의 인터페이스를 억지로 다른 객체와 협력하는 꼴이다.