Composition Over Inheritance

Composition Over Inheritance

“Composition Over Inheritance” 는 객체지향 프로그래밍에서 코드 재사용과 유연한 설계를 위해 상속보다 컴포지션을 우선적으로 활용하라는 설계 원칙이다. 상속의 단점인 강한 결합도와 클래스 폭발 문제를 해결하고자 한다. 인터페이스와 컴포지션을 통해 런타임 유연성을 제공하며, 인터페이스와 컴포지션을 통해 런타임 유연성을 제공하며, Bridge, Decorator, Strategy 등 다양한 디자인 패턴의 기반이 된다. 특히 다중 상속의 Diamond Problem 을 회피하고 단일 책임 원칙을 지원하여 현대적인 소프트웨어 설계에서 필수적인 원칙이다.

핵심 개념

Composition Over Inheritance (컴포지션 우선 원칙) 은 객체지향 프로그래밍에서 클래스들이 상속을 통한 “is-a” 관계보다는 컴포지션을 통한 “has-a” 관계로 기능을 재사용하고 다형성을 구현해야 한다는 설계 원칙이다.

• 컴포지션 (Composition, 구성): 객체가 다른 객체를 포함 (참조) 하여 기능을 조합하는 방식
• 상속 (Inheritance, 상속): 부모 클래스의 속성과 메서드를 자식 클래스가 물려받는 방식.

전략 패턴 (Strategy Pattern), 데코레이터 패턴 (Decorator Pattern) 등 다양한 디자인 패턴에서 이 원칙이 적용된다.

배경

역사적 배경:

• 1990 년대 초 객체지향 프로그래밍이 대중화되면서 상속 남용 문제 발생
• GoF(Gang of Four) 가 1994 년 “Design Patterns” 책에서 공식적으로 제시
• 상속의 단점인 강한 결합도, 클래스 폭발, 다중 상속 문제 해결 필요성 대두

문제 상황:

• 상속 계층이 깊어질수록 복잡성 증가
• 부모 클래스 변경 시 모든 자식 클래스에 영향
• 다중 상속에서 Diamond Problem 발생
• 런타임에 행동 변경의 어려움

목적 및 필요성

주요 원리 및 작동 원리

객체가 필요한 기능 (행동) 을 인터페이스로 정의하고, 해당 기능을 구현한 객체를 조합하여 원하는 기능을 완성한다.

작동 원리 다이어그램

graph TD
    A[Client] --> B[CompositeClass]
    B --> C[Interface1]
    B --> D[Interface2]
    C --> E[Implementation1A]
    C --> F[Implementation1B]
    D --> G[Implementation2A]
    D --> H[Implementation2B]
    
    style A fill:#e1f5fe
    style B fill:#f3e5f5
    style C fill:#e8f5e8
    style D fill:#e8f5e8
    style E fill:#fff3e0
    style F fill:#fff3e0
    style G fill:#fff3e0
    style H fill:#fff3e0

상속 (Inheritance) vs. 컴포지션 (Composition) 비교

상속은 명확한 계층적 관계와 다형성이 필요한 경우에 적합하며, 컴포지션은 유연성, 재사용성, 테스트 용이성이 중요한 현대적 소프트웨어 개발에 더 적합하다. “Composition Over Inheritance” 원칙에 따라 컴포지션을 기본으로 선택하고, 명확한 is-a 관계가 존재하는 경우에만 상속을 사용하는 것이 권장된다.

기술적 특성 비교

설계 관점 비교

개발 및 유지보수 비교

확장성 및 재사용성 비교

사용 시나리오 비교

성능 비교

상속 (Inheritance) vs. 컴포지션 (Composition) 예시

상속 (Inheritance)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# 부모 클래스 정의
class Animal:
    def speak(self):
        print("동물이 소리를 냅니다.")

# 자식 클래스가 부모 클래스를 상속
class Dog(Animal):
    def speak(self):
        print("멍멍!")

dog = Dog()
dog.speak()  # 출력: 멍멍!

graph LR
    subgraph "상속 (Inheritance)"
        A1[BaseClass] --> A2[DerivedClass1]
        A1 --> A3[DerivedClass2]
        A2 --> A4[SubDerivedClass]
    end
    
    
    style A1 fill:#ffcdd2
    style A2 fill:#ffcdd2
    style A3 fill:#ffcdd2
    style A4 fill:#ffcdd2
    

컴포지션 (Composition)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 동물의 행동을 별도의 클래스로 분리
class SpeakBehavior:
    def speak(self):
        print("동물이 소리를 냅니다.")

class Dog:
    def __init__(self, speak_behavior):
        self.speak_behavior = speak_behavior

    def speak(self):
        self.speak_behavior.speak()

dog = Dog(SpeakBehavior())
dog.speak()  # 출력: 동물이 소리를 냅니다.

graph LR    
    subgraph "컴포지션 (Composition)"
        B1[MainClass] --> B2[Component1]
        B1 --> B3[Component2]
        B1 --> B4[Component3]
    end

    style B1 fill:#c8e6c9
    style B2 fill:#c8e6c9
    style B3 fill:#c8e6c9
    style B4 fill:#c8e6c9

구조 및 아키텍처

구성 요소

아키텍처 다이어그램

graph TB
    subgraph "클라이언트 계층"
        Client[클라이언트 코드]
    end
    
    subgraph "조합 계층"
        Composite[컴포지트 클래스]
        Factory[팩토리]
    end
    
    subgraph "인터페이스 계층"
        IFilter[IFilter 인터페이스]
        ILogger[ILogger 인터페이스]
        IHandler[IHandler 인터페이스]
    end
    
    subgraph "구현 계층"
        TextFilter[텍스트 필터]
        LevelFilter[레벨 필터]
        FileLogger[파일 로거]
        ConsoleLogger[콘솔 로거]
        EmailHandler[이메일 핸들러]
        DBHandler[DB 핸들러]
    end
    
    Client --> Composite
    Client --> Factory
    Composite --> IFilter
    Composite --> ILogger
    Composite --> IHandler
    IFilter --> TextFilter
    IFilter --> LevelFilter
    ILogger --> FileLogger
    ILogger --> ConsoleLogger
    IHandler --> EmailHandler
    IHandler --> DBHandler
    Factory --> TextFilter
    Factory --> FileLogger
    Factory --> EmailHandler
    
    style Client fill:#e3f2fd
    style Composite fill:#f3e5f5
    style Factory fill:#f3e5f5
    style IFilter fill:#e8f5e8
    style ILogger fill:#e8f5e8
    style IHandler fill:#e8f5e8
    style TextFilter fill:#fff3e0
    style LevelFilter fill:#fff3e0
    style FileLogger fill:#fff3e0
    style ConsoleLogger fill:#fff3e0
    style EmailHandler fill:#fff3e0
    style DBHandler fill:#fff3e0

구현 기법

장점과 단점

상속의 문제점

합성 우선 상속 원칙이 등장한 이유는 상속이 가진 여러 문제점 때문이다.

1. 강한 결합도:
   상속은 부모 클래스와 자식 클래스 사이에 강한 결합을 만든다. 부모 클래스의 변경이 모든 자식 클래스에 영향을 미친다.

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

   class Animal { void breathe() { System.out.println("Breathing"); } void eat() { System.out.println("Eating normally"); } } class Dog extends Animal { void bark() { System.out.println("Woof"); } } // 나중에 Animal 클래스의 eat() 메서드가 변경됨 class Animal { void breathe() { System.out.println("Breathing"); } void eat() { validateFood(); // 새로운 검증 메서드 추가 System.out.println("Eating with validation"); } private void validateFood() { // 검증 로직 } }

   • 이 변경은 Dog 클래스의 동작에도 영향을 미친다. Dog 클래스의 개발자는 이러한 변경을 예상하지 못했을 수 있다.

2. 취약한 베이스 클래스 문제:
   부모 클래스의 변경이 자식 클래스를 망가뜨릴 수 있는 상황을 취약한 베이스 클래스 문제 라고 한다. 이것은 상속의 주요 문제점 중 하나이다.

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

   class Stack { protected List<Object> elements = new ArrayList<>(); public void push(Object item) { elements.add(item); } public Object pop() { if (elements.isEmpty()) { throw new EmptyStackException(); } return elements.remove(elements.size() - 1); } public int size() { return elements.size(); } } // Stack을 확장하는 MyStack class MyStack extends Stack { public void pushAll(Collection<?> items) { for (Object item : items) { push(item); } } } // 나중에 Stack 클래스가 변경됨 class Stack { // 변경: elements를 private으로 변경 private List<Object> elements = new ArrayList<>(); // 나머지 메서드는 동일 }

   • 이 변경으로 인해 MyStack 클래스의 pushAll 메서드는 더 이상 작동하지 않게 된다.

3. 다중 상속의 제한:
   많은 언어 (Java, C# 등) 는 단일 상속만 지원한다. 이는 여러 소스에서 기능을 상속받아야 할 경우 심각한 제한이 된다.

4. 계층 구조의 경직성:
   상속은 컴파일 타임에 결정되므로, 런타임에 객체의 행동을 변경하기 어렵다. 이는 설계의 유연성을 제한한다.

도전 과제 및 해결책

분류에 따른 종류 및 유형

컴포지션 종류

패턴 유형

구현 방식

실무 적용 예시

활용 사례

사례 1: 온라인 쇼핑몰의 결제 시스템

시나리오: 온라인 쇼핑몰의 결제 시스템에 다양한 결제 수단을 지원.
시스템 구성:

• PaymentStrategy 인터페이스: 결제 방식의 공통 인터페이스를 정의한다.
• CreditCardPayment, PayPalPayment 클래스: PaymentStrategy 인터페이스를 구현하여 각각의 결제 방식을 제공한다.
• ShoppingCart 클래스: PaymentStrategy 객체를 조합하여 결제 기능을 구성한다.

구성 다이어그램:

classDiagram
    class PaymentStrategy {
        <<interface>>
        +pay(amount: float): void
    }

    class CreditCardPayment {
        +pay(amount: float): void
    }

    class PayPalPayment {
        +pay(amount: float): void
    }

    class ShoppingCart {
        -paymentStrategy: PaymentStrategy
        +setPaymentStrategy(strategy: PaymentStrategy): void
        +checkout(amount: float): void
    }

    PaymentStrategy <|-- CreditCardPayment
    PaymentStrategy <|-- PayPalPayment
    ShoppingCart --> PaymentStrategy

워크플로우:

1. 사용자가 결제 수단을 선택한다.
2. 선택된 결제 수단에 해당하는 PaymentStrategy 구현체가 ShoppingCart 에 주입된다.
3. ShoppingCart 는 주입된 PaymentStrategy 를 이용하여 pay(amount) 메서드를 호출하고, 해당 구현체의 로직에 따라 결제가 처리된다.
4. 결제 결과에 따라 후속 처리 (주문 상태 변경, 알림 발송 등) 를 수행한다.

Workflow 다이어그램:

sequenceDiagram
    participant User
    participant ShoppingCart
    participant PaymentStrategy
    participant PayPalPayment
    participant CreditCardPayment

    User->>ShoppingCart: setPaymentStrategy(PayPalPayment)
    User->>ShoppingCart: checkout(100.00)
    ShoppingCart->>PaymentStrategy: pay(100.00)
    PaymentStrategy->>PayPalPayment: pay(100.00)
    PayPalPayment-->>ShoppingCart: 결제 성공
    ShoppingCart-->>User: 주문 완료 알림

담당 역할

사례 2: 게임 캐릭터 시스템

시나리오: 캐릭터는 점프, 공격, 방어 등 다양한 능력을 가질 수 있음. 각 능력을 컴포넌트로 구현하고, 캐릭터 객체에 필요한 능력을 조합하여 부여.

시스템 구성 및 다이어그램:

classDiagram
    class Character {
        +addAbility(Ability)
        +useAbility()
    }
    class Ability {
        +execute()
    }
    class JumpAbility {
        +execute()
    }
    class AttackAbility {
        +execute()
    }
    Character --> Ability : has-a
    Ability <|-- JumpAbility
    Ability <|-- AttackAbility

Workflow:

1. 캐릭터 객체 생성
2. 점프, 공격 등 능력 (Ability) 컴포넌트 생성
3. 캐릭터에 필요한 능력 추가
4. 캐릭터가 상황에 따라 능력 사용

역할:

• Character: 능력 관리 및 실행
• Ability: 행동 인터페이스
• JumpAbility/AttackAbility: 구체적 행동 구현

사례 3: 로깅 시스템 구현

시나리오: 대규모 웹 애플리케이션에서 다양한 레벨의 로그를 여러 출력 대상 (콘솔, 파일, 데이터베이스, 이메일) 으로 전송하고, 각각에 다른 필터링 규칙을 적용해야 하는 상황

시스템 구성:

graph TB
    subgraph "클라이언트 애플리케이션"
        App[Web Application]
    end
    
    subgraph "로깅 시스템"
        Logger[Logger]
        FilterChain[Filter Chain]
        HandlerManager[Handler Manager]
    end
    
    subgraph "필터 컴포넌트"
        LevelFilter[Level Filter]
        TextFilter[Text Filter]
        TimeFilter[Time Filter]
    end
    
    subgraph "핸들러 컴포넌트"
        ConsoleHandler[Console Handler]
        FileHandler[File Handler]
        DBHandler[Database Handler]
        EmailHandler[Email Handler]
    end
    
    subgraph "포맷터 컴포넌트"
        SimpleFormatter[Simple Formatter]
        JSONFormatter[JSON Formatter]
        XMLFormatter[XML Formatter]
    end
    
    App --> Logger
    Logger --> FilterChain
    Logger --> HandlerManager
    FilterChain --> LevelFilter
    FilterChain --> TextFilter
    FilterChain --> TimeFilter
    HandlerManager --> ConsoleHandler
    HandlerManager --> FileHandler
    HandlerManager --> DBHandler
    HandlerManager --> EmailHandler
    ConsoleHandler --> SimpleFormatter
    FileHandler --> JSONFormatter
    DBHandler --> JSONFormatter
    EmailHandler --> XMLFormatter
    
    style App fill:#e3f2fd
    style Logger fill:#f3e5f5
    style FilterChain fill:#f3e5f5
    style HandlerManager fill:#f3e5f5
    style LevelFilter fill:#e8f5e8
    style TextFilter fill:#e8f5e8
    style TimeFilter fill:#e8f5e8
    style ConsoleHandler fill:#fff3e0
    style FileHandler fill:#fff3e0
    style DBHandler fill:#fff3e0
    style EmailHandler fill:#fff3e0

활용 사례 Workflow:

sequenceDiagram
    participant App as Application
    participant Logger as Logger
    participant FC as FilterChain
    participant HM as HandlerManager
    participant CH as ConsoleHandler
    participant FH as FileHandler
    participant EH as EmailHandler
    
    App->>Logger: log("ERROR: Database connection failed")
    Logger->>FC: filter(message)
    FC->>FC: LevelFilter.filter(ERROR)
    FC->>FC: TextFilter.filter("Database")
    FC->>Logger: return true (passed)
    Logger->>HM: handle(message)
    HM->>CH: handle(message)
    CH->>CH: format & output to console
    HM->>FH: handle(message)
    FH->>FH: format & write to file
    HM->>EH: handle(message)
    EH->>EH: format & send email alert
    Logger->>App: return success

컴포지션의 역할:

1. 유연한 구성:

   • 런타임에 필터와 핸들러 조합 변경 가능
   • 새로운 출력 형식 추가 시 기존 코드 수정 불필요

2. 독립적 테스트:

   • 각 컴포넌트를 Mock 객체로 대체하여 단위 테스트
   • 통합 테스트에서 실제 구현체 조합

3. 확장성:

   • 새로운 필터 유형 추가 (예: 사용자별 필터)
   • 새로운 출력 대상 추가 (예: Slack, Teams)

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

1. 기능 단위 분리와 인터페이스화를 선행하지 않으면 컴포지션의 이점이 퇴색된다.
2. 조합 대상의 책임이 명확하지 않거나 너무 많을 경우 구조가 오히려 상속보다 더 복잡해진다.
3. 의존성 주입 없이 직접 객체 생성 시, 객체 수명 및 테스트 통제가 어려워질 수 있다.
4. 설계 문서와 코드 간 괴리가 생기지 않도록, 초기 설계와 실제 구현을 지속적으로 동기화해야 한다.
5. 성능 저하 요소(과도한 위임, 깊은 객체 참조 등) 는 반드시 사전 프로파일링과 모니터링으로 검증해야 한다.

최적화하기 위한 고려사항 및 주의할 점

주제와 관련하여 주목할 내용

하위 주제로 분류해서 추가적으로 학습해야 할 내용

관련 분야별 추가 학습 내용

용어 정리

객체지향 설계 핵심 개념

객체지향 설계 원칙

디자인 패턴

소프트웨어 품질 속성 (결합도/응집도)

객체지향 구조 문제 및 한계

성능 및 최적화 관련 기법

참고 및 출처

• Composition over Inheritance by Martin Fowler
• Composition over inheritance - Wikipedia
• Favoring Composition Over Inheritance In Java - GeeksforGeeks
• 5 Reasons to Use Composition over Inheritance - Java Revisited
• Composition vs Inheritance - DigitalOcean
• Composition Over Inheritance - Python Patterns Guide
• Inheritance and Composition: A Python OOP Guide - Real Python
• Composition over Inheritance - DEV Community
• Composition over Inheritance in Game Development - CKHang
• 상속보다 구성을 선호하는 것은 설계의 유연성을 높이는 설계 원칙이다 - Veluxer’s Blog
• 상속보다는 컴포지션을 선호해야 하는 이유 - Tistory
• 상속과 컴포지션 비교 - Velog 블로그
• 상속보다 컴포지션을 사용해야하는 이유 - Gyoogle
• SOLID Principles - DigitalOcean
• Design Patterns: Elements of Reusable Object-Oriented Software - GoF
• Refactoring Guru - Strategy Pattern
• Refactoring Guru - Decorator Pattern
• Effective Java - Joshua Bloch
• Head First Design Patterns
• Spring Dependency Injection Reference
• NestJS Dependency Injection
• StackOverflow - Composition vs Inheritance
• OOP Design Principles - TRCCompSci
• Composition Over Inheritance Principle - LinkedIn Article