오브젝트 - 2

※ 이글은 독자를 전혀 배려하지 않고 그냥 제가 정리하고 싶은 내용 정리하는 글입니다.

86p~129p

 

역할

- 역할은 객체가 참여할 수 있는 일종의 슬롯 (추상 클래스나 인터페이스로 구현)

- 협력에 참여하는 후보가 여러 종류의 객체에 의해 수행될 필요가 있다면 그 후보는 역할, 아니라면 객체

- 설계시 역할을 사용할지, 객체를 사용할지 애매하다면, 단순하게 객체로 시작하고, 책임과 협력을 정제해가면서 필요한 순간에 객체로부터 역할을 분리해내는 것이 가장 좋은 방법이다.

- 객체는 다양한 역할을 가질 수 있지만, 특정한 협력 안에서는 오직 하나의 역할로 보여진다.

 

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

객체지향 설계의 핵심은 역할, 책임, 협력

- 역할: 대체 가능한 책임의 집합

- 책임: 객체가 다른 객체와 협력하기 위해 수행하는 행동

- 협력: 애플리케이션의 기능을 구현하기 위해 메시지를 주고받는 객체들 사이의 상호 작용

 

객체지향 설계의 품질 척도: 캡슐화, 응집도, 결합도

- 캡슐화: 변경가능성이 높은 구현을 객체 내부로 숨기는 기법

- 응집도: 모듈 안의 요소들이 하나의 적을 위해 긴밀히 협력하는가

- 결합도: 모듈간 의존성의 정도

 

캡슐화 

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

- 객체의 속성을 외부로 제공하고 있지 않더라도, 메서드의 이름으로 속성을 유추할 수 있다면 캡슐화를 위반한 것이다.

- 즉, 캡슐화는 '변경 가능한 모든 요소'를 숨기는 것을 의미한다.

 

좋은 설계

높은 응집도와 낮은 결합도.

응집도의 결합도는 캡슐화의 정도에 영항을 받는다.

 

단일 책임 원칙(SRP)

클래스는 단 한가지의 변경 이유만을 가져야 한다.

단일 책임 원칙에서의 '책임'은 위에서 이야기한 책임(행동)을 의미하는 것이 아닌, 변경이라는 더 추상적인 개념을 의미한다고 보면 된다.

 

코드의 중복은 악의 근원이다.