[오브젝트] 9일차. 108-118pg | 캡슐화, 응집도, 결합도

9일차.

 
오브젝트: 코드로 이해하는 객체지향 설계[2주차_수요일]
108-118pg 
 
 

#요약 

 **Chapter 04. 실제 품질과 트레이드오프** 
2) 영화를 예매하자
 

02. 설계 트레이드오프

1) 캡슐화

- 한 곳에서 일어난 변경이 전체 시스템에 영향을 끼치지 않도록 파급효과를 적절하게 조절할 수 있는 장치 제공

 - 변경될 가능성이 높은 부분은 구현, 상대적으로 안정적인 부분은 인터페이스

 

2) 응집도와 결합도

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

- 모듈 내의 요소들이 하나의 목적을 위해 긴밀하게 협력한다면 그 모듈은 높은 응집도를 가진다.

- 변경의 관점에서 응집도란 변경이 발생할 때 모듈 내부에서 발생하는 변경의 정도로 측정할 수 있다.

- 응집도가 높을수록 변경의 대상과 범위가 명학해지기 때문에 코드를 변경하기 쉬워진다.

 

 

- 결합도 : 의존성의 정도를 나타내며 다른 모듈에 대해 얼마나 많은 지식을 갖고 있는지를 나타내는 척도.

- 결합도는 한 모듈이 변경되기 위해서 다른 모듈의 변경을 요구하는 정도로 측정할 수 있다.

 

- 캡슐화를 지키면 모듈 안의 응집도는 높아지고 모듈 사이의 결합도는 낮아진다.

 

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

1. 캡슐화 위반

2. 높은 결합도

3. 낮은 응집도

 

1) 캡슐화 위반

- 추측에 의한 설계전략 : 접근자와 수정자에 과도하게 의존하는 설계 방식 : 객체가 사용될 협력을 고려하지 않고 객체가 다양한 상황에서 사용될 수 있을 것이라는 막연한 추측을 기반으로 설계를 진행한다.

 

2) 높은 결합도

- 객체 내부의 구현이 객체의 인터페이스에 드러난다는 것은 클라이언트가 구현에 강하게 결합된다는 것이다.

- 데이터 중심 설계는 객체의 캡슐화를 약화시켜 클라이언트가 객체의 구현에 강하게 결합된다.

 

3) 낮은 응집도

- 서로 다른 이유로 변경되는 코드가 하나의 모듈 안에 공존할 때

- 단일 책임 원칙(Single Responsibility Principle, SRP) : 클래스는 단 한 가지의 변경 이유만 가져야 한다는 것.

 

04. 자율적인 객체를 향해

1) 캡슐화를 지켜라

- 객체는 자신이 어떤 데이터를 갖고 있는지 내부에 캡슐화하고 외부에 공개하면 안됨.

- 속성의 가시성을 private으로 설정했다고 해도 접근자와 수정자를 통해 속성을 외부로 제공하고 있다면 캡슐화를 위반하는 것이다.

 

 

 

 

#발췌

 동일한 객체라고 하더라도 객체가 참여하는 협력에 따라 객체의 얼굴은 계속해서 바뀌게 된다. 

코드를 완성한 그 순간부터 코드를 수정할 준비를 해야 한다.