Design pattern 8. Delegate Pattern

✅ Delegate Pattern란?

• 객체 지향 설계에서 자신이 해야 할 작업을 다른 객체에 위임(delegate) 하는 패턴

• 델리게이트 패턴은 어떤 객체가 자신이 처리해야 할 작업을 다른 객체에 위임하는 구조

• 즉, 자기가 직접 처리하지 않고 대신 해줄 다른 객체에게 전달(위임)

✅ 핵심 개념

• 위임(Delegation) = “나 대신 저 친구가 처리하게 할게!”

• 상속보다 합성(composition)과 위임을 선호하는 설계 방식

• 주로 유연한 책임 분리나 로직 재사용을 위해 사용됨

✅ 구조

┌─────────────┐
│ Client       │      호출자
└────┬────────┘
     │ 호출
     ▼
┌─────────────┐
│ Delegator    │     → 일을 맡는 객체
│ (위임자)     │
│ has a Delegate │
└────┬────────┘
     │ 위임
     ▼
┌─────────────┐
│ Delegate     │     → 실제로 일을 처리하는 객체
└─────────────┘

✅ 예시 (자바 스타일)

public interface Printer {
    void print(String message);
}

public class ConsolePrinter implements Printer {
    public void print(String message) {
        System.out.println("출력: " + message);
    }
}

public class Report {
    private Printer printer; // 위임할 대상

    public Report(Printer printer) {
        this.printer = printer;
    }

    public void generate(String content) {
        // 본인은 직접 출력하지 않고 프린터에게 위임
        printer.print("리포트 내용: " + content);
    }
}

Printer printer = new ConsolePrinter();
Report report = new Report(printer);

report.generate("월간 매출 보고서");

✅ Delegate Pattern vs Decorator Pattern

✅ 실전 활용 예

✅ 장점

✅ 요약

✅ Delegate Pattern vs Proxy Pattern

• Delegate(델리게이트) 패턴과 Proxy(프록시) 패턴은 자신의 작업을 다른 객체에 위임한다는 점에서 아주 비슷하지만 의도와 책임, 목적에서 차이가 있다.

✅ 공통점

✅ 차이점

✅ 간단한 비유

• Delegate:

“나는 일 못 해. 옆에 있는 전문가한테 물어봐.”

• Proxy:

“일단 나를 통해서 요청해. 내가 검토하고 진짜 객체에 전달할게.”

 

✅ 코드로 짧게 비교

🔸 Delegate

class Printer {
    void print(String msg) {
        System.out.println(msg);
    }
}

class Report {
    Printer printer;
    void generate() {
        printer.print("Report");
    }
}

Report는 Printer에게 출력 책임을 위임만 함

🔸 Proxy

class PrinterProxy {
    private RealPrinter realPrinter = new RealPrinter();

    void print(String msg) {
        System.out.println("접근 로그 기록...");
        realPrinter.print(msg);
    }
}

PrinterProxy는 자체적으로 부가 로직 수행 후, 실제 객체에게 전달

✅ 결론

✅ Delegate Pattern vs Strategy Pattern

• 둘 다 작업을 외부 객체에 위임한다는 공통점이 있지만, 의도와 유연성, 설계 방향에서 중요한 차이점이 있습니다.

✅ 비교 표

✅ 예제로 비교

class Printer {
    void print(String msg) {
        System.out.println(msg);
    }
}

class Report {
    Printer printer;

    public Report(Printer printer) {
        this.printer = printer;
    }

    void generate() {
        printer.print("리포트 출력");
    }
}

• Report는 항상 같은 Printer에게 위임함 (선택 아님)

• 단순히 역할 분리가 목적

interface PaymentStrategy {
    void pay(int amount);
}

class CardPayment implements PaymentStrategy {
    public void pay(int amount) {
        System.out.println("💳 카드로 결제: " + amount);
    }
}

class KakaoPayPayment implements PaymentStrategy {
    public void pay(int amount) {
        System.out.println("📱 카카오페이로 결제: " + amount);
    }
}

class Order {
    private PaymentStrategy payment;

    public void setPaymentStrategy(PaymentStrategy payment) {
        this.payment = payment;
    }

    public void checkout(int amount) {
        payment.pay(amount);
    }
}

• Order는 전략을 선택하고 갈아낄 수 있음

• 상황에 따라 카드, 카카오페이 등 전략을 다르게 설정 가능

✅ 핵심 차이 요약

✅ 마무리 요약

• Delegate Pattern → “내가 하기 싫으니까 대신 해줘”

• Strategy Pattern → 지금 상황에 가장 알맞은 방법을 선택해서 써야 해”

실습

package ex07.teacher;

public interface Teacher {
    void doLecture();

    boolean isSameLecture(LectureType lectureType);  // 책임: 누구한테 위임할지 결정
}

package ex07.teacher;

public enum LectureType {
    MATH, SCIENCE, HISTORY;
}

package ex07.teacher;

public class MathTeacher implements Teacher {
    public void doLecture() {
        System.out.println("수학 강의를 시작합니다");
    }


    @Override
    public boolean isSameLecture(LectureType lectureType) {
        return LectureType.MATH.equals(lectureType);
    }
}

package ex07.teacher;

public class HistoryTeacher implements Teacher {

    public void doLecture() {
        System.out.println("역사 강의를 시작합니다");
    }

    @Override
    public boolean isSameLecture(LectureType lectureType) {
        return LectureType.HISTORY.equals(lectureType);
    }
}

package ex07.teacher;

import java.util.ArrayList;
import java.util.List;

// 책임: 요청에 맞는 전문가를 찾아서 위임 - 단일진입점
// 단일 진입점을 만들면 좋은 이유 - 하나의 오브젝트만 바라볼 수 있음
public class LectureDelegator {
    private List<Teacher> teachers = new ArrayList<>();

    public LectureDelegator() {
        teachers.add(new HistoryTeacher());
        teachers.add(new MathTeacher());
    }

    public void delegate(LectureType lectureType) {
        teachers
                .stream()
                .filter(teacher -> teacher.isSameLecture(lectureType))
                .forEach(teacher -> {
                    teacher.doLecture();
                });

    }

}

package ex07;


import ex07.teacher.LectureDelegator;
import ex07.teacher.LectureType;


// Delegate (위임)
public class App {
    public static void main(String[] args) {
        LectureDelegator lectureDelegator = new LectureDelegator();

        // 1.  수학
        lectureDelegator.delegate(LectureType.MATH); // 타입으로 찾아서 위임

        // 2. 역사
        lectureDelegator.delegate(LectureType.HISTORY);  // 타입으로 찾아서 위임
    }
}