[오브젝트 2회독] 4장 - 설계 품질과 트레이드 오프

• 훌륭한 객체 지향 설계를 위해선 비용 내에서 변경을 수용할 수 있는 구조를 만드는 것
• 유연한 구조를 위해 응집도가 높고 결합도가 낮으며, 객체의 상태가 아닌 행동 더 나아가 책임에 초점을 맞춤

1. 설계 트레이드 오프

객체 설계의 장단점을 비교하기 위한 3가지 척도인 캡슐화, 응집도, 결합도

캡슐화

• 객체를 사용하여 변경 가능성이 높은 부분을 숨기고, 외부에 상대적으로 안정적인 부분을 공개하여 변경의 여파를 통제
• 상태는 변경 가능성이 높은 부분이며, 상대적으로 안정적인 부분은 객체의 책임, 메시지
• 핵심은 변경 가능성이 높은 부분을 객체 내부로 숨기는 추상화 기법으로서, 내부 구현이 변하더라도 변화의 여파를 통제할 수 있음

응집도와 결합도

응집도

• (변경의 관점) 변경 발생시 모듈 내부에서 발생하는 변경의 정도
• 하나의 변경 수용을 위해 모듈 전체가 변경될 때 응집도가 높음(다수의 모듈이 함께 변경된다면 응집도가 낮음)

결합도

• (변경의 관점) 한 모듈이 변경되기 위해 다른 모듈의 변경을 요구하는 정도

결론

• 결국 변경의 관점에서 높은 응집도와 낮은 응집도를 추구함으로써 변경하기 쉬운 설계를 만들 수 있음
• 캡슐화를 지킬수록 모듈안의 응집도가 높아지고, 결합도가 낮아짐

2. 데이터 중심 설계

• 데이터 중심의 관점에서 객체는 자신이 포함하고 있는 데이터를 조작하는데 필요한 오퍼레이션 정의
• 해당 관점이 잘못된 이유는 객체의 상태는 구현에 해당
• 상태라는 내부 구현이 객체의 인터페이스에 중심이 되어 캡슐화 원칙이 무너지고, 상태 변경에 클라이언트에 영향을 줌
• 이와 반대로 퍼블릭 인터페이스에 속한 객체의 책임을 중심으로 설계할 때 자주 변경되는 요소를 감추어 캡슐화를 잘 보존함

데이터 중심의 문제점

1. 캡슐화 위반

• 데이터 중심 설계에서는 getter, setter를 통해 객체 내부 상태에 접근할 수 있도록 함
• 내부 상태를 퍼블릭 인터페이스로 드러내어 캡슐화를 위반하고 있음
• 캡슐화의 본질은 단순히 private property가 아닌 변화에 취약한 것을 감춰야 함

1. 높은 결합도

• getter setter등으로 내부 상태에 접근할 수 있기 때문에, 객체 내부 구현이 변경될 때 모든 클라이언트에 영향을 줌

1. 낮은 응집도

• 행위를 처리하는 객체가 내부에 있지 않고 외부에 존재하기 때문에, 데이터를 사용하는 동작들이 여러 모듈에 걸쳐 존재하게 됨

데이터 중심의 설계의 문제점은 다양한 이유로 모듈이 변경되는 것

변경을 이유로 모듈을 분리하여 응집도를 높일 수 있음

SRP(단일 책임 원칙)이라고도 불리며, 결국 클래스는 단 한가지 변경에 대한 이유를 가져야 함

데이터 중심 설계는 객체의 행동보다 상태에 초점

데이터 중심 설계가 변경에 취약한 이유는

• 본질적으로 너무 이른 시기에 데이터에 관해 결정하도록 강요
• 협력이라는 문맥을 고려하지 않고 객체를 고립시켜 오퍼레이션을 결정

단순한 데이터의 집합체인 객체로 보기 때문에, 접근자와 수정자를 과도하게 추가하여 캡슐화 원칙이 무너짐

퍼블릭 인터페이스는 구현을 캡슐화하는데 실패하고 코드가 변경에 취약해짐

결론

• 훌륭한 객체 지향 설계는 변경에 유연한 구조를 만드는 것
• 이를 위해 캡슐화를 지키고, 높은 응집도와 낮은 결합도를 유지하도록 함
  • 캡슐화: 변화에 취약한 부분을 감추는 것
  • 높은 응집도: 변화의 원인을 한곳으로 모으는 것
  • 낮은 결합도: 한 모듈이 변경되도 다른 모듈에 영향을 최소화로 미쳐야 함
• 기존 데이터 중심 설계의 문제점 3가지
  • 캡슐화 위반
    • 객체 내부 상태 중심이기 때문에, 이를 조작할 수 있는 다양한 수정자가 제공
    • 변화에 취약한 내부 상태가 외부로 노출되어 변경에 취약함
  • 낮은 응집도
    • 하나의 원인에 대한 변경이 모듈로 모여 있지 않고 흩어짐
    • 데이터와 행동이 분리되어 있기 때문
  • 높은 결합도
    • 수정자등으로 내부 상태가 노출되어 있어, 내부 구현의 변경이 클라이언트에 영향을 미침
• 데이터 중심 설계의 문제점은 내부 구현이라는 변경에 취약한 부분에 의존하고 있기 때문
• 그리하여 비즈니스 로직 변경에도 상대적으로 변하지 않는 책임에 의존하고, 이를 퍼블릭 인터페이스로 노출해야 함