🌈 Chapter 9: 유연한 설계

📚 개방-폐쇄 원칙

• 개방-폐쇠 원칙은 소프트웨어 개체(클래스, 모듈, 함수 등등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다.

• 확장에 대해 열려 있다: 애플리케이션의 요구사항이 변경될 때 이 변경에 맞게 새로운 동작을 추가해서 애플리케이션의 기능을 확장할 수 있다.
• 수정에 대해 닫혀 있다: 기존의 코드를 수정하지 않고도 애플리케이션의 동작을 추가하거나 변경할 수 있다.

• 개방-폐쇄 원칙은 유연한 설계란 코드를 수정하지 않고도 애플리케이션의 동작을 확장할 수 있는 설곌고 이야기한다.

🎈 컴파일타임 의존성을 고정시키고 런타임 의존성을 변경하라

• 런타임 의존성은 실행시에 협력에 참여하는 객체들 사이의 관계다.
• 컴파일타임 의존성은 코드에서 드러나는 클래스들 사이의 관계다.
• 개방-폐쇄 원칙을 수용하는 코드는 컴파일타임 의존성을 수정하지 않고도 런타임 의존성을 쉽게 변경할 수 있다.
• 의존성 관점에서 개방-폐쇄 원칙을 따르는 설계란 컴파일타임 의존성은 유지하면서 런타임 의존성의 가능성을 확장하고 수정할 수 있는 구조라고 할 수 있다.

🎈 추상화가 핵심이다

• 개방-폐쇄 원칙의 핵심은 추상화에 의존하는 것이다.
• 추상화 과정을 거치면 문맥이 바뀌더라도 변하지 않는 부분만 남게 되고 문맥에 따라 변하는 부분은 생략된다.
• 개방-폐쇄 원칙의 관점에서 생략되지 않고 남겨지는 부분은 다양한 상황에서의 공통점을 반영한 추상화의 결과물이다. 공통적인 부분은 문맥이 바뀌더라도 변하지 않아야 한다. 공통적인 부분은 문맥이 바뀌더라도 변하지 않아야 한다. 다시 말해서 수정할 필요가 없어야 한다. 따라서 추상화 부분은 수정에 닫혀 있다.
• 추상화를 통해 생략된 부분은 확장의 여지를 남긴다. 언제라도 추상화의 생략된 부분을 채워넣음으로써 새로운 문맥에 맞게 기능을 확장할 수 있다. 따라서 추상화는 설계의 확장을 가능하게 한다.
• 개방-폐쇄 원칙에서 폐쇄를 가능하게 하는 것은 의존성의 방향이다. 수정에 대한 영향을 최소화하기 위해서는 모든 요소가 추상화에 의존해야 한다. (Movie는 할인 정책을 추상화한 DiscountPolicy에 대해서 의존)
• 주의할 점은 추상화를 했다고 해서 모든 수정에 대해 설계가 폐쇄되는 것은 아니다. 변경에 의한 파급효가를 최대한 피하기 위해서는 변하는 것과 변하지 않는 것이 무엇인지를 이해하고 이를 추상화의 목적으로 삼아야만 한다.

📚 생성 사용 분리

• 결합도가 높아질수록 개방-폐쇄 원칙을 따르는 구조를 설계하기가 어려워진다. 알아야 하는 지식이 많으면 결합도가 높아진다.
• 객체의 타입과 생성자에 전달해야 하는 인자에 대한 과도한 지식은 코드를 특정한 컨텍스트에 강하게 결합시킨다.
• 동일한 클래스 안에서 객체 생성과 사용이라는 두 가지 이질적인 목적을 가진 코드가 공존하는 것이 문제이다.
• 유연하고 재사용 가능한 설계를 원한다면 객체와 관련된 두 가지 책임을 서로 다른 객체로 분리해야 한다. 하나는 객체를 생성하는 것이고, 다른 하나는 객체를 사용하는 것이다.
• 한 마디로 말해서 객체에 대한 생성과 사용을 분리해야 한다.
• 사용으로부터 생성을 분리하는 데 사용되는 가장 보편적인 방법은 객체를 생성할 책임을 클라이언트로 옮기는 것이다.

public class Client {
  public Money getAvatarFee() {
    Movie avatar = new Movie("아바타",
      Duration.ofMinutes(120),
      Money.wons(10000),
      new AmountDiscountPolicy(...)
    );

    return avatar.getFee();
  }
}

🎈 FACTORY 추가하기

• 위 코드에서 Movie의 생성 책임을 Client로 옮겼다. 만약 Client도 특정한 컨텍스트에 묶이지 않기를 바란다고 가정하면 Client도 생성하는 동시에 getFee 메시지도 함께 전송하고 있다. 즉, 생성과 사용의 책임을 함께 지니고 있다.
• 이 문제는 Movie의 문제를 해결했던 방법과 동일한 방법으로 해결할 수 있다.
• 이 경우 객체 생성과 관련된 책임만 전담하는 별도의 객체를 추가하고 Client는 이 객체를 사용하도록 만들 수 있는데 이 처럼 생성과 사용을 분리하기 위해 객체 생성에 특화된 객체를 FACTORY라고 부른다.

public class Factory {
  public Movie createAvatarMovie() {
    return new Movie("아바타",
      Duration.ofMinutes(120),
      Money.wons(1000),
      new AmountDiscountPolicy(...)
    );
  }
}

• 이제 Client는 Factory를 사용해서 생성된 Movie의 인스턴스를 반환받아 사용하기만 하면 된다.

public class Client {
  private Factory factory;

  public Client(FACTORY factory) {
    this.factory = factory;
  }

  public Money getAvatarFee() {
    Movie avatar = factory.createAvatarMovie();

    return avatar.getFee();
  }
}

🎈 순수한 가공물에게 책임 할당하기

• 책임 할당의 가장 기본이 되는 원칙은 책임을 수행하는 데 필요한 정보를 가장 많이 알고 있는 INFORMATION EXPERT에게 책임을 할당하는 것이다. 도메인 모델은 INFORMATION EXPERT를 찾기 위해 참조할 수 있는 일차적인 재료다. 어떤 책임을 할당하고 싶다면 제일 먼저 도메인 모델 안의 개념 중에서 적절한 후보가 존재하는지 찾아봐야 한다.
• FACTORY는 도메인 모델에 속하지 않는다. FACTORY를 추가한 이유는 순수하게 기술적인 결정이다. 전체적인 결합도를 낮추고 재사용성을 높이기 위해 도메인 개념에게 할당돼 있던 객체 생성 책임을 도메인 개념과는 아무런 상관ㅇ니 없는 가공의 객체로 이동시킨 것이다.
• 시스템을 객체로 분해하는 데 크게 두 가지 방식이 존재하는데 하나는 표현적 분해이고 다른 하나는 행위적 분해다.
• 표현적 분해는 도메인에 존재하는 사물 또는 개념을 표현하는 객체들을 이용해 시스템을 분해하는 것이다. 표현적 분해는 도메인 모델에 담겨 있는 개념과 관계를 따르며 도메인과 소프트웨어 사이의 표현적 차이를 최소화하는 것을 목적으로 한다.
• 그러나 종종 도메인 개념을 표현하는 객체에게 책임을 할당하는 것만으로 부족한 경우가 발생한다. 모든 책임을 도메인 객체에 할당하면 낮은 응집도, 높은 결합도, 재사용성 저하와 같은 심각한 문제점에 봉착하게 될 가능성이 높아진다. 이 경우 도메인 개념을 표현한 객체가 아닌 설계자가 편의를 위해 임으로 만들어낸 가공의 객체에게 책임을 할당해서 문제를 해결해야 하는데 이처럼 책임을 할당하기 위해 창조되는 도메인과 무관한 인공적인 객체를 PURE FABRICATION(순수한 가공물)이라고 부른다.
• 어떤 행동을 추가하려고 하는데 이 행동을 책임질 마땅한 도메인 개념이 존재하지 않는다면 PURE FABRICATION을 추가하고 이 객체에게 책임을 할당해야 한다. 그 결과로 보통 특정한 행동을 표현하는 것이 일반적이다. 따라서 PURE FABRICATION은 표현적 분해보다 행위적 분해에 의해 생성된다.
• 먼저 도메인의 본질적인 개념을 표현하는 추상화를 이용해 애플리케이션을 구축하고 만약 도메인 개념이 만족스럽지 못하다면 인공적인 객체를 창조한다.
• FACTORY는 객체의 생성 책임을 할당할만한 도메인 객체가 존재하지 않을 때 선택할 수 있는 PURE FABRICATION을 포함한다.

📚 의존성 주입

• 사용하는 객체가 아닌 외부의 독립적인 객체가 인스턴스를 생성한 후 이를 전달해서 의존성을 해결하는 방법을 의존성 주입이라고 부른다.
• 이 기법은 외부에서 의존성의 대상을 해결한 후 이를 사용하는 객체 쪽에 주입한다.
• 의존성 주입은 의존성 해결 방법과 관련이 깊다. (생성자 주입, setter 주입, 메서드 주입)
• 다음 예제는 Movie의 생성자를 이용해 의존성을 주입하기 때문에 생성자 주입이라고 부른다.

Movie avatar = new Movie("아바타",
  Duration.ofMinutes(120),
  Money.wons(10000),
  new AmountDiscountPolicy(...)
);

• setter 주입은 이미 생성된 Movie에 대해 setter 메서드를 이용해 의존성을 해결한다. setter 주입의 장점은 의존성 대상을 런타임에 변경할 수 있다. 언제라도 의존 대상을 교체할 수 있다.
• 단점은 객체가 올바르게 생성되기 위해 어떤 의존성이 필수적인지를 명시적으로 표현할 수 없다.

avatar.setDiscountPolicy(new AmountDiscountPolicy(...));

• 메서드 주입은 메서드 호출 주입이라고도 부르며 메서드가 의존성을 필요로 하는 유일한 경우일 때 사용할 수 있다.

avatar.calculateDiscountAmount(screening, new AmountDiscountPolicy(...));

🎈 숨겨진 의존성은 나쁘다

• 의존성 주입 외에 의존성을 해결할 수 있는 방법 중 하나인 SERVICE LOCATOR 패턴이 있다.
• 이 패턴은 의존성을 해결할 객체들의 보관하는 일종의 저장소다. 외부에서 객체에게 의존성을 전달하는 의존성 주입과 달리 SERVICE LOCATOR의 경우 객체가 직접 SERVICE LOCATOR에게 의존성을 해결해줄 것을 요청한다.
• 예륻 들어 ServiceLocator라는 클래스가 SERVICE LOCATOR의 역할을 수행하고 Movie는 직접 ServiceLocator의 메서드를 호출해서 DiscountPolicy에 대한 의존성을 해결한다.

public class Movie {
  // ...
  private DiscountPolicy discountPolicy;

  public Movie(String title, Duration runningTime, Money fee) {
    this.title = title;
    this.runningTime = runningTime;
    this.fee = fee;
    this.discountPolicy = ServiceLocator.discountPolicy();
  }
}

• ServiceLocator는 DiscountPolicy의 인스턴스를 등록하고 반환할 수 있는 메서드를 구현한 저장소다.

public class ServiceLocator {
  private static ServiceLocator soleInstance = new ServiceLocator();
  private DiscountPolicy discountPolicy;

  public static DiscountPolicy discountPolicy() { // 인스턴스 반환
    return soleInstance.discountPolicy;
  }

  public static void provide(DiscountPolicy discountPolicy) { // 인스턴스 등록
    soleInstance.discountPolicy = discountPolicy;
  }

  private ServiceLocator() {}
}

• 다음과 같이 인스턴스를 ServiceLocator에 인스턴스를 등록한 후 Movie를 생성하면 된다.

ServiceLocator.provide(new AmountDiscountPolicy(...));
Movie avatar = new Movie("아바타",
  Duration.ofMinutes(120),
  Money.wons(10000)
);

ServiceLocator.provide(new PercentDiscountPolicy(...));
Movie avatar = new Movie("아바타",
  Duration.ofMinutes(120),
  Money.wons(10000)
);

• SERVICE LOCATOR 패턴의 가장 큰 단점은 의존성을 감춘다. Movie는 DiscountPolicy에 의존하고 있지만 Movie의 퍼블릭 인터페이스 어디에도 이 의존성에 대한 정보가 표시돼 있지 않다.
• 의존성을 구현 내부로 감출 경우 의존성과 관련된 문제가 컴파일타임이 아닌 런타임에 가서야 발견된다는 사실을 알 수 있다. 숨겨진 의존성이 이해하기 어렵고 디버깅하기 어려운 이유는 문제저을 발견할 수 있는 시점을 코드 작성 시점이 아니라 실행 시점으로 미루기 때문이다. 의존성을 숨기는 코드는 단위 테스트 작성도 어렵다.
• 숨겨진 의존성이 가지는 가장 큰 문제점은 의존성을 이해하기 위해 코드의 내부 구현을 이해할 것을 강요한다. 따라서 숨겨진 의존성은 캡슐화를 위반한다. 결과적으로 의존성을 구현 내부로 감추도록 강요하는 SERVICE LOCATOR는 캡슐화를 위반할 수밖에 없다.
• 명시적인 의존성이 숨겨진 의존성보다 좋다. 가급적 의존성을 객체의 퍼블릭 인터페이스에 노출해야 한다.
• 가능하다면 의존성으 명시적으로 표현할 수 있는 기법을 사용하라.

📚 의존성 역전 원칙

🎈 추상화와 의존성 역전

• 객체 사이의 협력이 존재할 때 그 협력의 본질을 담고 있는 것은 상위 수준의 정책이다. (할인 금액을 계산할 것인지가 아닌 영화를 계산하는 것) 다시 말해서 어떤 협력에서 중요한 정책이나 의사결정, 비즈니스의 본질을 담고 있는 것은 상위 수준의 클래스다.
• 상위 수준의 클래스는 어떤 식으로든 하위 수준의 클래스에 의존해서는 안 된다. (Movie는 AmountDiscountPolicy에 의존해서는 안 된다.)
• 상위 수준의 클래스가 하위 수준의 클래스에 의존하면 상위 수준의 클래스를 재사용할 때 하위 수준의 클래스도 필요하기 때문에 재사용하기가 어려워진다.
• 하위 수준의 변경으로 인해 상위 수준이 변경돼서는 안 된다.
• 이 경우에도 해결할 방법은 추상화다. (Movie와 AmountDiscountPolicy 사이에 추상 클래스인 DiscountPolicy) 상위 수준의 클래스와 하위 수준의 클래스 모두 추상화에 의존한다.
• 유연하고 재사용 가능한 설계를 원한다면 모두 의존성의 방향이 추상 클래스나 인터페이스와 같은 추상화를 따라야 한다. 구체 클래스는 의존성의 시작점이어야 한다.
• 의존성 역전 원칙이란 상위 수준의 모듈은 하위 수준의 모듈에 의존해서 안되고, 추상화는 구체적인 사항에 의존해서는 안 된다는 것이다. 즉, 상위와 하위 수준의 모듈 둘 다 추상화에 의존해야 하고, 구체적인 사항은 추상화에 의존해야 한다.

🎈 의존성 역전 원칙과 패키지

• 역전은 의존성의 방향뿐만 아니라 인터페이스의 소유권에도 적용된다.
• Movie의 재사용을 위해 필요한 것이 DiscountPolicy뿐이라면 DiscountPolicy를 Movie와 같은 패키지로 모으로 AmountDiscountPolicy와 PercentDiscountPolicy를 별도의 패키지에 위치시켜 의존성 문제를 해결할 수 있다. 따라서 추상화를 별도의 독립적인 패키지가 아니라 클라이언트가 속한 패키지에 포함시켜야 한다.
• 그리고 함께 재사용될 필요가 없는 클래스들은 별도의 독립적인 패키지에 모아야 한다. 마틴 파울러는 이 기법을 가리켜 SEPARATED INTERFACE 패턴이라고 부른다.
• 따라서 의존성 역정 원칙에 따라 상위 수준의 협력 흐름을 재사용하기 위해서는 추상화가 제공하는 인퍼테이스의 소유권 역시 역전시켜야 한다.
• 객체지향 패러다임에서 인터페이스가 상위 수준 모듈에 속한다.

📚 유연성에 대한 조언

🎈 유연한 설계는 유연성이 필요할 때만 옳다

• 유연하고 재사용 가능한 설계란 런타임 의존성과 컴파일타임 의존성의 차이를 인식하고 동일한 컴파일타임 의존성으로부터 다양한 런타임 의존성을 만들 수 있는 코드 구조를 가지는 설계를 의미한다.
• 하지만 유연하고 재사용 가능한 설계가 항상 좋은 것은 아니다. 단순하고 명확한 설계를 가진 코드는 읽기 쉽고 이해하기도 편하다. 변경하기 쉽고 확장하기 쉬운 구조를 만들기 위해서는 단순함과 명확함의 미덕을 버리게될 가능성이 높다.
• 유연성은 항상 복잡성을 수반한다. 유연하지 않은 설계는 단순하고 명확하다.
• 설계가 유연할수록 클래스 구조와 객체 구조 사이의 거리는 점점 멀어진다. 유연한 설계를 단순하고 명확하게 만드는 유일한 방법은 사람들 간의 긴밀한 커뮤니케이션뿐이다.
• 불필요한 유연성은 불필요한 복잡성을 낳는다. 단순하고 명확한 해법이 그런대로 만족스럽다면 유연성을 제거해야 한다.

🎈 햡력과 책임이 중요하다

• 설계를 유연하게 만들기 위해서는 협력에 참여하는 객체가 다른 객체에게 어떤 메시지를 전송하는지가 중요하다.
• 설계를 유연하게 민들기 위해서는 먼저 역할, 책임, 협력에 초점을 맞춰야 한다.
• 중요한 비즈니스 로직을 처리하기 위해 책임을 할당하고 협력의 균형을 맞추는 것이 객체 생성에 관한 책임을 할당하는 것보다 우선이다.
• 핵심은 객체를 생성하는 방법에 대한 결정은 모든 책임이 자리를 잡은 후 가장 마지막 시점에 내리는 것이 적절하다는 것이다.
• 의존성을 관리해햐 하는 이유는 역할, 책임, 협력의 관점에서 설계가 유연하고 재사용 가능해야 하기 때문이다. 따라서 역할, 책임, 협력에 먼저 집중해야 한다.