[오브젝트] Chapter5 책임 할당하기

오브젝트

조영호님의 책 오브젝트를 보며 정리한 내용입니다.

문제가 될 시 해당글 삭제하겠습니다.

---

책임 주도 설계

1. 데이터보다 행동(외부에서 제공하는 행동)을 먼저 결정하라
2. 협력이라는 문맥 안에서 책임을 결정하라
   - 책임은 객체의 입장이 아니라 객체가 참여하는 협력에 적합해야 한다.
   - 협력에 적합한 책임을 수확하기 위해서, 메시지를 결정한 후에 객체를 선택해야 한다.
   (메시지가 클라이언트의 의도를 표현한다)

책임 할당을 위한 패턴(GRASP?)

1. 도메인 개념에서 출발하기
   - 설계를 시작하기 전에 도메인에 대한 대략적인 모습을 그려 보는 것이 유용하다.
   - 도메인 개념들을 책임 할당의 대상으로 사용하면 코드에 도메인의 모습을 투영하기가 쉬워진다.
2. 정보 전문가에게 책임을 할당하라
   질문1 : 메시지를 전송할 객체는 무엇을 원하는가?
   질문2 : 메시지를 수신할 적합한 객체는 누구인가?(Infomation Expert 패턴)
3. 높은 응집도(High Cohesion 패턴)와 낮은 결합도(Low Compling 패턴)
   - 설계 == 트레이드오프(어느 한부분의 품질을 변경하는게, 다른 곳의 품질을 결정할 때)
   - 앞에서 설명했던 상태가 아닌 행동을 기준으로 설계를 하는것으로, 이를 통해서 높은 응집도, 낮은 결합도를 가진 객체를 생성할 수 있다.
4. 창조자에게 객체 생성 책임을 할당하라
   - Creator 패턴 : 어떤 방식으로든 생성되는 객체와 연결되거나 관련될 필요가 있는 객체에 해당 객체를 생성할 책임을 맡기는 것이다.
   - ex) 객체 A를 생성해야 할 때 어떤 객체에게 객체 생성 책임을 할당해야 하는가?
          아래 조건을 가장 많이 만족하는 객체 B에게 생성 책임을 할당해야 한다.
   - B가 A 객체를 포함하거나 참조한다.
   - B가 A 객체를 기록한다.
   - B가 A 객체를 긴밀하게 사용한다.
   - B가 A 객체를 초기화하는 데 필요한 데이터를 가지고 있다(이 경우 B 는 A 에 대한 정보 전문가이다)
5. 같은 인터페이스를 수행할 때, 구현체가 다르다면 다형성 패턴(Polymorphism) 을 사용하라!
   - ex) 영화를 예매할 때, 할인율을 구해야 한다. 할인율의 종류는(금액, 비율) 2가지가 있고, 할인율을 계산하는 인터페이스는 동일하다.
           그러다면 금액, 비율 할인율의 구현체는 할인율이라는 인터페이스를 상속받고, 예매할 때 할인율이라는 인터페이스를 사용하면 보다 객체지향적인 설계라 부를 수 있다.\
6. 변경 or 확장을 캡슐화하도록 책임을 할당하는 것 변경 보호 패턴(Protected Variations)
   - 객체가 사용하는 인터페이스를 호출하는 형태의 설계에서는 캡슐화를 통해서 변경, 확장이 용이하다.

변경의 이유가 하나 이상인 클래스에 위험 징후를 나타내는 패턴

1. 객체가 변경되야 하는 이유의 갯수를 살펴보자.
   - 변경의 이유를 기준으로 분리하자.
2. 인스턴스 변수가 초기화되는 시점을 살펴보자.
   - 응집도가 높은 객체는 인스턴스를 생성할 때 모든 속성을 초기화한다.
   - 응집도가 낮은 객체는 속성이 초기화되는 시점이 나뉘기 때문에, 함께 초기화되는 속성을 기준으로 코드를 분리해야 한다.
3. 메서드들이 인스턴스 변수를 사용하는 방식을 살펴보자.
   - 모든 메서드가 객체의 모든 속성을 사용한다면 객체의 응집도가 높다.
   - 메소드들이 상용하는 속성에 따라서 그룹이 나뉜다면 객체 응집도가 낮다. 때문에, 속성그룹 / 해당그룹/ 메서드그룹 기준으로 코드를 분리해야 한다.

변경과 유연성

개발자가 변경에 대비하는 2가지방법
1. 코드를 이해하고 수정하기 쉽도록 최대한 단순하게 설계하는 것
2. 코드를 수정하지 않고도 변경을 수용할 수 있도록 코드를 더 유연하게 만드는 것(상속보다는 합성)

-> 너무 이상적이야,,,

하지만 책임주도 설계는 쉽지 않은 것이다, 그에 대한 대안은, 다음과 같다.
-일단은 절차지향적으로 코드를 짜라! 그다음 다음의 절차를 밟아 나가라!~!!!!!!!!!!!!!!!!!!

-> 이거지~~

 

1. 매서드 응집도 해결(리팩토링)
   - 이해하기 쉽고 수정하기 쉬운, 소프트웨어로 개선하기 위해 겉으로 보이는 동작을 바꾸지 않은 채 내부 구조를 변경하는 것!
   - 너무 긴 메서드는 응집도가 낮아 이해하기도, 재사용하기도, 변경하기도 어려운 코드를 몬스터 메서드라고 한다.
   - 이러한 메서드는 작게 분해해서 각 메서드의 응집도를 높이는 리팩토링이 필수적이다!
   -> 이러한 몬스터 클래스를 분해해서 외부에서 필요한 소수의 인터페이스만 외부에 노출시키는 방법이 응집도를 높이는 최적의 방법이다!
2. 객체를 자율적으로!
   - 객체를 자율적으로, 응집도가 높게 만들어주기 위해서는 각 메서드가 사용하는 데이터를 정의하고 있는 클래스(infomation Expert)에 각 메서드를 옮겨야 한다.