4장. 설계 품질과 트레이드오프
4장. 설계 품질과 트레이드오프
❐ 1. 데이터 중심의 영화 예매 시스템
1-1. 데이터(상태) 중심 vs 책임 중심
비교하기
- 데이터 중심
- 세부사항이 객체의 인터페이스에 스며들게 되어 캡슐화 원칙이 무너진다.
- 결국 변경에 취약한 설계가 된다.
- 책임 중심
- 상대적으로 변경에 안정적인 설계를 얻을 수 있게 된다.
- 근본적인 차이점은 캡슐화를 다루는 방식
- 캡슐화의 정도가 객체의 응집도와 결합도를 결장한다.
❐ 2. 데이터 중심 설계의 문제점
2-1. 캡슐화를 위반한 설계는 변경에 취약하다.
데이터 중심 설계가 변경에 취향한 이유
- 데이터 중심의 설계는 본질적으로 너무 이른 시기에 데이터에 관해 결정하도록 강요한다.
- 데이터 중심의 설계에서는 협력이라는 문맥을 고려하지 않고 객체를 고립시킨 채 오퍼레이션을 결정한다.
2-2. 데이터 중심 설계는 행동보다는 상태에 초점을 맞춘다.
시작부터 잘못됐다.
- 데이터 중심 설계를 시작할 때 애초에 “이 객체에 포함해야 하는 데이터가 무엇인가?”라는 질문을 던짐
- 이건 처음부터 데이터에 관해 결정하도록 강요하기 때문에 너무 이른 시기에 내부 구현에 초점을 맞춤
데이터 중심의 관점에서 객체는 그저 단순히 데이터의 집합체일 뿐이다.
- 이로 인해 접근자와 수정자를 과도하게 추가하게 된다.
- 이 데이터 객체를 사용하는 절차를 분리된 별도의 객체 안에 구현하게 된다.
2-3. 데이터 중심 설계는 객체를 고립시킨 채 오퍼레이션을 정의하도록 만든다.
객체지향 설계의 무게 중심은 항상 객체의 외부에 맞춰져야 한다.
- 객체 내부에 어떤 상태를 가지고 그 상태를 어떻게 관리하는가는 부가적인 문제다.
- 데이터 중심 설계는
- 객체의 구현이 이미 결정된 상태에서 다른 객체와의 협력 방법을 고민한다.
- 결국 이미 구현된 객체의 인터페이스를 억지로 끼워 맞출수 밖에 없다.
객체의 인터페이스에 구현이 노출되게 된다.
- 협력이 구현 세부사항에 종속돼 있게 된다.
- 결국 객체의 내부 구현이 변경됐을 때 협력하는 객체 모두가 영향을 받을 수밖에 없다.
이 기사는 저작권자의
CC BY 4.0
라이센스를 따릅니다.