Java Decorator 패턴과 상속 비교, 상속 대신 Decorator를 선택해야 하는 이유

🔗 Decorator 패턴의 핵심 개념과 구조

Decorator 패턴은 객체에 추가적인 기능을 동적으로 부여하기 위해 사용되는 구조 패턴(Structural Pattern)입니다.
상속처럼 기존 클래스의 기능을 확장할 수 있지만, 새로운 클래스를 무분별하게 생성하지 않고 객체를 감싸는 방식으로 구현됩니다.
즉, 원본 객체와 동일한 인터페이스를 구현한 Decorator 클래스를 통해 기존 객체의 기능을 확장하거나 변경할 수 있습니다.

이 패턴은 크게 세 가지 구성 요소로 나눌 수 있습니다.
첫째, Component 인터페이스나 추상 클래스는 기본 기능의 규격을 정의합니다.
둘째, ConcreteComponent는 실제 기능을 구현하는 클래스입니다.
셋째, Decorator 클래스는 Component를 참조하며, 여기에 새로운 기능을 덧붙입니다.

🧩 동작 방식

Decorator 패턴은 실행 중에 객체를 감싸고, 감싼 객체의 메서드를 호출한 뒤 그 전후에 추가 동작을 수행하는 방식으로 확장성을 확보합니다.
이로 인해, 필요에 따라 여러 개의 데코레이터를 체인 형태로 연결할 수 있습니다.
이는 상속 구조에서 흔히 발생하는 클래스 폭발 문제를 예방합니다.

📌 UML 구조 예시

UML로 표현하면, Component 인터페이스를 구현하는 ConcreteComponent와 Decorator가 나란히 존재하고, Decorator는 다시 Component 타입의 참조를 가집니다.
이를 통해 기능의 추가·변경이 필요할 때마다 새로운 Decorator 클래스를 정의하면 되므로, 코드의 변경 없이도 새로운 동작을 쉽게 추가할 수 있습니다.

// Component
public interface Coffee {
    String getDescription();
    double cost();
}

// ConcreteComponent
public class BasicCoffee implements Coffee {
    public String getDescription() { return "Basic Coffee"; }
    public double cost() { return 2.0; }
}

// Decorator
public class MilkDecorator implements Coffee {
    private Coffee coffee;
    public MilkDecorator(Coffee coffee) { this.coffee = coffee; }
    public String getDescription() { return coffee.getDescription() + ", Milk"; }
    public double cost() { return coffee.cost() + 0.5; }
}

위 예시처럼, 우유를 추가하는 기능을 위해 BasicCoffee를 직접 수정하지 않고, MilkDecorator를 통해 동적으로 기능을 확장할 수 있습니다.
이러한 설계 방식은 OCP(개방-폐쇄 원칙)을 준수하며, 변경에 강하고 유지보수성이 뛰어난 시스템을 만들 수 있게 합니다.

🛠️ 상속 기반 설계의 한계와 문제점

상속은 객체지향 프로그래밍에서 재사용성을 높이고 기능을 확장하는 기본적인 방법입니다.
그러나 단순히 상속만으로 기능을 추가하려 하면 예상치 못한 문제들이 발생할 수 있습니다.
특히, 기능이 복잡해지고 클래스 수가 늘어날수록 상속 구조는 유지보수가 어려워지고 설계 유연성이 떨어집니다.

📉 클래스 폭발 문제

상속 기반 설계에서는 새로운 기능 조합이 필요할 때마다 별도의 하위 클래스를 만들어야 합니다.
예를 들어, 커피 클래스에 우유, 설탕, 시럽을 조합해서 추가하려면 모든 조합에 대한 클래스를 만들어야 하고, 이는 클래스 폭발(class explosion) 현상을 초래합니다.
이런 경우 클래스 관리가 복잡해지고, 작은 변경에도 다수의 클래스를 수정해야 합니다.

🔄 강한 결합도

상속은 부모 클래스와 자식 클래스 간에 강한 결합도를 만듭니다.
즉, 부모 클래스의 변경은 모든 하위 클래스에 영향을 미치게 되고, 이는 유지보수 비용 증가로 이어집니다.
또한, 자식 클래스는 부모 클래스의 불필요한 메서드나 속성까지 상속받을 수 있어 코드의 일관성과 가독성이 저하될 수 있습니다.

⛔ OCP 위반

OCP(개방-폐쇄 원칙)는 “확장에는 열려 있어야 하지만 변경에는 닫혀 있어야 한다”는 원칙입니다.
그러나 상속 기반 설계에서는 새로운 기능을 추가하기 위해 기존 클래스의 코드를 변경해야 하는 경우가 많습니다.
이는 OCP 위반이며, 시스템 안정성을 저해하는 원인이 됩니다.

결국 상속만으로 모든 기능 확장을 처리하려는 접근은 유연성을 제한하고, 변화에 취약한 코드를 만들게 됩니다.
이러한 문제를 해결하기 위해 Decorator 패턴과 같은 대안적 설계 패턴이 필요합니다.

⚙️ 상속 대신 Decorator를 선택해야 하는 이유

Decorator 패턴은 상속의 한계를 극복하고 유연하고 확장 가능한 설계를 가능하게 합니다.
상속은 컴파일 시점에 구조가 고정되지만, Decorator는 런타임에 기능을 동적으로 조합할 수 있어 확장성과 유지보수성이 뛰어납니다.
이 점에서 기능 변경이 잦은 시스템에서는 Decorator가 훨씬 적합한 선택이 됩니다.

💡 조합을 통한 유연한 확장

Decorator 패턴은 기능을 조합(Composition) 방식으로 추가합니다.
즉, 필요에 따라 객체를 감싸고, 그 위에 또 다른 Decorator를 덧씌워 새로운 기능을 계속 추가할 수 있습니다.
이 방식은 클래스 수를 급격히 늘리지 않으면서도 다양한 기능 조합을 지원합니다.

🔄 OCP 준수

Decorator 패턴은 기존 클래스의 코드를 전혀 수정하지 않고도 새로운 기능을 추가할 수 있습니다.
따라서 OCP(개방-폐쇄 원칙)을 완벽하게 준수합니다.
이는 안정적인 시스템 유지에 매우 중요한 요소입니다.

🛠️ 유지보수성과 테스트 용이성

각 Decorator는 독립적인 기능 단위이므로, 개별적으로 개발·수정·테스트가 가능합니다.
이는 오류를 빠르게 찾고 수정할 수 있게 하며, 기능 추가나 변경이 다른 부분에 미치는 영향을 최소화합니다.

• 🛠️런타임에 기능 조합 가능
• ⚙️클래스 수 최소화로 유지보수 용이
• 🔌OCP 원칙 준수
• 💡독립적 모듈로 테스트 및 수정 용이

결론적으로, 상속 대신 Decorator를 사용하면 기능 확장에 필요한 유연성을 확보하면서도, 코드의 안정성과 재사용성을 유지할 수 있습니다.
이러한 장점 덕분에 많은 개발자들이 실무에서 Decorator 패턴을 선호합니다.

🔌 Java에서의 Decorator 구현 예시

Java에서 Decorator 패턴을 구현할 때는 인터페이스 또는 추상 클래스를 기반으로 한 컴포넌트 구조를 먼저 정의합니다.
그 후, 실제 기능을 수행하는 구체 클래스(Concrete Component)와, 해당 객체를 감싸 추가 기능을 제공하는 Decorator 클래스를 작성합니다.
이 방식은 GUI 컴포넌트, 스트림 처리, 로깅 등 다양한 분야에서 널리 활용됩니다.

☕ 커피 주문 예제

다음 예제는 커피 주문 시스템에 Decorator 패턴을 적용한 코드입니다.
이 예제에서는 기본 커피에 다양한 옵션(우유, 시럽, 휘핑크림 등)을 조합하여 새로운 메뉴를 동적으로 생성할 수 있습니다.

// Component
public interface Coffee {
    String getDescription();
    double cost();
}

// Concrete Component
public class BasicCoffee implements Coffee {
    public String getDescription() { return "Basic Coffee"; }
    public double cost() { return 2.0; }
}

// Base Decorator
public abstract class CoffeeDecorator implements Coffee {
    protected Coffee decoratedCoffee;
    public CoffeeDecorator(Coffee coffee) { this.decoratedCoffee = coffee; }
    public String getDescription() { return decoratedCoffee.getDescription(); }
    public double cost() { return decoratedCoffee.cost(); }
}

// Concrete Decorators
public class MilkDecorator extends CoffeeDecorator {
    public MilkDecorator(Coffee coffee) { super(coffee); }
    public String getDescription() { return super.getDescription() + ", Milk"; }
    public double cost() { return super.cost() + 0.5; }
}

public class WhipDecorator extends CoffeeDecorator {
    public WhipDecorator(Coffee coffee) { super(coffee); }
    public String getDescription() { return super.getDescription() + ", Whip"; }
    public double cost() { return super.cost() + 0.7; }
}

// Usage
Coffee order = new WhipDecorator(new MilkDecorator(new BasicCoffee()));
System.out.println(order.getDescription() + " $" + order.cost());

이 예제에서 MilkDecorator와 WhipDecorator는 각각 기능을 확장하는 독립적인 클래스입니다.
필요한 옵션을 원하는 순서대로 감싸서 조합할 수 있으며, 이렇게 하면 클래스의 개수는 최소화하면서도 무한한 조합이 가능합니다.

📂 Java API 속 Decorator 예시

Java의 java.io 패키지는 Decorator 패턴의 대표적인 예시입니다.
예를 들어, BufferedInputStream은 InputStream을 감싸서 버퍼링 기능을 제공합니다.
이처럼 Decorator 패턴은 다양한 표준 라이브러리에서도 확인할 수 있는 실무 친화적인 설계 방식입니다.

💡 Decorator 패턴 활용 시 주의사항

Decorator 패턴은 강력한 확장성과 유연성을 제공하지만, 잘못 사용하면 복잡성과 관리 비용이 증가할 수 있습니다.
효과적으로 사용하기 위해서는 몇 가지 주의할 점을 반드시 기억해야 합니다.

📏 Decorator의 과도한 중첩 피하기

Decorator는 여러 개를 중첩해서 사용할 수 있지만, 중첩이 과도해지면 코드 가독성이 떨어지고 디버깅이 어려워집니다.
필요 이상으로 많은 Decorator를 적용하는 것은 지양하고, 적절한 조합만 사용해야 합니다.

🔍 공통 기능은 상위 레벨에서 처리

여러 Decorator에서 반복되는 기능이 있다면, 이를 상위 Decorator 클래스나 별도의 유틸리티로 추출하는 것이 좋습니다.
중복 코드를 줄이면 유지보수성과 확장성이 함께 향상됩니다.

⚠️ 성능 고려

Decorator는 객체를 여러 겹으로 감싸는 구조이기 때문에 호출 체인이 길어질 수 있습니다.
이로 인해 성능 저하가 발생할 수 있으므로, 성능이 중요한 애플리케이션에서는 Decorator의 계층 깊이를 제한하는 것이 바람직합니다.

🛠️ 테스트 전략

각 Decorator는 개별적으로 테스트할 수 있도록 설계하는 것이 좋습니다.
기능을 모듈 단위로 검증하면 문제 발생 시 원인을 빠르게 파악할 수 있으며, 조합 시에도 안정성을 확보할 수 있습니다.

이러한 주의사항을 염두에 두면, Decorator 패턴은 상속의 단점을 보완하면서도 확장성과 유지보수성을 모두 잡는 훌륭한 설계 도구가 될 수 있습니다.

❓ 자주 묻는 질문 (FAQ)