-
객체 지향 설계의 핵심 - 역할, 책임, 협력
- 협력 - 객체들의 상호작용
- 책임 - 협력하기 위해 수행하는 행동
- 역할 - 대체 가능한 책임의 집합(가중 중요)
-
객체지향 설계의 핵심이 책임
- 책임을 할당하는 작업이 응집도와 설계 품질과 깊이 연관
- 객체에 행동에 초점을 맞춤으로서 결합도와 응집도를 합리적인 수준으로 유지할 수 있다.
01 데이터 중심의 영화 예매 시스템
- 객체의 상태 = 구현(구체적인 것)
- 객체의 상태가 객체 분할의 중심축이되면 캡슐화의 원칙이 무너지게 된다.
- 이는 변경에 취약한 구조를 가지게 한다.
데이터를 준비하자
영화를 예매하자
02 설계 트레이드오프
캡슐화
- 변경될 가능성이 높은 부분을 구현
- 안정적인 부분을 인터페이스
- 캡슐화는 구현을 인터페이스 뒤로 숨기는 것
응집도와 결합도
- 응집도가 높은 설계에서는 하나의 요구 사항 변경을 반영하기 위해 오직 하나의 모듈만 수정하면 된다. (코드 변경하기가 쉬워진다)
- 결합도는 한 모듈이 변경되기 위해 다른 모듈의 변경을 요구하는 정도
- 퍼블릭 인터페이스를 수정했을 때만 다른 모듈에 영향을 미치는 경우에는 결합도가 낮다고 표현
- 즉 쉽게 변경할 수 있다면 높은 응집도를 가지고 낮은 결합도일 가능성이 높다.
03 데이터 중심의 영화 예매 시스템의 문제점
- 데이터 중심 설계의 문제점
- 캡슐화 위반
- 높은 결합도
- 낮은 응집도
캡슐화 위반
- 데이터 중심 설계 → 저장할 데이터에 초점을 맞춤
- 접근자와 수정자의 막연한 사용
- 추측에 의한 설계 전략
- 당영한 상황에서 사용될 수 있을 것이라는 막연한 추측을 기반으로 설계
높은 결합도
- 객체 내부 구현이 객체의 인터페이스에 드러난다는 것은 클라이언트가 구현에 강하게 결합된다는 것
- 데이터 중심 설계의 또 다른 문제는 제어 로직이 특정 객체 안에 집중됨
- 제어 로직을 가지고 있는 특정 객체는 변경에 지속적으로 영향을 받게된다.
낮은 응집도
- 서로 다른 이유로 변경되는 코드가 하나의 모듈 안에 공존할 때 모듈의 응집도가 낮다고 말한다.
- 변경을 수용하기 위해 하나 이상의 클래스를 수정해야 하는 것이 설계의 응집도가 낮다는 증거다.
04 자율적인 객체를 향해
캡슐화를 지켜라
- 의미 있는 메서드 = 책임져야 하는 무언가를 수행하는 메서드
- private으로 설정했다고 해도 접근자와 수정자를 통해 속성을 외부로 제공하고 있다면 캡슐화를 위반하는 것
스스로 자신의 데이터를 책임지는 객체
- 데이터 보다 중요한 것은 책임을 정의하는 오퍼레이션이 더 중요
05 하지만 여전히 부족하다
캡슐화 위반
- 내부 구현의 변경이 외부로 퍼져나가는 파급 효과는 캡슐화가 부족하다는 명백한 증거
높은 결합도
- 결합도가 높다 → 한 객체의 구현을 변경할 때 다른 객체에게 변경의 영향이 전파될 확률이 높아진다
낮은 응집도
06 데이터 중심 설계의 문제점
- 데이터 중심 설계는 ...
- 너무 이른 시기에 데이터에 관해 결정하도록 강요
- 협력이라는 문맥을 고려하지 않고 객체를 고립시킨 채 오퍼레이션을 결정
데이터 중심 설계는 객체의 행동보다 상태에 초점을 맞춘다.
- 데이터는 구현의 일부
- 접근자와 수정자는 public 속성과 큰 차이가 없다
데이터 중심 설계는 객체를 고립시킨 채 오퍼레이션을 정의하도록 만든다.
- 협력이라는 문맥 안에서 필요한 책임을 결정하고 이를 수행할 적절한 객체를 결정하는 것
- 데이터 중심 설계는 구현이 결정된 상태에서 다른 객체의 협력 방법을 고민 → 이미 구현된 객체의 인터페이스를 억지로 끼워 맞추게 된다.
꾸준히 나아가자 🐢