Day 41 — 행동 패턴: 행동을 갈아끼우고, 사건을 구독하기

지난 시간 Day 40 에서는 객체를 만들어내는 네 가지 방법을 배웠어요. Singleton 으로 딱 하나만, Builder 로 이름표 붙여 쌓고, Factory 로 무엇을 만들지 한 곳에서 결정했죠. 전부 "객체가 태어나는 순간" 을 다루는 생성 패턴이었어요.

오늘은 한 걸음 더 나아가요. 객체를 다 만들었으면, 이제 그 객체가 어떻게 동작하느냐 가 남아요. 그런데 동작이라는 건 자주 바뀌어요. 알림을 이메일로 보내다가 푸시로 바꾸고 싶고, 좋아요가 눌리면 알림도 보내고 숫자도 올리고 기록도 남겨야 하죠. 이렇게 행동을 유연하게 다루는 패턴들을 행동 패턴(behavioral pattern) 이라고 불러요.

오늘은 그중 가장 많이 쓰이는 두 가지를 만나봐요. 행동을 통째로 갈아끼우는 Strategy, 그리고 한 사건에 여러 곳이 알아서 반응하게 하는 Observer. 둘 다 우리가 이미 만들어둔 인스타그램 코드 위에서 자연스럽게 자라나요. 시작해봐요!

🎯 학습 목표

• if-else 로 동작을 분기할 때 코드가 어떻게 부풀어 오르는지 — 그 불편을 몸으로 느껴요.
• Strategy — 행동(알고리즘)을 통째로 갈아끼우는 법. 지난 Day 14 에서 만든 알림 채널을 그대로 전략으로 써요.
• 람다로 전략을 더 가볍게 — 단일 메서드 인터페이스의 힘.
• Observer — 한 사건에 여러 곳이 각자 반응하게 하는 법 (발행과 구독의 분리).
• Strategy 와 Observer 가 어떻게 다른지, 언제 무엇을 꺼낼지 가늠하는 눈.

오늘의 로드맵

• Step 1 — 같은 일, 다른 방식: if-else 가 늘어나는 고통.
• Step 2 — 행동을 통째로 갈아끼우는 Strategy.
• Step 3 — 사건이 나면 여러 곳이 반응: 일일이 부르는 고통.
• Step 4 — 구독하고 통지받는 Observer.
• Step 5 — 두 패턴 한자리 비교, 그리고 다음 패턴으로 잇기.

Step 1: 같은 일, 다른 방식 — if-else 가 늘어나는 고통

인스타그램에서 알림을 보낸다고 해봐요. 그런데 사용자마다 받고 싶은 방식이 달라요. 누구는 이메일로, 누구는 휴대폰 푸시로, 누구는 문자로 받고 싶어 하죠. 가장 먼저 떠오르는 방법은 "방식을 보고 갈라서 보내기" 예요.

String sendNotification(String type, String message) {
    if (type.equals("EMAIL")) {
        return "[Email] " + message;
    } else if (type.equals("PUSH")) {
        return "[Push] " + message;
    } else if (type.equals("SMS")) {
        return "[SMS] " + message;
    }
    return message;
}

처음엔 깔끔해 보여요. 그런데 문제는 알림 방식이 앞으로도 계속 늘어난다 는 거예요. 슬랙으로도 보내고 싶고, 카카오톡으로도 보내고 싶어지죠. 그럴 때마다 이 메서드를 열어서 else if 한 줄씩 끼워 넣어야 해요.

 sendNotification(type, message) 안에서…
   if (type == EMAIL)      → 이메일로 보내기
   else if (type == PUSH)  → 푸시로 보내기
   else if (type == SMS)   → 문자로 보내기
   else if (type == SLACK) → ??? (새 방식이 생기면 또 여기에 한 줄)
   else if (type == ...)   → ??? (그리고 또, 또…)

이게 왜 문제일까요? Day 14 에서 배운 OCP, 기억하시죠. "기능을 확장할 때는 새 코드를 더하는 쪽이 좋지, 멀쩡히 돌던 기존 코드를 건드리는 건 위험하다" 는 원칙이요. 그런데 지금 이 sendNotification 은 방식 하나 늘 때마다 매번 열어서 고쳐야 해요. 잘 돌던 이메일·푸시 코드 사이에 손을 집어넣는 셈이라, 실수로 옆줄을 건드릴 위험도 같이 커지죠.

그때 Day 14 에서 우리는 이미 답을 한 번 봤어요. 바로 NotificationChannel 이라는 인터페이스였죠. "알림을 보낼 수 있다" 는 역할만 약속으로 정해두고, 이메일·푸시·문자는 각자 그 약속을 지키는 클래스로 따로 떼어냈어요.

// com/instagram/javabasic/design/ocp/NotificationChannel.java
public interface NotificationChannel {

    // 메시지를 채널 형식으로 보내고, 보낸 결과 문구를 돌려줘요.
    String send(String message);
}

이 인터페이스를 지키는 채널들도 이미 만들어뒀고요. 각자 자기 방식대로 send 만 다르게 구현했죠.

// com/instagram/javabasic/design/ocp/EmailChannel.java
public class EmailChannel implements NotificationChannel {

    @Override
    public String send(String message) {
        return "[Email] " + message;
    }
}

PushChannel, SmsChannel 도 똑같은 모양이에요. 각자 "[Push] ", "[SMS] " 만 다르게요. 그때는 이 채널들을 한꺼번에 여러 개에 뿌리는 걸 봤어요. 오늘은 여기서 한 발 더 나아가요. 한 발송기가 상황에 따라 채널 하나를 골라 쓰고, 보내던 도중에도 다른 채널로 갈아끼우는 모습을 볼 거예요. 그게 바로 Strategy 패턴이에요.

Step 2: 행동을 통째로 갈아끼우는 Strategy

Strategy(전략) 패턴의 아이디어는 한 문장이에요. "바뀌는 행동을 객체로 뽑아내서, 통째로 갈아끼울 수 있게 하자." 여기서 "바뀌는 행동" 이 바로 알림을 보내는 방식이에요. 이메일로 보낼지 푸시로 보낼지 — 이 행동 하나하나가 곧 하나의 "전략" 이죠.

우리는 이미 전략의 약속(NotificationChannel)도, 전략들(EmailChannel·PushChannel…)도 가지고 있어요. 이제 필요한 건 그 전략을 품고 있다가, 보낼 때 그 전략에게 맡기는 발송기 하나예요. 이걸 NotificationSender 라고 부를게요.

// com/instagram/javabasic/design/behavioral/strategy/NotificationSender.java
public class NotificationSender {

    // 지금 사용 중인 전략(알림 채널)이에요. 런타임에 다른 채널로 바꿀 수 있어요.
    private NotificationChannel channel;

    // 처음 만들 때 어떤 전략으로 시작할지 외부에서 받아요.
    public NotificationSender(NotificationChannel channel) {
        this.channel = channel;
    }

    // 보내던 도중에도 전략(채널)을 새것으로 갈아끼워요.
    public void changeChannel(NotificationChannel channel) {
        this.channel = channel;
    }

    // 실제로 보낼 때는 직접 하지 않고, 지금 품고 있는 전략에게 맡겨요.
    public String notify(String message) {
        return channel.send(message);
    }
}

핵심은 notify 메서드예요. 자기가 직접 이메일을 보내거나 푸시를 보내지 않아요. 그냥 지금 품고 있는 전략의 send 를 부를 뿐이에요. 그래서 어떤 전략을 품느냐에 따라 똑같은 notify 호출이 완전히 다르게 동작해요.

NotificationSender sender = new NotificationSender(new EmailChannel());
sender.notify("새 댓글");          // "[Email] 새 댓글"

sender.changeChannel(new PushChannel());
sender.notify("새 댓글");          // "[Push] 새 댓글"

같은 sender 에게 같은 notify("새 댓글") 을 시켰는데, 중간에 전략을 갈아끼웠더니 결과가 달라졌어요. 발송기 자체는 한 줄도 안 바꿨는데 말이죠.

   new NotificationSender( EmailChannel )
            │  notify("새 댓글")
            ▼
        품은 전략에게 맡김  →  "[Email] 새 댓글"

   changeChannel( PushChannel )   ← 전략만 통째로 교체
            │  notify("새 댓글")
            ▼
        품은 전략에게 맡김  →  "[Push] 새 댓글"

Step 1 의 if-else 와 비교해봐요. 거기선 새 방식이 생기면 sendNotification 을 열어 고쳐야 했어요. 여기선 새 채널 클래스를 하나 만들어서 changeChannel 으로 끼워주기만 하면 돼요. NotificationSender 는 영원히 그대로예요. 이게 바로 Day 14 에서 봤던 "확장에는 열리고, 수정에는 닫힌" 그 모습이에요.

💡 Strategy 의 핵심은 상속이 아니라 조합 이에요. "이메일 발송기", "푸시 발송기" 처럼 발송기를 종류별로 상속받아 만드는 게 아니라, 발송기는 하나만 두고 그 안에 전략을 넣었다 뺐다 하는 거죠. 그래서 프로그램이 돌아가는 도중에도 행동을 바꿀 수 있어요.

여기서 작은 보너스가 하나 있어요. NotificationChannel 을 다시 보면 메서드가 send 딱 하나 뿐이에요. 이렇게 추상 메서드가 하나뿐인 인터페이스는, Day 25 에서 배운 람다 로도 바로 만들 수 있어요. 굳이 클래스 파일을 새로 만들지 않고도 전략을 그 자리에서 적어줄 수 있는 거죠.

NotificationSender sender = new NotificationSender(msg -> "[Slack] " + msg);
sender.notify("hi");               // "[Slack] hi"

msg -> "[Slack] " + msg 한 줄이 곧 하나의 전략이에요. 슬랙 채널 클래스를 따로 만들지 않았는데도 발송기는 아무 불평 없이 받아줘요. 전략이 "약속(인터페이스)만 지키면 된다" 는 사실이, 람다와 만나면 이렇게 가벼워져요.

Step 3: 사건이 나면 여러 곳이 반응 — 일일이 부르는 고통

이번엔 다른 상황이에요. 누군가 내 게시물에 좋아요 를 눌렀어요. 그러면 한 가지 일만 일어나는 게 아니에요. 여러 일이 동시에 벌어져야 하죠.

• 게시물 주인에게 "OO님이 좋아합니다" 알림 을 보내야 하고,
• 게시물의 좋아요 수 를 1 올려야 하고,
• "누가 언제 좋아요를 눌렀다" 는 활동 기록 도 남겨야 해요.

가장 먼저 떠오르는 방법은, 좋아요를 처리하는 like 메서드 안에서 이 셋을 직접 다 부르는 거예요.

 좋아요가 눌리면 like() 안에서 직접…
   like(user) {
       notificationService.send(...)   ← 알림 보내기
       likeCounter.increment()         ← 좋아요 수 올리기
       activityLog.add(...)            ← 활동 기록 남기기
   }
   → 좋아요 났을 때 할 일이 늘 때마다 like() 를 또 열어 고쳐야 해요.

문제가 보이시나요? like 메서드가 좋아요 이후에 일어날 모든 일 을 다 알고 있어야 해요. 알림 서비스도 알아야 하고, 카운터도 알아야 하고, 로그도 알아야 하죠. 나중에 "좋아요를 누르면 추천 점수도 올리자" 가 추가되면? 또 like 를 열어서 한 줄 더 끼워야 해요. Step 1 의 if-else 와 똑같은 고통이 다른 옷을 입고 돌아온 거예요.

게다가 이건 방향이 좀 이상해요. 게시물은 그냥 "나 좋아요 받았어!" 하고 사건을 알리기만 하면 충분한데, 그 사건에 누가 어떻게 반응할지까지 게시물이 일일이 챙기고 있으니까요. 알리는 쪽과 반응하는 쪽이 너무 딱 붙어 있는 거죠.

여기서 발상을 뒤집어봐요. 게시물은 그냥 "좋아요 났다!" 고 방송만 하고, 거기에 관심 있는 쪽들이 알아서 듣고 반응 하게 하면 어떨까요? 그게 Observer 패턴이에요.

Step 4: 구독하고 통지받는 Observer

Observer(관찰자) 패턴은 유튜브 구독을 떠올리면 쉬워요. 채널이 새 영상을 올리면, 채널이 구독자 한 명 한 명에게 전화를 거는 게 아니에요. 그냥 영상을 올리면, 구독해둔 사람들에게 알림이 자동으로 가죠. 채널은 누가 구독했는지 정도만 알지, 그 사람들이 알림을 받고 무엇을 하는지(보든 말든)는 신경 쓰지 않아요.

여기서 등장인물은 둘이에요. 사건을 알리는 쪽(게시물)을 주체(Subject), 그 사건을 듣고 반응하는 쪽을 관찰자(Observer) 라고 불러요. 먼저 관찰자가 지켜야 할 약속부터 정해요.

// com/instagram/javabasic/design/behavioral/observer/PostObserver.java
public interface PostObserver {

    // 게시물에 좋아요가 눌리면 호출돼요.
    // postId 는 어떤 게시물인지, likedBy 는 누가 눌렀는지예요.
    void onLiked(String postId, String likedBy);
}

"좋아요 사건을 구독하고 싶으면, onLiked 를 할 줄 알아야 한다" 는 약속이에요. 무엇을 할지는 각 관찰자가 알아서 정해요. 이제 사건을 알리는 주체, 게시물을 만들어요.

// com/instagram/javabasic/design/behavioral/observer/LikeablePost.java
public class LikeablePost {

    private final String postId;
    // 이 게시물의 좋아요 사건을 구독 중인 관찰자들이에요.
    private final List<PostObserver> observers = new ArrayList<>();

    public LikeablePost(String postId) {
        this.postId = postId;
    }

    // 관찰자를 구독 목록에 등록해요.
    public void subscribe(PostObserver o) {
        observers.add(o);
    }

    // 관찰자를 구독 목록에서 빼요. 그 뒤로는 더 이상 통지받지 않아요.
    public void unsubscribe(PostObserver o) {
        observers.remove(o);
    }

    // 좋아요가 눌렸어요. 등록된 모든 관찰자에게 한 명씩 알려줘요.
    public void like(String likedBy) {
        for (PostObserver o : observers) {
            o.onLiked(postId, likedBy);
        }
    }
}

여기서 가장 중요한 건 like 메서드예요. Step 3 에서는 like 안에서 알림·카운터·로그를 직접 불렀죠. 여기선 그런 게 하나도 없어요. 그냥 구독자 목록을 돌면서 "좋아요 났어요" 라고 알려줄 뿐이에요. 구독자가 그걸 받고 무슨 일을 하는지는 LikeablePost 가 전혀 몰라요. 그래서 관찰자가 몇 개로 늘어나든 이 클래스는 그대로예요.

이제 그 사건에 반응할 관찰자들을 만들어요. 셋 다 같은 onLiked 를 받지만, 각자 하는 일은 완전히 달라요. 먼저 좋아요 수를 세는 관찰자예요.

// com/instagram/javabasic/design/behavioral/observer/LikeCountObserver.java
public class LikeCountObserver implements PostObserver {

    private int count;

    @Override
    public void onLiked(String postId, String likedBy) {
        count++;
    }

    public int getCount() {
        return count;
    }
}

다음은 알림 문구를 만드는 관찰자고요.

// com/instagram/javabasic/design/behavioral/observer/NotificationObserver.java
public class NotificationObserver implements PostObserver {

    private String lastMessage;

    @Override
    public void onLiked(String postId, String likedBy) {
        lastMessage = likedBy + "님이 회원님의 게시물을 좋아합니다";
    }

    public String getLastMessage() {
        return lastMessage;
    }
}

활동 기록을 남기는 ActivityLogObserver 도 같은 모양이에요. onLiked 안에서 기록을 한 줄 쌓죠. 이제 이들을 게시물에 구독시키고, 좋아요를 한 번 눌러봐요.

LikeablePost post = new LikeablePost("post-1");
post.subscribe(new LikeCountObserver());
post.subscribe(new NotificationObserver());
post.subscribe(new ActivityLogObserver());

post.like("minji");   // 사건 한 번 → 구독자 셋이 각자 반응

post.like("minji") 라는 한 번의 사건 으로, 구독자 셋이 동시에 깨어나 각자 할 일을 해요. 카운터는 숫자를 올리고, 알림 관찰자는 "minji님이 회원님의 게시물을 좋아합니다" 문구를 만들고, 로그 관찰자는 기록을 남기죠.

   LikeablePost ("post-1")
        │  like("minji")  ← 사건 한 번
        ▼
   구독자 전원에게 onLiked 통지
        ├─→ LikeCountObserver    → 좋아요 수 +1
        ├─→ NotificationObserver → "minji님이…" 문구 생성
        └─→ ActivityLogObserver  → 기록 한 줄 추가

만약 "추천 점수도 올리자" 가 추가되면? like 메서드는 손도 안 대요. RecommendObserver 를 하나 만들어서 subscribe 해주면 끝이에요. 반대로 어떤 반응이 더 이상 필요 없어지면 unsubscribe 로 빼면 되고요. 빼고 나면 그 관찰자는 더 이상 통지받지 않아요.

💡 Observer 의 핵심은 알리는 쪽과 반응하는 쪽을 떼어놓는 것 이에요. 게시물은 "사건이 났다" 만 방송하고, 무엇을 할지는 구독자들이 각자 정해요. 그래서 한쪽을 고쳐도 다른 쪽이 흔들리지 않죠. "방송하는 사람은 듣는 사람이 뭘 하는지 모른다" — 이게 느슨한 연결의 핵심이에요.

Step 5: 두 패턴 한자리 비교, 그리고 다음 패턴으로 잇기

오늘 만난 두 패턴은 둘 다 "행동을 유연하게" 다뤘지만, 푸는 불편이 서로 달라요. 한자리에 모아봐요.

재미있는 건, 둘이 닮은 구석도 있다는 거예요. 둘 다 "무엇을 할지" 를 인터페이스로 떼어냈어요. Strategy 는 NotificationChannel 로, Observer 는 PostObserver 로요. 그래서 둘 다 새 동작이나 새 구독자를 추가해도 기존 코드를 건드리지 않아요. Day 14 에서 배운 OCP 가 두 패턴 모두의 바탕에 깔려 있는 거죠.

인터페이스로 약속만 정해두면, 그 뒤는 얼마든지 유연해진다는 걸 오늘 두 번 확인한 셈이에요.

차이는 방향과 개수 예요. Strategy 는 여러 전략 중 하나 를 골라 쓰다가 갈아끼우는 거고(교체), Observer 는 한 사건에 여럿 이 동시에 반응하는 거예요(통지). "골라 끼우면 Strategy, 모여서 반응하면 Observer" 로 기억해두면 헷갈리지 않아요.

⚠️ 여기서도 Day 40 의 교훈은 그대로예요. 패턴은 불편이 실제로 있을 때 꺼내는 연장이에요. 동작이 한 가지뿐이라면 굳이 Strategy 로 뽑을 필요가 없고, 사건에 반응하는 곳이 하나뿐이라면 그냥 직접 부르는 게 더 읽기 쉬워요. "분기가 자꾸 늘어나나?", "한 사건에 반응할 곳이 여럿인가?" — 그 불편이 보일 때, 그때가 패턴을 꺼낼 때예요.

마무리

오늘은 객체의 행동을 유연하게 다루는 두 가지 패턴을 배웠어요.

• Strategy — 바뀌는 행동을 객체로 뽑아, 통째로 갈아끼우는 패턴. Day 14 의 NotificationChannel 을 전략으로 재활용했고, 단일 메서드 인터페이스라 람다로도 가볍게 만들 수 있었죠.
• Observer — 한 사건을 여러 구독자가 각자 듣고 반응하는 패턴. 알리는 쪽(LikeablePost)과 반응하는 쪽(관찰자들)을 떼어놓아, 반응이 늘어도 사건을 알리는 코드는 그대로였어요.

그리고 두 패턴 모두 인터페이스로 "무엇을 할지" 를 분리해, 확장에는 열리고 수정에는 닫힌 구조를 만든다는 것도요.

다음 시간(Day 42)엔 행동 패턴 가족을 마저 만나봐요. 이미 만들어진 기능에 새 기능을 덧입히는 Decorator, 큰 흐름의 골격은 고정해두고 일부 단계만 갈아끼우는 Template Method — 이건 사실 Day 12 에서 Content 의 render() 로 한 번 맛본 패턴이에요 — 그리고 우리가 매일 쓰는 for-each 의 비밀을 푸는 Iterator 와 Iterable 까지요.

오늘 "행동을 분리한다" 는 감각을 잡았다면, 다음 패턴들도 한결 수월할 거예요. 수고 많으셨어요!

과제

오늘 배운 두 패턴을 직접 손으로 만들어볼 시간이에요. 셋 다 인스타그램에서 실제로 일어날 법한 상황이에요. 막히면 본문 코드를 참고하되, 먼저 "이 불편을 어떤 패턴이 풀어주지?" 를 떠올려보세요.

과제 1 (기초): 피드 정렬 전략을 Strategy 로 갈아끼우기

상황 배경: 인스타그램 피드를 보여줄 때, 정렬 방식이 여러 가지예요. 최신순으로 볼 수도 있고, 좋아요가 많은 인기순으로 볼 수도 있죠. 사용자가 정렬 버튼을 누르면 그때그때 방식을 바꿔야 해요. Step 2 의 NotificationSender 를 참고하세요.

🎯 해결 미션:

1. FeedSortStrategy 라는 인터페이스를 만들고, 게시물 목록을 받아 정렬된 목록을 돌려주는 메서드 하나(예: List<Post> sort(List<Post> posts))를 약속으로 두세요.
2. 이 약속을 지키는 전략 둘을 만드세요. LatestSortStrategy(최신순)와 PopularSortStrategy(좋아요 많은 순)요.
3. FeedSorter 라는 클래스를 만들어, 전략을 품고 있다가 sort(...) 가 불리면 품은 전략에게 맡기게 하세요. 그리고 전략을 갈아끼우는 메서드도 두세요.
4. 최신순으로 한 번 정렬해보고, 전략을 인기순으로 갈아끼운 뒤 다시 정렬해, 결과 순서가 달라지는지 확인하세요.

과제 2 (응용): 팔로우 사건을 Observer 로 퍼뜨리기

상황 배경: 누군가 나를 팔로우하면, 좋아요 때처럼 여러 일이 한꺼번에 일어나야 해요. 나에게 "OO님이 팔로우하기 시작했습니다" 알림이 가야 하고, 내 팔로워 수가 1 올라가야 하죠. Step 4 의 LikeablePost 와 관찰자들을 참고하세요.

🎯 해결 미션:

1. 팔로우 사건을 구독하는 관찰자 약속 FollowObserver 인터페이스를 만들고, onFollowed(String followedBy) 메서드를 두세요.
2. 사건을 알리는 주체 FollowablePost 대신 FollowableUser 클래스를 만들어, subscribe·unsubscribe·follow(String followedBy) 를 두세요. follow 는 구독자 전원에게 통지해야 해요.
3. 관찰자 둘을 만드세요. 팔로워 수를 세는 FollowerCountObserver 와, 알림 문구를 만드는 FollowNotificationObserver 요.
4. 한 명을 팔로우시켜보고, 두 관찰자가 각각 제대로 반응했는지(수가 올랐는지, 문구가 생겼는지) 확인하세요. 그다음 관찰자 하나를 unsubscribe 하고 다시 팔로우시켜, 뺀 관찰자는 더 이상 반응하지 않는지도 확인해보세요.

과제 3 (심화): 람다 전략으로 새 채널 추가 + if-else 와 비교

상황 배경: 본문에서 NotificationSender 에 슬랙 채널을 람다로 추가해봤죠. 이번엔 직접 새 채널 두 개를 추가해보고, 만약 Step 1 의 if-else 방식이었다면 같은 일을 하는 데 코드를 몇 군데 고쳐야 했을지 비교해볼 거예요. Step 2 의 람다 전략 부분을 참고하세요.

🎯 해결 미션:

1. 본문의 NotificationSender 를 그대로 써서, 카카오톡 채널("[KaKao] " + msg)과 디스코드 채널("[Discord] " + msg)을 람다로 각각 만들어 끼워보세요. NotificationSender 클래스는 한 줄도 고치지 않아야 해요.
2. 두 채널로 각각 같은 메시지를 보내, 앞에 붙는 이름표가 다르게 나오는지 확인하세요.
3. 이제 상상해보세요. 만약 Step 1 의 if-else 방식으로 같은 두 채널을 추가한다면, 어떤 메서드를 몇 번 열어 고쳐야 할까요? Strategy 방식에서는 기존 코드를 몇 줄 고쳤나요? 둘을 비교해 "왜 Strategy 가 확장에 강한지" 를 한두 줄로 적어보세요.

생각해볼 주제

혼자 고민해도 좋고, 동료와 토론해도 좋아요. 정답을 외우기보다 "나라면 어떻게 설명할까" 를 떠올리며 읽어보세요.

1. Strategy 는 "조합", 상속은 "고정" 이라는데, 왜 조합이 더 유연할까?

오늘 Strategy 를 보면, 발송기는 하나뿐인데 그 안의 전략을 도중에 갈아끼웠어요. 만약 상속으로 EmailSender·PushSender 를 따로 만들었다면 이렇게 도중에 바꾸진 못했을 거예요.

"한 객체가 살아 있는 동안 행동을 바꿀 수 있는가" 를 떠올려보세요. 상속으로 행동을 정하면 그 객체는 태어날 때 이미 행동이 굳어버려요. 반면 조합(전략을 품기)은 품은 것을 바꾸면 행동도 바뀌죠.

또 행동의 조합이 많아질 때도 생각해보세요. 채널이 3가지, 말투가 2가지라면 상속으로는 6가지 클래스가 필요하지만, 조합이라면 3 + 2 만 만들어 섞으면 돼요. "상속보다 조합을 우선하라" 는 오래된 설계 조언이 왜 나왔는지, 오늘 코드와 연결해 정리해보세요.

2. Observer 에서 구독자가 아주 많아지면, 어떤 점을 조심해야 할까?

오늘은 구독자가 셋뿐이라 편하게 통지했어요. 그런데 인기 게시물이라 구독자가 수천 개라면? 혹은 한 구독자가 통지를 받고 아주 느린 작업을 한다면 어떻게 될까요?

"통지가 한 명씩 차례로 돌아간다" 는 점을 떠올려보세요. like 안의 반복문은 구독자를 하나씩 부르고 그게 끝나야 다음으로 넘어가요. 그러면 느린 구독자 하나가 전체를 붙잡을 수 있죠.

또 하나, 구독만 하고 unsubscribe 를 깜빡하면 어떻게 될까요? 주체가 그 관찰자를 계속 목록에 쥐고 있어서, 더 이상 필요 없는 객체가 메모리에 남는 일도 생겨요. "편리하게 여럿에게 알린다" 는 장점의 뒷면에 어떤 비용이 숨어 있는지 같이 저울에 올려보세요.

3. Strategy 도 Observer 도 결국 "인터페이스로 분리" 였는데, 왜 인터페이스가 이렇게 자주 나올까?

오늘 두 패턴 모두 인터페이스(NotificationChannel, PostObserver)로 "무엇을 할지" 를 떼어냈어요. 사실 Day 13 부터 인터페이스는 계속 등장했죠. 왜 좋은 설계 이야기에는 늘 인터페이스가 따라올까요?

"두 코드가 서로 얼마나 알아야 하는가" 를 떠올려보세요. NotificationSender 는 EmailChannel 이라는 구체적인 이름을 몰라요. 그저 NotificationChannel 이라는 약속만 알죠. LikeablePost 도 LikeCountObserver 를 몰라요. PostObserver 만 알아요.

이렇게 구체적인 상대 대신 약속 만 알고 지내면, 상대가 바뀌거나 새로 생겨도 내가 흔들리지 않아요. 인터페이스가 좋은 설계의 단골인 이유를, "서로 덜 알수록 덜 흔들린다" 는 말과 연결해 정리해보세요.