5. 책임 할당하기 - 4

🐿️  올바른 설계가 됐는지 코드를 통해 검증

🗣️ 구현을 통한 검증 

 

movie의 구현을 고려하지 않고 필요한 메시지를 결정

→ movie의 내부 구현을 깔끔하게 캡슐화함

 

public class Screeening {

	private Movie movie;
	private int sequence;
	private LocalDateTime whenScreened;

	public Reservation reserve(Custoemr customer, int audienceCount) {
		return new Reservation(customer, this, calculateFee(audienceCount), audienceCount);	
	}

	public Money calculateFee(int audienceCount) {
		return movie.calculateMovieFee(this).times(audienceCount);
}

}

 

메시지를 기반으로 협력을 구성하면 Screening과 Movie사이의 결합도를 느슨하게 유지할 수 있다.

 

 

 

1. DiscountCondition 개선하기

• 가장 큰 문제점은 변경에 취약한 클래스를 포함하고 있다는 것
• 변경에 취약한 클래스: 코드를 수정해야하는 이유를 하나 이상 가지는 클래스
•  
• 응집도가 낮다: 서로 연관성이 없는 기능이나 데이터가 하나의 클래스 안에 뭉쳐져 있다.
• 높은 응집도를 갖기 위해서: 변경의 이유에 따라 클래스를 분리해야한다

 

• 코드를 통해 변경의 이유를 파악할 수 있는 첫번째 방법
• : 인스턴스 변수가 초기화되는 시점을 살펴보는 것
• → 함께 초기화되는 속성을 기준으로 코드를 분리해야 한다
•  
•  
• 두번째 방법:
• 메서드들이 인스턴스 변수를 사용하는 방식을 살펴보는 것
• → 속성 그룹과 해당 그룹에 접근하는 메서드 그룹을 기준으로 코드를 분리해야함

 

 

2. 타입 분리하기

문제점

: 순번 조건, 기간 조건이 독립적인 타입인데 하나의 클래스 안에 공존

 

 

3. 다형성을 통해 분리하기

구현을 공유해야한다: 추상클래스 이용

구현을 공유하지 않아도 됨, 역할을 대체하는 객체들의 책임만 정의하고 싶음: 인터페이스 사용

 

POLYMORPHISM(다형성) 패턴 from GRASP

: 객체의 타입에 따라 변화하는 행동이 있다면 타입을 분리하고 변화하는 행동을 각 타입의 책임으로 할당하기

 

 

4. 변경으로부터 보호하기

PROTECTED VARIATIONS(변경 보호) 패턴 from GRASP

변경을 캡슐화하도록 책임을 할당하는 것

변화가 예상되는 불안정한 지점들을 식별하고 그 주위에 안정된 인터페이스를 형성하도록 책임을 할당하라

변경될 가능성이 높으면 → 캡슐화하라

 

 

5. Movie 클래스 개선하기
문제: Movie는 금액 할인 정책 영화, 비율 할인 정책 영화 두가지 타입을 하나의 클래스 안에서 구현하고 있음

→ 응집도가 낮음

 

도메인 구조가 코드의 구조를 이끈다

 

6. 변경과 유연성

설계를 주도하는 것은 변경이다

 

변경 대비 방법 두가지

1. 코드를 이해하고 수정하기 쉽도록 최대한 단순하게 설계

2. 코드를 수정하지 않고도 변경을 수용할 수 있도록 코드를 더 유연하게 만듦

 

합성을 하면

아래의 일을 하지 않아도 된다.

(새로운 할인 정책이 추가될 때마다 인스턴스를 생성하고, 상태를 복사하고, 식별자를 관리하는 코드를 추가하는 일)

 

 

유연성은 의존성 관리의 문제다

요소들 사이의 의존성의 정도가 유연성의 정도를 결정한다

유연성의 정도에 따라 결합도를 조절할 수 있는 능력은 객체지향 개발자가

갖춰야 하는 중요한 기술 중 하나다

 

도메인 모델은 구현과 밀접한 관계가 있다.

도메인 모델은 코드에 대한 가이드를 제공하고 코드의 변화에 따라 함께 변화해야한다