[Java] Composition vs Inheritance — 언제 써야 하나?

🧠 Composition vs Inheritance — 언제 써야 하나?

---

✅ 1. 기본 개념 정리

📌 Inheritance (상속)

• "is-a" 관계일 때 사용
• 한 클래스가 다른 클래스의 필드와 메서드를 상속받아 확장
• 계층 구조를 형성하며 코드 재사용에 유리

  

    
    
    
    
  
class Animal {
    void eat() { System.out.println("eating..."); }
}

class Dog extends Animal {
    void bark() { System.out.println("bark!"); }
}

✅ Dog is-a Animal → 올바른 상속

---

📌 Composition (구성)

• "has-a" 관계일 때 사용
• 클래스 내부에 다른 클래스의 인스턴스를 필드로 포함시켜 사용
• 상속보다 유연하며, 역할 분리와 기능 조합에 유리

  

    
    
    
    
  
class Engine {
    void run() { System.out.println("Engine running"); }
}

class Car {
    private Engine engine = new Engine();

    void start() {
        engine.run();  // Engine의 기능을 사용
    }
}

✅ Car has-a Engine → 구성 관계

---

✅ 2. 차이점 요약

항목	Inheritance (상속)	Composition (구성)
관계	is-a	has-a
결합도	높음	낮음
유연성	낮음	높음
테스트 용이성	낮음	높음
변경 영향	큼 (부모 변경 시 자식 영향)	작음 (필요한 기능만 포함)
사용 예	타입 확장	기능 조합, 위임

---

❗ 3. ❌ 언제 상속을 피해야 할까? + ✅ 언제 상속을 써야 할까?

❌ 피해야 할 상황들

❌ 예1: 단순히 기능 재사용 목적으로만 상속할 때

  

    
    
    
    
  
class FileLogger {
    void log(String message) {
        System.out.println("LOG: " + message);
    }
}

class User extends FileLogger { // ❌ User is-a FileLogger?
    String name;
}

📌 User는 로그를 남기기 위해 상속을 받았지만 User is-a FileLogger는 말이 안 됨
➡️ 잘못된 상속

✅ 올바른 방식 (Composition):

  

    
    
    
    
  
class User {
    String name;
    FileLogger logger = new FileLogger();

    void doSomething() {
        logger.log("User did something");
    }
}

---

❌ 예2: 부모 변경 시 자식까지 영향 받는 경우

  

    
    
    
    
  
class Animal {
    void move() {
        System.out.println("Animal moves");
    }
}

class Snake extends Animal {
    // Snake는 부모 메서드만 사용 중
}

부모 수정:

  

    
    
    
    
  
class Animal {
    void move() {
        // 이동 시 로깅 추가됨
        System.out.println("LOG: animal moving...");
    }
}

📌 예상치 못한 변경이 자식 클래스 전체에 영향을 미침
➡️ 캡슐화 깨짐

그 구조를 상속 대신 구성(Composition)으로 바꿨을 때 어떤 식으로 되는지

---

✅ 상속 구조 (문제 상황 다시 복습)

1. 상속 시 부모 클래스 변경 → 자식 클래스 영향 받는 이유

 

📌 개념 설명

상속은 부모의 모든 필드와 메서드를 자식 클래스가 그대로 "물려받는" 구조입니다.
이는 매우 강력하지만, 부모가 변경되면 자식이 자동으로 영향을 받기 때문에 취약합니다.

이걸 강한 결합(high coupling) 이라고 해요.

---

❗ 문제 요약

부모 클래스의 내부 구현이 바뀌면,
자식 클래스는 알지 못한 채 그 영향을 그대로 받는다.

 

💡 예제 설명

  

    
    
    
    
  
class Animal {
    void move() {
        System.out.println("Animal moves");
    }
}

class Snake extends Animal {
    // 아무 것도 오버라이딩 안 함 → Animal의 move() 사용
}

 

💥 그런데 Animal의 내부가 변경되면 ...

  

    
    
    
    
  
class Animal {
    void move() {
        logGPS();  // 예: 추가된 로깅 기능 (성능 저하 가능성)
        System.out.println("Animal moves");
    }
}

 

❗ 문제

  

    
    
    
    
  
Snake s = new Snake();
s.move();  // 출력: Animal moves with tracking
           // → 의도치 않게 GPS 로그 기능까지 따라옴

• Snake는 move() 내부가 변경된 사실도 모르고 따라옴
• 테스트도 예외 없이 영향받고, 성능 문제 발생 가능

---

🔍 요약: 상속은 내부 구현까지 강하게 결합되므로, 부모 변경이 자식에게 그대로 전달된다.

➡️ 이런 상황을 방지하려면 구성(Composition)을 사용하는 것이 더 안전하다.

---

✅ 구성(Composition) 구조로 리팩토링하면?

  

    
    
    
    
  
class AnimalMover {
    void move() {
        System.out.println("Animal moves");
    }
}

class Snake {
    private AnimalMover mover = new AnimalMover();

    void move() {
        mover.move();
    }
}

🔄 이렇게 하면…

• Snake는 AnimalMover 객체를 "가지고" 있어요 (has-a 관계)
• AnimalMover가 변경되더라도, Snake는 선택적으로 대응할 수 있어요

---

✅ 구성의 핵심 장점: 유연하게 교체 가능!

  

    
    
    
    
  
class AnimalMoverWithLogging extends AnimalMover {
    @Override
    void move() {
        logGPS();  // 성능 비용이 큰 기능
        super.move();
    }
}

  

    
    
    
    
  
Snake snake = new Snake();
snake.setMover(new AnimalMoverWithLogging());  // 전략 변경 가능

➡️ 런타임에 어떤 mover를 쓸지 교체 가능 → 전략 패턴 응용 가능

---

✅ 전체 코드 예시 (리팩토링 버전)

  

    
    
    
    
  
// 움직임을 담당하는 구성 요소
class AnimalMover {
    void move() {
        System.out.println("Animal moves");
    }
}

// 부가 기능이 추가된 전략
class AnimalMoverWithLogging extends AnimalMover {
    @Override
    void move() {
        logGPS();
        super.move();
    }

    private void logGPS() {
        System.out.println("[GPS 로그]: 위치 기록됨");
    }
}

// Snake는 Animal이 아닌 별도 클래스 → 구성 사용
class Snake {
    private AnimalMover mover;

    Snake(AnimalMover mover) {
        this.mover = mover;
    }

    void move() {
        mover.move();  // 동작 위임
    }

    void setMover(AnimalMover newMover) {
        this.mover = newMover;  // 전략 교체도 가능
    }
}

---

✅ 실행 예시

  

    
    
    
    
  
public class Main {
    public static void main(String[] args) {
        Snake snake = new Snake(new AnimalMover());
        snake.move();
        // 출력: Animal moves

        // 동작 전략 교체
        snake.setMover(new AnimalMoverWithLogging());
        snake.move();
        // 출력:
        // [GPS 로그]: 위치 기록됨
        // Animal moves
    }
}

---

✅ 구성으로 바꾸면 생기는 장점

항목	설명
유연성	필요할 때 동작을 교체 가능 (예: 테스트용, 성능 제한용 등)
테스트성	가짜 mover 넣어서 테스트 가능 (MockMover)
결합도 낮음	Snake는 mover의 인터페이스에만 의존
재사용성	AnimalMover를 다른 클래스에서도 재사용 가능
변경 안전성	부모 클래스 변화에 자동으로 영향받지 않음

---

🧠 결론

상속 구조에서는 부모 클래스 변경이 자식에게 자동 전파되어 위험하지만,
구성을 사용하면 기능을 객체로 분리해 선택적으로 포함하거나 교체 가능하기 때문에
훨씬 안정적이고 유연한 구조를 만들 수 있습니다.

 

---

❌ 예3: 테스트 어려움 (상속 깊이로 인해)

  

    
    
    
    
  
class UserService extends DatabaseService {
    void registerUser() {
        // DB 연결부터 강제로 포함됨
    }
}

✅ 구성으로 대체:

  

    
    
    
    
  
class UserService {
    private DatabaseService db;

    UserService(DatabaseService db) {
        this.db = db; // 의존성 주입
    }
}

➡️ 유닛 테스트 가능, 유연성 ↑

---

✅ 그럼 언제 상속을 써야 할까?

✅ 예1: 진짜 is-a 관계일 때

  

    
    
    
    
  
class Vehicle {
    void move() { System.out.println("Vehicle moving"); }
}

class Bus extends Vehicle {
    void openDoors() { System.out.println("Doors opened"); }
}

➡️ Bus is-a Vehicle → 논리적 타입 확장으로 적절

---

✅ 예2: 기본 동작을 확장하고 싶을 때

  

    
    
    
    
  
class Button {
    void click() {
        System.out.println("Button clicked");
    }
}

class AnimatedButton extends Button {
    @Override
    void click() {
        super.click();
        System.out.println("...with animation");
    }
}

➡️ 부모 기본 동작을 확장해서 쓰는 경우는 상속이 적합

---

✅ 4. 언제 Composition을 써야 할까?

✅ 예1: 기능 조합이 목적일 때

  

    
    
    
    
  
class NotificationSender {
    void send(String msg) {
        System.out.println("Sending: " + msg);
    }
}

class OrderService {
    NotificationSender sender = new NotificationSender();

    void completeOrder() {
        sender.send("Order completed!");
    }
}

➡️ OrderService is-a Sender는 아님 → 기능만 포함해서 사용

---

✅ 예2: 동작을 유연하게 교체해야 할 때 (전략 패턴)

  

    
    
    
    
  
interface PayStrategy {
    void pay(int amount);
}

class KakaoPay implements PayStrategy {
    public void pay(int amount) {
        System.out.println("Paid with KakaoPay");
    }
}

class PaymentProcessor {
    PayStrategy strategy;

    PaymentProcessor(PayStrategy strategy) {
        this.strategy = strategy;
    }

    void process(int amount) {
        strategy.pay(amount);
    }
}

➡️ 런타임에 전략(결제 수단) 교체 가능 → 구성 방식의 대표적 장점

✅ 전략 패턴을 통해 구성(Composition)으로 동작을 유연하게 교체하는 방식

 

📌 개념 설명

때때로 우리는 같은 동작을 상황에 따라 다르게 처리하고 싶을 수 있습니다.

예를 들어:

• 오늘은 카카오페이로 결제
• 내일은 신용카드로 결제
• 테스트 환경에서는 가짜 결제로 처리

이때 상속으로는 동작 교체가 어렵고,
인터페이스 + 구성(Composition) 을 활용하면 유연하게 처리할 수 있습니다.

➡️ 이 방식이 전략 패턴 (Strategy Pattern) 입니다.

---

🎯 전략 패턴 개념 요약

요소	역할
인터페이스	공통 동작의 "계약" 정의 (ex. pay)
구현 클래스	각각의 전략을 실제로 구현 (ex. KakaoPay, CardPay)
Context 클래스	동작을 실행하지만 전략은 "바깥에서 주입"받음

---

✅ 예제 코드

 

1) 공통 동작 정의 (인터페이스)

  

    
    
    
    
  
interface PayStrategy {
    void pay(int amount);
}

 

2) 전략 구현체 (여러 개)

  

    
    
    
    
  
class KakaoPay implements PayStrategy {
    public void pay(int amount) {
        System.out.println("Paid " + amount + " with KakaoPay");
    }
}

class CardPay implements PayStrategy {
    public void pay(int amount) {
        System.out.println("Paid " + amount + " with Credit Card");
    }
}

 

3) 실행 클래스 (전략을 받아서 위임)

  

    
    
    
    
  
class PaymentProcessor {
    private PayStrategy strategy;

    public PaymentProcessor(PayStrategy strategy) {
        this.strategy = strategy;
    }

    public void process(int amount) {
        strategy.pay(amount);  // 전략에게 실행 위임
    }
}

---

🧪 사용 예시

  

    
    
    
    
  
PayStrategy strategy = new KakaoPay(); // 전략 선택
PaymentProcessor processor = new PaymentProcessor(strategy);

processor.process(10000);  // 출력: Paid 10000 with KakaoPay

// 전략 교체
processor = new PaymentProcessor(new CardPay());
processor.process(10000);  // 출력: Paid 10000 with Credit Card

---

💡 이 구조의 장점

장점	설명
유연성	실행 중 전략(동작)을 쉽게 교체 가능
테스트 용이	모의 전략(MockStrategy)으로 테스트 가능
재사용성	전략 구현체들을 다른 곳에서도 활용 가능
결합도 낮음	실행 클래스는 PayStrategy에만 의존하고, 구체 구현체는 몰라도 됨

---

📌 정리: 전략 패턴이 필요한 상황

• 특정 기능(예: 결제, 정렬, 출력)을 다양한 방식으로 구현해야 할 때
• 실행 중에 전략을 바꾸고 싶을 때
• 테스트 시 실제 전략 대신 가짜(Mock)를 쓰고 싶을 때
• 상속보다 더 유연한 구조를 만들고 싶을 때

---

✅ 결론 요약

항목	상속 (Inheritance)	구성 (Composition)
구조	계층적 (is-a)	조합적 (has-a, uses-a)
변경에 대한 강건함	약함 (부모 변경 → 자식 영향)	강함 (내부 구성만 교체)
동작 확장	상속 or 오버라이딩	인터페이스 기반 전략 교체
유연성	낮음	✅ 높음
테스트 용이성	어려움	✅ 높음

 

---

✅ 예3: 단위 테스트가 필요한 경우

  

    
    
    
    
  
class ReportGenerator {
    FileWriter writer;

    ReportGenerator(FileWriter writer) {
        this.writer = writer;
    }

    void generate() {
        writer.write("Report...");
    }
}

➡️ 실제 실행에서는 FileWriter, 테스트에서는 MockWriter 사용 가능

---

🎯 결론 요약: 언제 어떤 걸 써야 하나?

상황	상속 (Inheritance)	구성 (Composition)
진짜로 is-a 관계일 때	✅ 사용	❌ 불필요
기능 재사용이 목적일 때	❌ 위험	✅ 유리
유연하게 교체 가능해야 할 때	❌ 불편	✅ 가능
테스트, 확장 고려 시	❌ 단점 많음	✅ 장점 많음
관계가 has-a / uses-a	❌ 부적절	✅ 적절
대표 적용 패턴	템플릿 메서드 패턴	전략 패턴, 데코레이터, DI

---

🧠 핵심 철학

✅ "가능한 한 상속보다 구성을 선호하라 (Favor composition over inheritance)"
— Effective Java, Joshua Bloch

---