브릿지 패턴 (Bridge Pattern)

사용 의도

• 추상화와 구현을 분리하여 유연함을 증가시키고 재사용성을 증가시킵니다.

---

예시

메시지를 보내는 어플리케이션을 개발한다고 가정해봅니다.

• TextMessage 와 EmailMessage 를 보내는 어플리케이션을 개발하는 과정에서 아래와 같은 설계를 하였습니다.

---

구조

Message	메시지에 대한 추상화 클래스
TextMessage / EmailMessage	상세한 메시지 (Text / Email) 에 대한 추상클래스
TextMessageSender / EmailMessageSender	TextMessage 와 EmailMessage 를 보내는 클래스

---

단점

• 추상화인 Message (Client 에 제공) 와 TextMessageSender (구현체) 가 너무 밀접하게 통합되어있습니다.
  • 추상화에 선택적으로 메시지를 암호화하는 로직을 추가한다면, 하위 구현체들도 이에 민감하게 반응하게 됩니다.
• 재사용성이 좋지 않습니다.
  • 구현체에 구현한 것을 재사용하고 싶은 경우에는 재사용이 힘듭니다.

---

개선

• 위의 구조를 Compsition 을 사용한 Bridge Pattern 으로 변경하면 재사용성과 밀접한 의존관계를 피할 수 있습니다.

@Getter
public abstract class Message {
    private final MessageSender messageSender; // composition

    public Message(MessageSender messageSender) {
        this.messageSender = messageSender;
    }

    private String content;

    public void setContent(String content) {
        this.content = content;
    }

    public void send() {
        messageSender.sendMessage();
    }
}

public interface MessageSender {
    void sendMessage();
}

Message 는 MessageSender 를 생성자로 초기화(DI) 하는 구조를 통해서 (Composition)

• 재사용성 : MessageSender 를 재사용 할 수 있음
• 유연함 : 선택적으로 Content 를 암호화하는 로직을 Message 추상클래스에 추가해도 MessageSender 에는 영향이 없음

---

사용처

• 계속 깊어지는 상속구조를 갖고있다면, 책임을 명확하게 분리하여 Has-A 관계 (Composition? DI?) 를 갖는 Bridge Pattern 을 적용하면 좋을 것입니다.

---

참고

• https://springframework.guru/gang-of-four-design-patterns/bridge-pattern/
• https://ko.wikipedia.org/wiki/%EB%B8%8C%EB%A6%AC%EC%A7%80_%ED%8C%A8%ED%84%B4