4. 설계 품질과 트레이드 오프
- 객체지향 설계의 핵심은 역할, 책임, 엽력입니다.
- 책임 주도 설계라는 이름처럼 역할, 책임, 협력에서 가장 중요한 것은 '책임'입니다.
- 객체지향 설계란 올바른 객체에게 올바른 책임을 할당하면서 낮은 결합도와 높은 응집도를 가진 구조를 창조하는 활동입니다.
01. 데이터 중심의 영화 예매 시스템#
- 객체지향 설계에서는 두 가지 방법을 이용해 시스템을 객체로 분할할 수 있습니다.
- 첫 번째 방법은 상태 분할의 중심축으로 삼는 방법입니다.
- 두 번째 방법은 책임을 분할의 중심축으로 삼는 방법입니다.
- 훌륭한 객체 지향 설계는 데이터가 아니라 책임에 초점을 맞춥니다.
- 객체의 상태는 구현에 속하며, 구현은 불안정하기 때문에 변하기가 쉽습니다.
- 객체의 책임은 인터페이스에 속합니다.
데이터를 준비하자#
- 데이터 중심의 설계란 객체 내부에 저장되는 데이터를 기반으로 시스템을 분할하는 방법입니다.
- 데이터 중심의 설계에서는 객체가 포함해야 하는 데이터에 집중합니다.
- 필요한 데이터를 준비한 후에에는 다른 객체의 오염시키는 것을 막아야 하며, 이를 구현할 간단한 방법은 접근자(accessor) 과 수정자(mutatotr) 를 추가하는 것입니다.
영화를 예매하자#
- (생략.)
02. 설계 트레이드오프#
- 데이터 중심 설계와 책임 중심 설계의 장단점을 비교하기 위해 캡슐화, 응집도, 결합도 를 사용합니다.
캡슐화#
- 객체를 사용하면 변경 가능성이 높은 부분은 내부에 숨기고 외부에는 상대적으로 안정적인 부분만 공개함으로써 변경의 여파를 통제할 수 있습니다.
- 변경될 가능성이 높은 부분은 구현이라고 부르고 상대적으로 안정적인 부분을 인터페이스라고 부릅니다.
복잡성을 다루기 위한 가장 효과적인 도구는 추상화입니다.- 변경될 수 있는 어떤 것이라도 캡슐화해야합니다. 이는 객체지향 설계의 핵심입니다.
유지보수성은 두려움, 주저함, 저항감 없이 코드를 변경할 수 있는 능력이며 가장 중요한 동료는 캡슐화입니다.
응집도와 결합도#
- 응집도는 모듈에 포함된 내부 요소들이 연관돼 있는 정도를 나타냅니다.
- 결합도는 의존성의 정도를 나타내며 다른 모듈에 대해 얼마나 많은 지식을 갖고 있는지를 나타냅니다.
- 높은 응집도와 낮은 결합도를 가진 설계를 추구함으로써, 설계를 변경하기 쉽게 해줍니다
- 변경의 관점에서 응집도란 변경이 발생할 때 모듈 내부에서 발생하는 변경의 정도로 측정할 수 있습니다.
- 결합도란 한 모듈이 변경되기 위해서 다른 모듈의 변경을 요구하는 정도로 측정할 수 있습니다.
- 캡슐화의 정도가 응집도와 결합도에 영향을 미칩니다.
03. 데이터 중심의 영화 예매 시스템의 문제점#
- 요약하자면, 데이터 중심의 설계가 가진 문제는 캡슐화 위반, 높은 결합도, 낮은 응집도 입니다.
캡슐화 위반#
- 접근자와 수정자에 과도하게 의존하는 설계 방식을 추측에 의한 설계 전략(desing-by-guessing strategy) 라 하며, 추측에 의해 설계를 하므로 압박과 이에 따른 캡슐화의 원칙을 위반하는 설계가 됩니다.
높은 결합도#
- 데이터 중심의 설계는 전체 시스템을 하나의 거대한 의존성 덩어리로 만들어 버리므로, 어떤 변경이라도 발생하고 나면 시스템 전체가 흔들립니다.
낮은 응집도#
- 낮은 응집도는 두 가지 측면에서 설계에 문제가 있습니다.
- 변경의 이유가 서로 다른 코드들을 하나의 모듈에 뭉쳐놓았기 때문에 변경과 아무 상관이 없는 코드들이 영향을 받습니다.
- 하나의 요구사항 변경을 반영하기 위해 동시에 여러 모듈을 수정해야 합니다.
04. 자율적인 객체를 향해#
캡슐화를 지켜라#
- 캡슐화는 설계의 제1원리입니다.
- 이 캡슐화를 잘못하면 여러 문제가 발생합니다.
- '코드 중복'이 발생할 확률이 높습니다.
- '변경에 취약'합니다.
스스로 자신의 데이터를 책임지는 객체#
- 상태와 행동을 객체라는 하나의 단위로 묶는 이유는 객체 스스로 자신의 상태를 처리할 수 있게 하기 위해서 입니다.
- 객체를 설계할 때는 아래 질문을 받아야합니다.
- 이 객체가 어떤 데이터를 포함해야 하는가?
- 이 객체가 데이터에 대해 수행해야 하는 오퍼레이션은 무엇인가?
05. 하지만 여전히 부족하다#
캡슐화 위반#
- 내부 구현 변경이 외부로 퍼져나가는 파급 효과(ripple effect) 는 캡슐화가 부족하다는 명백한 증거입니다.
높은 결합도#
- 캡슐화 위반으로 인해 내부 구현이 외부로 노출된다면, 결합도는 높을 수 밖에 없습니다.
낮은 응집도#
- 하나의 변경이 수용하기 위해 코드의 여러 곳을 동시에 변경해야 한다는 것은 설계의 응집도가 낮다는 증거입니다.
06. 데이터 중심 설계의 문제점#
- 데이터 중심의 설계가 변경에 취약한 이유는 두 가지입니다.
- 데이터 중심의 설계는 본질적으로 너무 이른 시기에 데이터에 관해 결정하도록 강요합니다.
- 데이터 중심의 설계에서는 협력이라는 문맥을 고려하지 않고 객체를 고립시킨 채 오퍼레이션을 결정합니다.
데이터 중심 설계는 객체의 행동보다는 상태에 초점을 맞춘다#
- 데이터 중심의 설계는 너무 이른 시기에 데이터에 대해 고민하기 때문에 캡슐화에 실패하게 됩니다.
데이터 중심 설계는 객체를 고립시킨 채 오퍼레이션을 정의하도록 만든다.#
- 객체지향 애플리케이션을 구현한다는 것은 협력하는 객체들의 공동체를 구축한다는 것을 의미합니다.
- 데이터 중심 설계에서 초점은 객체의 외부가 아니라 내부로 향합니다.