설계 품질과 트레이드 오프

객체지향 설계

올바른 객체에게 올바른 책임을 할당 하면서 낮은 결합도와 높은 응집도를 가진 구조를 창조하는 활동

• 객체지향 설계의 핵심은 책임.
• 책임을 할당하는 작업은 응집도와 결합도 같은 설계 품질과 깊이 연관되어 있다.

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

• 객체의 상태가 아닌 객체의 행동에 초점을 맞춰라.

데이터 중심 VS 책임 중심의 관점

데이터 중심의 관점에서의 객체 : 자신이 포함하고 있는 데이터를 조작하는 데 필요한 오퍼레이션을 정의

객체의 상태는 구현이다.

구현은 불안정하기 때문에 변하기 쉽다. 상태를 각체 분할의 중심 축으로 삼으면 구현에 관한 세부사항이 객체의 인터페이스에 스며들게 되어 캡슐화의 원칙이 무너진다.

즉, 상태 변경은 인터페이스의 변경을 초래하며, 이 인터페이스에 의존하는 모든 객체에게 변경의 영향이 퍼지게 된다. 취약하다.

---

책임 중심의 관점에서의 객체 : 객체는 다른 객체가 요청할 수 있는 오퍼레이션을 위해 필요한 상태를 보관

객체의 책임은 인터페이스다.

객체는 책임을 드러내는 안정적인 인터페이스 뒤로 책임을 수행하는 데 필요한 상태를 캡슐화함으로써 구현 변경에 대한 파장이 외부로 퍼져나가는 것을 방지한다. 상대적으로 변경에 안정적이다.

설계 트레이드 오프

1) 캡슐화
코드의 변경 가능성이 큰 부분을 객체 내부로 숨기는 추상화 기법이다.

2)응집도와 결합도

응집도

모듈에 포함된 내부 요소들이 연관돼 있는 정도. 모듈 내 요소들이 하나의 목적을 위해 긴밀하게 협력함을 나타냄.
응집도가 높을수록 변경의 대상과 범위가 명확해지기 때문에 코드를 변경하기 쉬워진다.

결합도

의존성의 정도. 한 모듈이 변경되기 위해서 다른 모듈의 변경을 요구하는 정도.
다른 모듈에 대해 꼭 필요한 지식만 알고 있다면 낮은 결합도를 가진다.

단일 책임 원칙 (SRP: Single Responsibility Principle)

출처 : https://yoongrammer.tistory.com/96

---

클래스를 변경하는 이유는 단 한 가지여야 한다.

단일 책임 원칙(SRP: Single Responsibility Principle)은 다섯 가지 SOLID 애자일 원칙 중 하나입니다.

클래스를 변경하는 이유가 한 가지이기 위해서는 하나의 액터에 대한 책임만 가지고 있어야 합니다.

여기서 책임은 하나의 특정 액터를 위한 기능 집합이고, 액터란 기능(=클래스 ,모듈)을 사용하는 주체입니다.

캡슐화를 위해서 외부에서 접근하는 함수명을 제어하는가? 뭐가 우선되어야 하는가?

  
이 책에서는 함수명에서 그 객체가 가지고 있는 상태값을 노출하면 안된다고 한다.
만약, 사각형의 가로와 세로의 길이를 동일한 크기만큼 늘린다면?
public void extendHeightWidth(int n){} // 추상화는 생각 안하나
public void enlarge(int n){}   // 가로, 세로가 동시에 동일한 크기만큼 늘린다는 뉘앙스를 주는가?

클린코드 책에서는 함수명이 길어도 상관없으니, 이야기를 읽듯이 최대한 자세하게 함수명을 작성하라고 한다.

예를 들어 비밀번호 변경 함수를 작성할 시, 초기화 과정이 있으니
checkPassword() {} → checkPasswordAndInitializeSession() {}