[오브젝트 - 기초편] 책임 할당하기

본 게시글은 '오브젝트 - 기초편 강의 | 조영호 - 인프런'을 수강하고 학습한 내용을 정리한 게시글입니다.

---

시스템 내부 상태 변경 정리

애플리케이션 기능이 객체 협력 설계에 필요한 문맥을 제공
-> 기능이라는 문맥 안에서 협력을 잘 설계하기 위해서는 시스템 내부에서 일어나는 상태 변경 정리 필요

표현적 차이를 줄이기 위한 단계

• 애플리케이션 기능의 실행은 도메인 개념의 상태나 구조를 변경시킴
  • ex) 상영 예매 기능 수행 후, 시스템 내부에서 '예매' 생성 & '예매'를 '상영'과 연결 & 생성된 예매 반환
• 시스템 내부에서 일어나는 상태 변경을 도메인 모델에 기반한 개념들의 집합으로 가시화하는 것이 중요

사영 예매 협력 설계

시스템 실행 결과를 가시화했다면, 상태 변경을 기반으로 객체 협력 설계 가능

예매를 생성할 책임을 어떤 객체에게 할당할 것인가?

1. 애플리케이션의 기능을 시스템이 수행할 책임으로 간주하기
2. 이 시스템의 책임을 객체의 책임으로 변환
   • 이제 초점은 '기능을 시작하는 책임'을 어떤 객체에게 할당할지를 결정하는 문제로 전환됨
   • 책임을 수행할 후보 객체를 찾을 때는 도메인 모델 안에 책임을 할당하기에 적합한 개념이 존재하는지 살펴보아야 함
     • ex) 도메인 모델 안에 영화, 상영, 할인 정책, 할인 조건 중 '상영 예매'할 책임을 할당하기에 적합한 객체가 있는지 살펴보기
3. 객체에게 책임 할당
   • 어떤 객체에게 책임을 할당할지 GRASP 패턴 참고
   • 도메인 개념 중에 적절한 '정보 전문가'에게 할당 (정보 전문가 패턴에 대해서는 바로 다음에 다룸)
     • ex) 예매 생성을 위해 필요한 정보를 가장 많이 알고있고 그 정보에 대해 가장 적절하게 대답할 수 있는 객체?
       • => '상영'
       • 사용자가 예매하는 대상은 영화가 아닌 상영이고, 상영 시간이 예매 개념을 설명하는 가장 중요한 정보이기 때문
       • 상영과 영화 사이에는 관계가 존재하므로, 영화 제목이나 정가 등의 정보가 필요하다면 영화와 협력을 통해 정보를 얻을 수 있음
4. 해당 클래스 안에 책임을 구현
   • 객체지향 설계에 따라 행동을 구현하면서 구현에 적합한 데이터를 선택
   • 책임을 원활하게 수행할 수만 있다면 데이터는 어떤 방식으로 구현해도 무방

정보와 책임 할당 - 정보 전문가 패턴

• 문제: 책임을 객체에게 할당하는 일반적인 원칙은 무엇인가?
  • 어떤 책임을 객체에게 할당할 때 적용할 수 있는 가장 일반적인 원칙을 찾는 문제를 해결하려고 함
• 해결 방법: 책임을 수행하는데 필요한 정보를 가장 많이 알고 있는 객체에게 할당하라
  • 정보 전문가 패턴은 책임 할당 문제를 해결하기 위해 적용할 수 있는 가장 일반적이고 보편적인 해결방법
  • => 책임 할당 후보를 찾기 위해서 가장 먼저 적용해보자

정보(information)

• 정보는 '데이터'가 아니라 '행동'
• 어떤 상태를 수정하거나 질문에 답하는 '책임'

정보 전문가 찾기

• '정보 전문가'란 어떤 정보가 필요할 때 이 정보에 대한 질문에 답을 해줄 수 있는 객체를 의미
  • 해당 데이터를 갖고 있을 필요가 없음. 질문에 대답만 할 수 있으면 됨
• ex) 나이에 대한 요청에 응답은 '학생'이라는 본인이 직접 응답하는 것이 적절할 것 -> '학생'이 정보 전문가

정보 전문가의 구현 방식 3가지

• 정보 전문가 객체가 해당 데이터를 '인스턴스 변수'로 갖는 형태
  • ex) answerAge라는 메서드를 Student 클래스 내부에 두고, 이를 구현하면서 적절한 데이터(필드) 추가
• 정보 전문가가 데이터를 직접 저장하지 않고, 책임을 실행하는 도중에 '필요한 정보를 생성'하는 형태
  • ex) age 대신, birthdate를 저장하여 answerAge에서는 나이를 현재 년도에 따라 계산하여 반환하도록 함으로써, 매년 age를 업데이트 해야 하는 귀찮음 제거
• 정보 전문가가 '다른 객체와 협력'해서 데이터를 제공하는 형태
  • ex) Student가 SchoolRecord라는 객체에게 요청을 전송하여 나이 정보를 얻어오고 이를 반환

=> 위 3가지 방식은 서로 다른 유형의 데이터를 이용해서 동일한 정보를 제공하고 있음
=> 정보는 데이터가 아니다
=> 어떤 방식으로 구현을 하든 나이를 문의하는 외부 객체 입장에서 위 3가지 객체는 완전히 동일

• 하지만, 객체 내부 구현은 완전히 다름 (데이터 저장 방식, 데이터 사용해서 나이를 구하는 방식이 모두 다름)
• 정보는 행동 관점이기 때문에 내부의 데이터가 다르더라도 외부에서 보이는 행동은 동일
  • 객체 내부의 데이터 저장 방식 & 메서드 수행 방식 = '구현'
  • 외부에서 객체가 행동을 수행하도록 요청할 수 있는 메서드의 시그니처 = '인터페이스'
• 위 3가지 구현 방식은 인터페이스는 동일하지만 구현은 다름

=> 책임만 동일하다면 내부 구현 방식은 자유롭게 선택할 수 있음
=> 책임만 잘 정의하면 내부 구현은 언제라도 자유롭게 바뀔 수 있음
(= 행동을 먼저 결정, 데이터를 마지막에 결정하는 이유)

 

+) 애매하면 목적어에 책임을 할당하라

• ex) 책임: '상영을 예매하다'
  • 목적어인 '상영'에 예매 책임을 할당
  • 이후, 목적어를 주어로 바꾸면 능동적으로 책임을 수행하도록 만들 수 있음 ('상영이 예매하다')

더 좋은 판단 기준은 없을까??

---

설계 트레이드 오프 - 창조자 패턴과 낮은 결합도 패턴

창조자(CREATOR) 패턴

객체지향 설계를 하다보면 예매를 생성하는 예제처럼 다른 객체를 생성할 책임을 할당해야 하는 경우가 빈번하게 발생
=> '창조자(CREATOR)' 패턴 적용하기 용이

• 문제: 새로운 인스턴스를 생성하는 책임을 어떤 객체에게 할당할 것인가?
• 해결 방법: 다음 중 한 가지라도 만족할 경우 A의 인스턴스를 생성할 책임을 B에게 할당하라
  • B가 A를 포함하거나 참조
  • B가 A를 기록
  • B가 A를 긴밀하게 사용
  • B가 A를 초기화하는 데 필요한 정보를 알고 있음
  • => 즉, 생성되는 객체와 밀접한 관계를 맺고 있는 객체에게 생성 책임 할당

정보 전문가 패턴 관점에서 '예매 생성' 책임을 '상영'에게 할당했었음.
-> 이번엔 창조자 패턴 관점에서 이 선택이 옳았는지 확인해보자

• 영화는 예매를 생성할 때 필요한 초기화 정보인 '영화의 제목, 정가, 할인 금액'을 알고 있음 => 창조자 패턴의 4번째 조건 만족 => 생성 책임 할당하기 적합함
• 상영은 예매를 생성할 때 필요한 정보인 '상영 시간'을 알고 있음 => 창조자 패턴의 4번째 조건 만족
  • 뿐만 아니라, 상영은 이미 예매를 참조(연결)하고 있음 => 상영은 예매를 잘 알고 있는 상태 => 창조자 패턴의 1번째 조건 만족
  • => 영화보다 더 많은 조건을 만족하고 있으므로 생성 책임 할당하기에 영화보다 더 적합함
  • => 상영과 예매를 연결하는 구조는 영화에 연결했을 때보다 낮은 결합도를 가짐
  • 상영은 영화와도 이어져 있기 때문에, 영화에 대한 정보를 얻어오는데에도 문제가 없음

두 객체 사이의 관게 안예는 '결합도'라는 개념이 숨겨져 있음

결합도

• 객체들이 서로 연관되어 있는 정도
• 책임을 할당할 때는 가급적이면 전체적으로 결합도가 낮아지는 방향으로 책임을 할당해야 함
• 이를 GRASP에서 '낮은 결합도(LOW COUPLING)' 패턴이라고 함

낮은 결합도(LOW COUPLING) 패턴

• 문제: 어떻게 낮은 의존성을 유지하고, 변경에 따른 영향을 줄이면서, 재사용성을 높일 수 있을까?
• 해결 방법: 설계의 전체적인 결합도를 낮게 유지할 수 있도록 책임을 할당하라

창조자 패턴을 다시 보면, 4가지 조건 중 1~3번째 조건은 '낮은 결합도'를 의미하고, 4번째 조건은 '정보 전문가'를 의미하고 있음을 알 수 있음
=> 창조자 패턴 = 낮은 결합도 패턴 + 정보 전문가 패턴

• 상영에게 예매 생성 책임을 할당할 경우, 상영과 예매 사이에는 이미 연결 관계가 존재하기 때문에 결합도에 변화가 없음
• 반면, 영화에게 예매 생성 책임을 할당할 경우, 새로운 관계가 추가되어 결합도 상승 => X
• 낮은 결합도가 중요한 이유?
  • 수정하기 쉬운 설계를 만들기 위해
  • 의존성 = 변경 가능성
  • 영화에 예매 생성 책임을 할당한 설계에서는 영화 수정 시 상영과 예매가 함께 수정될 수 있음 => 결합도가 높음

결합도가 낮은 설계를 선택하라

 

=> 낮은 결합도 패턴은 책임을 할당할 때마다 설계의 품질을 판단하기 위해 적용할 수 있는 평가 기준
=> 책임 할당할 때마다 전체적인 설계의 결합도를 낮출 수 있는 더 좋은 방법은 없는지 고민해보자

---

설계 트레이드 오프 - 높은 응집도

높은 응집도(HIGH COHESION) 패턴

• 문제: 어떻게 낮은 결합도를 유지하고, 변경에 따른 영향을 줄이면서, 재사용성을 높일 수 있을까?
• 해결 방법: 높은 응집도를 유지하도록 책임을 할당하라
• 높은 응집도의 의미
  • 유사한 책임들이 함께 모여있을 경우, 응집도가 높음
  • 한 요소의 책임들이 얼마나 강력하게 관련되고 집중되어 있는가
  • 연관성 높은 책임들을 가지면서 너무 많은 일을 하지 않는 객체에 책임 할당
• => 서로 밀접한 관련성을 가진 책임들만 같은 객체에게 할당해야 함

영화 예매 예제

상영을 예매하는 책임을 완수하기 위해서는 예매를 생성해야 하고, 예매를 생성하기 위해서는 영화 가격에 대한 정보가 필요함

=> 예매 생성을 담당하는 상영에 영화 가격을 계산하는 책임까지 추가하면 상영이 너무 많은 책임을 맡게 됨
=> 예매 책임과 영화 가격 계산 책임은 서로 상관이 없음
=> 상영의 부담을 낮추기 위해서는 외부 객체에게 영화 가격 계산을 요청해야 함 = 새로운 책임
(= 책임 주도 설계 단계에서의 6단계)

 

영화 가격 계산이라는 새로운 책임을 할당하기 위한 적절한 객체를 찾기 위해, 먼저 정보 전문가 패턴을 적용해보자

• 가격 계산을 위해 필요한 정보를 알고 있는 전문가는?
  • 가장 중요한 정보는 '영화의 정가'
  • 이에 대답할 수 있는 후보는 '영화'
• 할인 요금 정보도 필요
  • 이미 영화는 할인 정책과 할인 조건과도 관계를 맺고 있기 때문에 할인 요금 계산을 위해 관계를 추가할 필요 X
  • 낮은 결합도 패턴 관점에서도 가격을 계산하는 책임을 할당하는게 합리적
• 높은 응집도가 중요한 이유?
  • 역시, 수정하기 쉬운 설계를 만들기 위함
  • 서로 연관성이 적은 책임이 하나의 객체 안에 모여있는 경우(낮은 응집도..) 코드를 읽을 때 수정할 부분을 찾기 어려움
  • 어떤 책임을 부여한 코드를 수정하면, 이 책임과 아무 상관없는 다른 코드가 영향을 받을 가능성도 커짐

응집도가 높은 설계를 선택하라

• 높은 응집도 패턴은 낮은 결합도 패턴과 함께 설계의 품질을 평가하기 위한 기준으로 사용됨
• 후보 객체 중 어떤 객체에게 책임을 할당할지 판단하기 어렵다면, 설게 전체적으로 응집도를 높일 수 있는 객체에게 책임을 할당하자

---

유연한 설계 - 다형성

영화 가격을 계산하기 위해서는 할인 금액을 계산해야 함. 이 책임까지 영화에게 할당하면 응집도가 낮아짐.. => 외부에 요청하자
이번에는 할인 금액을 계산하기 위해 영화와 협력해야 하는 객체들을 설계해보도록 하자

• 할인 금액을 계산할 책임을 담당할 '정보 전문가'는?
  • 도메인 모델에서 이미 할인 금액을 계산하는 규칙을 '할인 정책'이라고 불렀음
  • => 할인 금액을 계산하는 책임을 할당할 객체에게 '할인 정책(DiscountPolicy)'라는 이름을 붙이면 표현적 차이를 줄일 수 있음
  • DiscountPolicy에 금액할인 계산을 위한 calculateAmountDiscount와 비율 할인 계산을 위한 calculatePercentDiscount를 인터페이스로 지정

낮은 응집도 문제 - DiscountPolicy가 금액/비율 할인 모두를 책임

• 높은 응집도와 낮은 결합도 측면에서 설계 품질 평가!
  • 현재 설계는 DiscountPolicy의 응집도가 낮다는 문제가 있음..
  • DiscountPolicy 내부에 구현된 비율 할인 정책 계산 로직과 금액 할인 정책 계산 로직은 할인 정책의 한 종류라는 공통점이 있지만,
  • 필요한 데이터도 다를 뿐만 아니라 로직도 서로 공유하지 않음
  • => DiscountPolicy는 서로 상관없는 두 로직을 함께 포함하고 있음 => 낮은 응집도..
  • => 새로운 할인 정책이 추가되면 새로운 메서드를 추가해야 할 것 -> DiscountPolicy 내부 수정해야 함 + 영화에서의 분기문 추가
  • = 낮은 응집도 + 높은 결합도 문제

 

 

GRASP 패턴에서는 유사하지만 다른 방식의 행동을 추가하고 싶을 때 다른 코드에 영향을 주지 않고도 쉽게 코드를 확장할 수 있는 패턴을 제공
=> 다형성(POLYMORPHISM) 패턴

다형성(POLYMORPHISM) 패턴

• 문제: 타입을 기반으로 유사하지만 서로 다르게 행동할 때, 조건문을 사용하지 않고 변하는 행동을 어떻게 처리할 것인가?
  • 다형성 패턴을 언제 적용해야 하는가?: 타입을 기반으로 유사하지만 서로 다르게 행동할 때
    • 금액 할인 정책과 비율 할인 정책은 서로 다르게 동작하는 서로 다른 타입
    • 두 타입은 '할인 요금 계산'이라는 유사한 행동을 서로 다른 방식으로 구현
  • 조건문을 사용하지 않고 변하는 행동을 어떻게 처리할 것인가?
    • 새로운 할인 정책 추가에 따라 영화(Movie)에서는 조건문이 추가되었음..
    • => 조건문 없이도 여러 행동을 처리할 수 있는 방법이 필요
• 해결 방법: '다형적인 메시지'를 이용해서 (2), '행동이 변하는 타입들에게 각 행동을 다루기 위한 책임을 할당하라' (1)

(1) 행동이 변하는 타입들에게 각 행동을 다루기 위한 책임을 할당하라?

서로 다른 행동을 서로 다른 클래스로 구현

• 할인 정책 안에는 서로 다른 방식으로 동작하는 두 가지 행동(메서드)이 포함되어 있음
• 할인 정책과 협력하는 영화의 관점에서는 할인 정책의 행동은 시간에 따라 변하는 것처럼 보임
  • 영화는 한 시점에 두 가지 행동 중 하나만 필요하기 때문
• 이렇게 클라이언트의 입장에서 행동이 변하는 것처럼 보인다면 행동에 따라 타입을 분리하는 것이 좋음
  • DiscountPolicy의 문제는 비율 할인 정책과 금액 할인 정책이라는 서로 다른 2개의 타입이 메서드의 형태로 하나의 클래스 안에 공존하고 있다는 것
  • => 유사해보이지만 서로 다르게 동작하는 책임(비율 할인 정책 계산, 금액 할인 정책 계산)이 하나의 후보(DiscountPolicy) 안에 뭉쳐있다면 타입을 분리한 후, 서로 다른 책임은 서로 다른 타입의 객체에게 할당해야 함
• ex) '금액 할인 정책(AmountDiscountPolicy)'이라는 특화된 타입에 '금액 할인 금액 계산 책임' 할당 + '비율 할인 정책(PercentDiscountPolicy)'이라는 특화된 타입에 '비율 할인 금액 계산 책임' 할당
  • => 서로 다르게 변하는 행동들이 비율 할인 정책 타입과 금액 할인 정책 타입으로 분리됨
  • => 영화는 비율 할인 정책 & 금액 할인 정책과 협력

여전히 높은 응집도..

Movie는 여전히 조건문 사용해서 분기처리 / 할인 정책 추가 시 결합도 상승 및 코드 내부 수정

• Movie는 두 개의 할인 정책과 협력해야 하기 때문에 PercentDiscountPolicy와 AmountDiscountPolicy 모두 필드로 추가해야 함
• 이제, 조건문을 이용해서 어떤 메서드를 호출할지 결정하기만 하면 됨
• ..? => 여전히 조건문이 남아있음.. 우리의 목표는 조건문을 제거하는 것이었음 => 여전히 높은 결합도
• 이는 Movie가 PercentDiscountPolicy & AmountDiscountPolicy 모두에 의존하고 있기 때문
• 여전히 높은 결합도로 인해 변경을 위해서는 Movie의 코드를 변경해야 함

---

결합도 낮추기 with 다형적인 메시지 + 변경 보호 패턴

메시지(Message)

• 객체들이 협력하기 위해 사용할 수 있는 유일한 의사소통 수단
• 객체는 다른 객체에게 협력을 요청하기 위해 메시지를 전송
• 객체가 다른 객체의 메서드를 호출하는 것과 같음

영화 예제에서의 메시지

책임이 동일하면 메시지 통일 / 타입에 따라 적절한 방법을 객체 스스로 선택

• 영화 입장에서 할인 금액을 계산하고 계산된 할인 금액을 반환한다는 점에서 비율 할인 정책(PercentDiscountPolicy)과 금액 할인 정책(AmountDiscountPolicy)은 다르지 않음
• 할인 금액을 계산하는 책임만 수행할 수 있다면, 금액을 계산하는 방식이나 타입이 무엇인지는 신경 쓸 필요 X
• => 영화는 협력하는 대상이 할인 금액을 계산할 수만 있다면, 조건문으로 누구에게 메시지를 전송할지 고민할 필요 X
• => 서로 다른 메시지 필요 X => 메시지를 통일해서 영화가 할인 정책의 타입과 무관하게 동일한 메시지를 전송하도록 만들 수 있음
• 객체지향에서는 메시지를 수신한 객체가 메시지를 처리할 방식을 스스로 선택할 수 있는 매커니즘 제공 by 다형성

다형성

• '동일한 메시지'를 전송했을 때, 메시지를 수신한 객체의 타입에 따라 '서로 다른 방식'으로 동작하고, '동일한 결과'를 반환하는 것
• 다형적인 메시지: 타입에 따라 다르게 동작하도록 요청을 전송하는 메시지

남아있는 높은 결합도

메시지를 통합했더라도 여전히 높은 결합도 문제가 남아있음.. => 결합도를 낮추기 위해 할인 정책의 타입을 숨겨야 함

=> 다형성을 사용하자

=> 변경 보호 패턴 적용

변경 보호(PROTECTED VARIATIONS) 패턴

• 문제: 요소들의 변화나 불안정한 요소가 다른 요소에 해로운 영향을 미치지 않을까?
• 해결 방법: 변화가 예상되거나 불안정한 지점을 식별하고, 그 주위에 안정적인 인터페이스 또는 추상화를 형성하도록 책임을 할당하라
  • 변하는 부분 = 영화가 협력해야 하는 할인정책의 종류
  • 영화를 할인 정책의 타입 변화로부터 보호할 필요 => 변경 보호 패턴 적용 필요
  • 변화 대상은 비율 할인 정책과 금액 할인 정책이므로, 이 두 타입 주변에 '할인 정책(DiscountPolicy)'라는 추상화 인터페이스를 추가
  • 추상화를 도입했으니, 영화가 이 안정적인 추상화에만 의존하도록 변경 => 영화는 더 이상 AmountDiscountPolicy, PercentDiscountPolicy를 몰라도 됨. 그 추상화인 DiscountPolicy만 알고있음
  • => 비율 할인 정책과 금액 할인 정책이라는 구체적인 타입은 안정적인 추상화인 할인 정책 뒤로 '캡슐화'되어 있음 (타입 캡슐화)

변경 보호 패턴 - 안정적인 추상화 뒤로 변하는 타입 숨기기

=> 다형적인 메시지로 요청을 통일하고, 변경 보호 패턴을 통해 변화를 캡슐화
=> 다형적으로 동작하는 협력 관계 형성

역할(Role)

역할 - 다른 것으로 대체할 수 있는 책임의 집합

영화와 비율 할인 정책 & 금액 할인 정책 사이에는 '할인 정책'이라는 추상화가 존재
=> 실제 영화가 이 두 정책과 협력하기 위해서는 구체적인 타입인 두 정책이 '할인 정책'을 대체(런타임에) 가능해야 함

• 역할(Role): 구체적인 타입들로 대체 가능한 추상화
• 역할과 객체는 같을 수도, 다를 수도 있음
  • 한 종류의 객체만 역할을 대체한다면, 객체와 역할은 동일
  • 여러 종류의 객체가 역할을 대체할 수 있다면, 역할은 객체와 다름. 역할은 객체가 대체 가능한 추상화를 의미

---

책임 주도 설계 구성 요소

역할, 책임, 협력

• 협력: 한 객체가 다른 객체에게 메시지를 전송해서 도움을 요청하고 응답을 받는 과정
• 책임: 객체가 다른 객체와 협력하기 위해 알아야 하거나 행동해야 하는 것
• 역할: 협력 안에서 책임을 수행하는 대상

영화 예제 - 할인 여부 판단 w/ 다형성 패턴 + 변경 보호 패턴

할인 정책은 할인 금액을 계산하기 위해 '할인 여부를 판단'해야 함
=> 할인 여부를 할인 정책이 판단하는 것은 응집도가 낮아짐..
=> 외부의 객체에게 도움 요청 필요

• 먼저 정보 전문가 패턴 적용
  • 도메인 모델 안에는 이미 할인 여부를 판단하기에 적절한 도메인 개념인 '할인 조건'이 존재
  • 할인 조건은 순서 조건과 기간 조건이라는 두가지 타입으로 분류 가능하며
  • 이 두 타입은 할인 여부를 판단하는 행동은 공유하지만, 서로 다른 방식에 따라 조건을 판단하고 있음..
  • => 순서 조건과 기간 조건 타입에 따라 행동이 변함
  • => 다형성 패턴과 변경 보호 패턴 적용 가능
• 다형성 패턴 적용
  • 유사하지만 다르게 동작하는 책임들을 각각의 타입에 할당
  • 순서 조건(SequenceCondition)과 기간 조건(PeriodCondition) 객체 생성
  • 이제 할인 정책은 순서 조건과 기간 조건 2개의 타입 모두에 의존
  • => 결합도가 높아 변경에 취약..
• 다형성 패턴 + 변경 보호 패턴 적용 (추상화 & 인터페이스)
  • 다형성 패턴을 통해 다형적인 메시지로 요청 통합
  • 이후 변경 보호 패턴을 통해 할인 조건(DiscountCondition)이라는 안정적인 추상화 추가 & 할인 정책(DiscountPolicy)가 이 추상화에 의존하도록 변경
  • => 전체적으로 결합도가 낮아짐. => 새로운 할인 조건이 추가되더라도 협력하는 할인 정책에는 영향 X

---

정리

• 협력을 잘 설계하기 위해서는 시스템 내부에서 일어나는 상태 변경 정리 필요
  • 도메인 모델에 기반한 개념들의 집합으로 가시화한 후, 이를 기반으로 객체 협력을 설계하자
    • 애플리케이션 기능 -> 시스템이 수행할 책임 -> 객체가 수행할 책임 변환
    • 책임을 수행할 객체를 GRASP 패턴을 통해 찾고 책임 할당하기
    • 책임을 구현하면서 필요한 데이터를 추가
• 책임을 할당할 객체를 찾는 과정
  • '정보 전문가 패턴' 적용해서 구조 찾기
  • 찾은 구조에 '낮은 결합도 패턴'과 '높은 응집도 패턴'을 적용해서 평가하기
  • 하나의 클래스 안에 유사하지만 서로 다른 타입이  공존하고 있다면 타입을 분리하고, 추상화를 통해 다형성 적용 = '다형성 패턴 + 변경 보호 패턴'
• 위 과정을 통해 전체적으로 낮은 결합도, 높은 응집도, 캡슐화를 달성할 수 있으며 그 결과 변경이 쉬운 설계를 달성할 수 있음