포스트

4장. 설계 품질과 트레이드오프

4장. 설계 품질과 트레이드오프


❐ 1. 데이터 중심의 영화 예매 시스템


1-1. 데이터(상태) 중심 vs 책임 중심

비교하기

  • 데이터 중심
    • 세부사항이 객체의 인터페이스에 스며들게 되어 캡슐화 원칙이 무너진다.
    • 결국 변경에 취약한 설계가 된다.
  • 책임 중심
    • 상대적으로 변경에 안정적인 설계를 얻을 수 있게 된다.
  • 근본적인 차이점은 캡슐화를 다루는 방식
    • 캡슐화의 정도가 객체의 응집도와 결합도를 결장한다.



❐ 2. 데이터 중심 설계의 문제점


2-1. 캡슐화를 위반한 설계는 변경에 취약하다.

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

  1. 데이터 중심의 설계는 본질적으로 너무 이른 시기에 데이터에 관해 결정하도록 강요한다.
  2. 데이터 중심의 설계에서는 협력이라는 문맥을 고려하지 않고 객체를 고립시킨 채 오퍼레이션을 결정한다.


2-2. 데이터 중심 설계는 행동보다는 상태에 초점을 맞춘다.

시작부터 잘못됐다.

  • 데이터 중심 설계를 시작할 때 애초에 “이 객체에 포함해야 하는 데이터가 무엇인가?”라는 질문을 던짐
  • 이건 처음부터 데이터에 관해 결정하도록 강요하기 때문에 너무 이른 시기에 내부 구현에 초점을 맞춤


데이터 중심의 관점에서 객체는 그저 단순히 데이터의 집합체일 뿐이다.

  • 이로 인해 접근자와 수정자를 과도하게 추가하게 된다.
  • 이 데이터 객체를 사용하는 절차를 분리된 별도의 객체 안에 구현하게 된다.


2-3. 데이터 중심 설계는 객체를 고립시킨 채 오퍼레이션을 정의하도록 만든다.

객체지향 설계의 무게 중심은 항상 객체의 외부에 맞춰져야 한다.

  • 객체 내부에 어떤 상태를 가지고 그 상태를 어떻게 관리하는가는 부가적인 문제다.
  • 데이터 중심 설계는
    • 객체의 구현이 이미 결정된 상태에서 다른 객체와의 협력 방법을 고민한다.
    • 결국 이미 구현된 객체의 인터페이스를 억지로 끼워 맞출수 밖에 없다.


객체의 인터페이스에 구현이 노출되게 된다.

  • 협력이 구현 세부사항에 종속돼 있게 된다.
  • 결국 객체의 내부 구현이 변경됐을 때 협력하는 객체 모두가 영향을 받을 수밖에 없다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.