여기서 주의할 점은 추상화를 했다고 해서, 모든 수정에 대해 설계가 폐쇄되는 것은 아니라는 것이다. 수정에 대해 닫혀있고 확장에 대해 열려있는 설계는 공짜로 얻어지지 않는다.

• Open-Closed Principle, so called OCP is related with the dependency, compile time dependency and runtime dependency.
  • If these dependencies are not same, we can ‘replace’ them to other one without modifying exist thing.

Separate use from creation

Process to separate

소프트웨어 시스템은 응용 프로그램을 제작하고 의존성을 서로 연결하는 시작 단계와 시작 단계 이후에 이어지는 실행 단계를 분리해야 한다.

class Movie {
	// ...
	private discountPolicy: DiscountPolicy;
	constructor() {
		// create
		this.discountPolicy = new AmountDiscountPolicy(...);
	}
	// use
	public calculateMovieFee(screening: Screening): Money {
		return fee.minus(discountPolicy.calculateDiscountAmount(screening);
	}
}

• There is no problem that creating a specific instance in specific object. And also, there is no problem that sending a message to non-specific(abstract class, interface, what else) object in specific instance.
• But, when these are occurred in same object, this is not a good design.

class Movie {
	constructor(
		// ...
		private discountPolicy: DiscountPolicy,
	) {}
	// use
	public calculateMovieFee(screening: Screening): Money {
		return fee.minus(discountPolicy.calculateDiscountAmount(screening);
	}
}

// ------------------------------------------------------------------------ //

// create
class Client {
	public getAvatarFee() {
		const avatar = new Movie("아바타", Duration.ofMinutes(120), Money.wons(10000), ...);
		return avatar.getFee();
	}
}

• Separate use from creation

Using Factory

// Factory Class
class Factory {
	public createAvatarMovie(): Movie {
		return new Movie(
			"아바타",
			Duration.ofMinutes(120),
			// ...
	}
}

// ------------------------------------------------------------------------ //

class Client {
	constructor(
		private readonly factory: Factory
	) {}
	
	public getAvatarFee() {
		const avatar = this.factory.createAvatarMovie();
		return avatar.getFee();
	}
}

• We separate use from creation, but this design allow client be related with some specific contexts.
• If we want to separate the client from specific contexts also, use Factory object.
  • This object just create instance, so Client object doesn’t know the contexts.

Assigning role - Pure fabrication and types of decomposition

그러나 종종 도메인 개념을 표현하는 객체에게 책임을 할당하는 것만으로는 (소프트웨어의 설계가) 부족한 경우가 발생한다. 도메인 모델은 설계를 위한 중요한 출발점이지만, 단지 출발점이라는 사실을 명심해야 한다. 실제로 동작하는 애플리케이션은 데이터베이스 접근을 위한 객체와 같이 도메인 개념을 초월하는 기계적인 개념들을 필요로 할 수 있다.

모든 책임을 도메인 객체에게 할당하면 낮은 응집도, 높은 결합도, 재사용성 저하와 같은 심각한 문제점에 봉착하게 될 가능성이 높아진다. 이 경우, 도메인 개념을 표현한 객체가 아닌 설계자가 편의를 위해 임의로 만ㄷ르어낸 가공의 객체에게 책임을 할당해서 문제를 해결해야 한다. 크레이그 라만은 이처럼 책임을 할당하기 위해 창조되는 도메인과 무관한 인공적인 객체를 Pure Fabrication 이라고 부른다.

객체 지향이 실세계의 모방이라는 말은 옳지 않다. 객체지향 애플리케이션은 도메인 개념 뿐만 아니라, 설계자들이 임의로 창조한 인공적인 추상화들을 포함하고 있다. 애플리케이션 내에서 인공적으로 창조한 객체들이 도메인 개념을 반영하는 객체들보다 오히려 더 많은 비중을 차지하는 것이 일반적이다.