TIL

09 유연한 설계

01 개방-폐쇄 원칙

• 개방-폐쇄 원칙 (Open-Closed Principle, OCP)
  • 소프트웨어 개체는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다.
• ‘확장’과 ‘수정’이라는 키워드는 애플리케이션의 ‘동작’과 ‘코드’의 관점을 반영한다.
  • 확장에 열려 있다: 요구사항이 변경될 때 새로운 ‘동작’을 추가해서 기능을 확장할 수 있다.
  • 수정에 닫혀 있다: 기존 ‘코드’를 수정하지 않고 ‘동작’을 추가하거나 변경할 수 있다.

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

• OCP는 런타임 의존성과 컴파일타임 의존성에 관한 이야기다.
• 영화 예매 시스템의 할인 정책은 이미 OCP를 만족하고 있다.
  • Movie는 DiscountPolicy 추상 클래스에 의존
  • 할인 정책으로 어떤 구현체가 추가되어도 Movie가 DiscountPolicy를 의존하고 있는 코드는 변경하지 않아도 된다.
• 의존성 관점에서 OCP는 컴파일타임 의존성은 유지하면서 런타임 의존성의 기능을 확장하고 수정할 수 있는 구조

추상화가 핵심이다

• OCP의 핵심은 추상화에 의존하는 것
• 추상화란 핵심만 남기고 불필요한 부분은 생략함으로써 복잡성을 극복하는 기법
• OCP 관점에서 생략되지 않고 남겨지는 부분은 다양한 상황에서의 공통점을 반영한 추상화의 결과물이다.
  • 공통적인 부분은 문맥이 바뀌어도 수정할 필요가 없어야 한다.
• 주의할 점은 추상화를 했다고 모든 수정에 대해 설계가 폐쇄되는 것은 아니라는 점이다.
  • 변경에 의한 파급효과를 피하려면 변하는 것과 변하지 않는 것을 잘 파악하고 추상화해야 한다.
  • OCP가 지켜지는 것은 변경되지 않을 부분을 신중하게 결정하고 올바른 추상화를 했기 때문

02 생성 사용 분리

• 객체가 오직 추상화에만 의존하기 위해서는 객체 내부에서 구체 클래스 인스턴스를 생성해서는 안 된다.
  • 이는 동작을 추가하거나 변경할 때 기존 코드를 수정하게 만들어 OCP를 위반한다.
  • 결합도가 높아질수록 OCP를 지키기가 어려워진다.
  • ex) Movie 내부에서 AmounDiscountPolicy를 생성
• 유연하고 재사용 가능한 설계를 위해선 객체에 대한 생성과 사용을 분리해야 한다.
  • 동일한 클래스에서 객체 생성과 사용이라는 두 목적을 가진 코드가 공존하는 것이 문제
  • 객체를 생성할 책임을 클라이언트로 옮겨야 한다.
• 객체가 추상화에만 의존하도록 제한함으로써 확장에 열려있으면서 수정에 닫힌 코드를 만들 수 있다.

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

FACTORY 추가하기

• 구체적인 할인 정책 생성 책임을 Client로 옮긴 배경
  • Movie가 특정 컨텍스트에 묶이지 않게 하기 위해
  • Client도 특정 컨텍스트에 묶이지 않기를 바란다면?
• 객체의 생성과 사용을 분리하기 위해 객체 생성에 특화된 객체를 Factory라고 부른다.

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

public class Client {
    private Factory factory;

    public Cleint(Factory factory) {
        this.factory = factory;
    }

    public Movney getAvatarFee() {
        Movie avatar = factory.createAvatarMvoie();
        return avatar.getFee();
    }
}

• FACTOR로 객체 생성 책임을 이동시킴으로써 Client는 사용과 관련된 책임만 남게 된다.

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

• INFORMATION EXPERT
  • GRASP 패턴 중 책임을 수행할 객체를 찾을 때 정보 전문가에게 맡기는 패턴
  • 보통 도메인 모델 안의 개념 중 적절한 후보를 탐색한다.
  • 하지만 종종 도메인 개념을 초월하는 기계적인 개념이 필요할 수도 있다.
  • 앞서 설명한 FACTORY도 도메인 모델이 아니다.
• 시스템을 객체로 분해하는 두 가지 방식
  • 표면적 분해 (representational decomposition)
    • 도메인에 존재하는 사물 또는 개념을 표현하는 객체를 이용해 시스템을 분해하는 것
  • 행위적 분해(behavioral decomposition)
• PURE FABRICATION (순수 가공물)
  • 도메인 개념을 표현한 것이 아닌 설계자가 편의를 위해 임의로 만들어낸 가공의 객체
  • 모든 책임을 도메인 객체에게 할당하면 낮은 응집도, 높은 결합도, 재사용성 저하와 같은 문제가 발생할 수 있다.
  • 어떤 행동을 책임질 마땅한 도메인 개념이 존재하지 않는다면 PURE FABRICATION에게 책임을 할당하라
  • 행위적 분해에 의해 생성되는 개념

03 의존성 주입

• 의존성 주입 (Dependency Injection)
  • 외부의 독립적인 객체가 인스턴스를 생성 후 전달하여 의존성을 해결하는 방법
  • 의존성 주입은 의존성 해결 방법과 관련이 깊다.
    • 컴파일타임 의존성과 런타임 의존성의 차이를 해소하는 다양한 메커니즘을 포괄
• 의존성 주입 방법
  • 생성자 주입
  • setter 주입
  • 메서드 주입

숨겨진 의존성은 나쁘다.

• SERVICE LOCATOR 패턴
  • 의존성을 해결할 객체들을 보관하는 일종의 저장소
  • 객체가 직접 SERVICE LOCATOR에게 의존성 해결을 요청

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

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

• SERVICE LOCATOR 패턴의 가장 큰 단점은 의존성을 감춘다는 것이다.
  • Movie의 퍼블릭 인터페이스에 DiscountPolicy 의존성이 나타나지 않는다.
  • ServiceLocator에서 DiscountPolicy가 잘 들어가 있지 않다면 NPE를 마주할 수도 있다.
  • 컴파일타임이 아닌 런타임에 문제가 발견된다.
• 의존성을 숨기는 코드는 단위 테스트 작성도 어렵다.
  • ServiceLocator는 내부적으로 정적 변수를 이용하기에 각 단위 테스트가 고립돼야 한다는 기본 원칙을 위반한다.
• 숨겨진 의존성은 캡슐화를 위반한다.
  • 퍼블릭 인터페이스만으로 사용 방법을 이해할 수 있는 코드가 캡슐화 관점에서 훌륭한 코드다.
  • 사용을 위해 내부 구현을 알아야 한다면 캡슐화는 무너진 것
  • ex) Movie가 사용되려면 ServiceLocator에 구현체를 넣어두어야 함을 알아야 한다.
• 무조건 의존성 주입이 SERVICE LOCATOR 패턴보다 좋다는 것은 아니다.
  • 명시적인 의존성이 더 좋다는 것
  • 어쩔 수 없이 SERVICE LOCATOR 패턴을 사용해야 하는 경우
    • 의존성 주입 프레임워크를 사용하지 못하는 경우
    • 깊은 호출 계층에 걸쳐 동일한 객체를 계속 전달해야 하는 경우

04 의존성 역전 원칙

추상화와 의존성 역전

• 구체 클래스에 대한 의존성은 결합도를 높이고 재사용성과 유언성을 낮춘다.
  • OCP 위반
• 모든 의존성 방향은 추상 클래스나 인터페이스와 같은 추상화를 따라야 한다.
  • 구체 클래스는 의존성의 시작점이어야 한다.
• 의존성 역전 원칙 (Dependency Inversion Principle, DIP)
  • 상위 수준 모듈은 하위 수준 모듈에 의존해서는 안 된다. 둘 모두 추상화에 의존해야 한다.
  • 추상화는 구체적인 사항에 의존해서는 안 된다. 구체적인 사항은 추상화에 의존해야 한다.

의존성 역전 원칙과 패키지

• 역전은 의존성 방향뿐만 아니라 인터페이스 소유권에도 적용된다.
• 추상화와 클라이언트가 별도의 패키지에 있는 경우
  • Movie / DiscountPolicy, AmountDiscountPolicy, PercentDiscountPolicy
  • Movie는 DiscountPolicy를 의존하기에 정상적인 컴파일을 위해선 DiscountPolicy가 필요
  • 그런데 DiscountPolicy가 있는 패키지 안에 구체 클래스들도 포함되어 있다
  • 컴파일 측면에서 DiscountPolicy가 포함된 패키지 안의 어떤 클래스가 수정되더라도 패키지 전체가 배포되어야 한다.
  • 전체적인 빌드 시간 상승
• SEPARATED INTERFACE 패턴
  • 추상화와 클라이언트를 같은 패키지에 포함시켜야 한다.
  • Movie, DiscountPolicy / AmountDiscountPolicy, PercentDiscountPolicy
  • 이 구조를 통해 Movie는 특정 컨텍스트로부터 완전 독립한다.
  • 새로운 할인 정책을 위해 새로운 패키지를 추가하고 새 자식 클래스를 구현하면 상위 수준 협력 관계를 재사용할 수 있다.

05 유연성에 대한 조언

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

• 유연하고 재사용 가능한 설계가 항상 좋은 것은 아니다.
• 유연성은 항상 복잡성을 수반한다.
  • 유연하지 않으면 단순하고 명확하다.
  • 불필요한 유연성은 불필요한 복잡성을 낳는다.
• 복잡성에 대한 걱정보다 유연하고 재사용 가능한 설계의 필요성이 더 크다면 객체지향적으로 설계하라

협력과 책임이 중요하다

• 유연한 설계를 위해선 협력에 참여하는 객체가 다른 객체에게 어떤 메시지를 전송하는지가 중요
• 메시지 전송자 관점에서 동일한 책임을 수행하는지 여부를 판단해야 공통의 추상화에 도달할 수 있다.
• 초보자가 자주 하는 실수가 바로 객체 역할과 책임이 자리 잡기 전에 성급하게 객체 생성에 집중하는 것이다.
  • 성급한 객체 생성은 불필요한 세부사항에 객체를 결합시킨다.
  • 객체 생성 방법에 대한 결정은 모든 책임이 자리 잡은 후 마지막 시점에 내리는 것이 적절
• 의존성을 관리해야 하는 이유는 역할, 책임, 협력 관점에서 설계가 유연하고 재사용 가능해야 하기 때문