결합도와 응집도를 합리적인 수준으로 유지할 수 있는 원칙

• 객체의 상태가 아니라 객체의 행동에 초점을 맞추는 것

• 행동에 초점을 맞춘다는 의미는 객체의 책임에 초점을 맞춘다는 것이다.

4장에서는 영화 예매 시스템을 책임이 아닌 상태를 표현하는 데이터 중심의 설계를 살펴보고 객체지향적 구조와 어떤 차이점이 있는지 살펴본다.

01 데이터 중심의 영화 예매 시스템

• 책임에 초점을 맞춰야 하는이유는 변경에 안정적인 설계를 얻을 수 있다.

• 데이터 중심 설계는 객체의 내부에 저장해야하는 ’데이터가 무엇인가‘ 라는질문으로 시작한다.

근데 데이터 중심이라도 인터페이스쓰면 비슷한거 아닌가?

02 설계 트레이드 오프

캡슐화

• 변경될 가능성이 높은 곳을 구현이한다.

• 안정적인 부분을 인터페이스라고한다

• 외부에서는 인터페이스에만 의존하도록 함

• 설계가 필요한 이유는 요구사항이 변경되기 때문

• 변경될 수 있는 모든 것을캡슐화하라

• 유지보수성 :두려움없이, 주저함 없이, 저항감 없이 코드를 변경할 수 있는 능력을 말한다

• 캡슐화는 우리는 좋은 코드로 안내한다. 그러므로 가장 중요한 제1원리다.

응집도와 결합도

• 응집도는 모듈에 포함된 내부 요소들이 연관돼 있는 정도를 나타냄

• 결합도는 의존성의 정도를 나타태며 다른 모듈에 대해 얼마나많은 지식을 갖고 있는지를 나타냄

• 좋은 설계는 높은 응지도와 낮은 결합도를 가진 모듈로 구성된 설계를 의미한다.

• 응집도가높고 결합도가낮으면 코드를 변경하기가 쉬워진다.

• 변경될 확률이 매우 적은 안정적인 모듈에 의존하는 것은 결합도가 높아도 문제가 되지 않는다. (표준라이브러리나, 매우 성숙한 프레임워크등)

• 직접 작성한 코드는 그렇지 않으므로 낮은 결합도를 유지하도록 노력해야함

• 캡슐화의 정도가 응집도와 결합도에 영향을 미친다.

03 데이터 중심의 영화 예매 시스템의 문제점

• 데이터 중심 설계는 캡슐화를 위반하여 높은 결합도와 낮은 응집도를 가진다.

• 데이터 중심 설계는 높은 결합도를 가지는데, 본문에서는 ReservationAgency가모든 데이터 객체에 의존한다.

• 낮은 응집도로 인해 수정이 필요한 경우 여러개의파일을 수정해야한다. Ex) 할인정책 추가

단일 책임원치 (SRP)

> 클래스는 단 한가지의 변경 이유만 가져아한다. (응집도 높이기)

04 자율적인 객체를 향해

캡슐화를 지켜라

• 캡슐화는 설계의 제 1원리이다.

스스로 자신의 데이터를 책임지는 객체

• 객체는 단순 데이터제공자가 아닌 협력에 참여하며 자신의 책임을 수행한다.

• 객체 설계시 어떤 데이터를 포함해야 하는가와 수행해야 하는 오퍼레이션이무엇인가를 고민해야한다.

05 하지만 여전히 부족하다

캡슐화 위반

• 코드 변경시의 파급효과가 자신을 너어서면 캡슐화가 깨진것이다.

• 내부구현이 외부에 노출 되는 것도 캡슐화가 되지 않았음을 의미한다.

• 캡슐화는 변경 될 수 있는 모든 것을 감추는 것을 의미한다. 설계에서 변하는 것이 무엇인지 고려하고 변하는 개념을 캡슐화해야한다.

높은 결합도

• 이또한 캡슐화 원칙을 지키지 않았기 때문이다.

낮은 응집도

• 이것도 캡슐화를 위반했기때문이다.

06 데이터 중심 설계의 문제점

• 데이터 중심의 설계는 본질적으로 너무 이른 시기에 데이터에 관해 결정하도록 강요한다.

• 데이터 중심의 설계에서는 협력이라는 문맥을 고려하지 않고 객체를 고립 시킨채 오퍼레이션을 결정한다.

이전 게시글

• 오브젝트 1장 https://careerly.co.kr/comments/92380

• 오브젝트 2장 https://careerly.co.kr/comments/92467

• 오브젝트 3장 https://careerly.co.kr/comments/92725