[디자인 패턴] 브릿지 패턴 (Bridge Pattern)

브릿지 패턴

• 객체 지향 설계에서 구조적 디자인 패턴 중 하나로, 구현부에서 추상층을 분리하여 둘을 독립적으로 변형할 수 있도록 지원
  • 하나의 계층 구조일 때 보다 각기 나누었을 때 독립적인 계층 구조로 발전시킬 수 있음 
  • 시스템이 변화하는 요구사항에 유연하게 대처할 수 있도록 해줌

 

• 브릿지 패턴의 주된 목적은 추상화와 구현을 분리하여 두 부분이 독립적으로 변화할 수 있도록 하는 것
  • 이는 코드의 유지보수성과 확장성을 높이는 데 큰 도움을 줌

 

https://www.geeksforgeeks.org/bridge-design-pattern/

 

주요 구성 요소

 

1. Abstraction

• 구현의 인터페이스를 정의하는 역할
• 일반적으로 구현 객체에 대한 참조(레퍼런스)를 포함 (컴포지션)
• 구현체에 위임하는 고수준의 작업들을 정의

 

2. RefinedAbstraction

• Abstraction의 확장판으로, 세부적인 기능을 추가하거나 변경

 

3. Implementor

• Abstraction이 정의한 인터페이스를 실제로 구현하는 역할
• 구현부의 공통 인터페이스를 정의

 

4. ConcreteImplementor

• Implementor의 구체적인 구현체로, 실제 작업을 수행

 

브릿지 패턴 구현 예시

 

1. Abstraction

 

 

2. RefinedAbstraction

 

 

3. Implementor

 

 

4. ConcreteImplementor

 

 

 

부연 설명

• Vehicle 클래스는 Workshop 객체를 사용하여 작업을 수행하지만, 구체적인 작업 내용은 Workshop의 구체적인 구현 클래스 (Produce와 Assemble)에 위임
  • Vehicle 클래스와 Workshop 인터페이스를 분리함으로써 각각을 독립적으로 확장
  • 새로운 Vehicle 타입을 추가하거나 새로운 Workshop 구현을 추가하는 것이 용이

 

• Car와 Bike 클래스는 Vehicle 클래스를 확장하여 각각의 manufacture 메서드를 구현
• Produce와 Assemble 클래스는 Workshop 인터페이스를 구현하여 각각의 work 메서드에서 작업을 수행

 

브릿지 패턴 장단점

 

장점

• 추상적인 코드를 구체적인 코드 변경 없이도 독립적으로 확장할 수 있음 (SOLID의 OCP 원칙)
• 추상적인 코드와 구체적인 코드를 분리할 수 있음 (SOLID의 SRP 원칙)

 

단점

• 다른 디자인 패턴들과 마찬가지로 클래스가 늘어남에 따라 관리 포인트가 늘어나 복잡도가 증가할 수 있음

 

실무에서 쓰이는 브릿지 패턴

 

1. JDBC API, DriverManager, Driver

• JDBC API는 데이터베이스와의 연결을 추상화
• DriverManager와 Driver를 사용하여 구체적인 데이터베이스 드라이버 구현과 추상화를 분리하는 역할

 

부연 설명

• Abstraction: JDBC API는 DB와 상호작용하는데 필요한 추상화 계층을 제공
• Refined Abstraction: DriverManager 클래스는 JDBC API와 구체적인 드라이버 구현 사이의 브릿지 역할을 수행
• Implementor: Driver 인터페이스는 구체적인 DB 드라이버가 구현해야 하는 메서드를 제공
• Concrete Implementor: MySQL Driver, H2 Driver와 같은 각 DB 드라이버

 

2. Slf4j, Logger

• Slf4j는 로깅 시스템과 로깅 API를 분리하여 서로 독립적으로 변경할 수 있도록 하는 역할
  • 이를 통해 다양한 로깅 구현체를 사용할 수 있게 하면서도, 일관된 로깅 API를 제공

 

부연 설명

• Abstraction: Slf4j API는 로깅 기능을 추상화하여 제공하는 인터페이스인 Logger를 정의
• Refined Abstraction: 클라이언트 코드는 Slf4j API를 통해 로깅을 수행하며 로깅을 위해 LoggerFactory를 사용하여 Logger 객체를 생성하고 이를 통해 로그 메시지를 기록
• Implementor: SLF4J 바인딩은 Logger 인터페이스를 구현하는 로깅 프레임워크의 실제 인스턴스를 제공하며 바인딩 클래스는 특정 로깅 프레임워크와의 연동을 담당
• Concrete Implementor: Logback, Log4j, java.util.logging 등 다양한 로깅 프레임워크가 Logger 인터페이스를 구현하여 실제 로깅을 수행

 

3. Spring Framework의 PSA(Portable Service Abstraction)

• PSA는 다양한 서비스(예: 트랜잭션 관리, 메시징, 스케줄링 등)를 추상화하여 애플리케이션 코드가 특정 구현체에 종속되지 않도록 지원
  • 이는 브릿지 패턴을 사용하여 구현과 추상화를 분리하는 원칙과 매우 유사

 

3.1 Spring Framework의 트랜잭션 관리

• Abstraction: TransactionTemplate은 트랜잭션 관리를 위한 고수준의 추상화 API 제공
• Implementor: PlatformTransactionManager는 트랜잭션 관리의 저수준 인터페이스를 정의
• Concrete Implementor: DataSourceTransactionManager, JpaTransactionManager와 같이 구체적인 트랜잭션 관리자 구현체는 인터페이스를 구현하여 특정 기술에 맞는 트랜잭션 관리 기능을 제공
• 정리하면 Spring의 트랜잭션 관리 구조에서 TransactionTemplate은 브리지 패턴의 Abstraction 역할, PlatformTransactionManager는 Implementor 역할, 그리고 구체적인 트랜잭션 관리자 구현체들(DataSourceTransactionManager, JpaTransactionManager 등)은 Concrete Implementor 역할을 수행
  • 이러한 구조를 통해 트랜잭션 관리의 복잡성을 추상화하고, 다양한 트랜잭션 관리 구현체를 유연하게 사용

 

3.2 Spring Framework의 MailSender

• Abstraction: MailSender는 메일 발송을 추상화하는 인터페이스
• Refined Abstraction: JavaMailSender는 MailSender 인터페이스를 확장하여 JavaMail API를 사용하는 더 구체적인 메서드 제공
• Implementor: JavaMailSenderImpl 클래스는 JavaMailSender 인터페이스를 구현하여 실제 메일 발송 기능을 제공
• 정리하면 Spring의 MailSender 구조에서 MailSender 인터페이스는 브리지 패턴의 Abstraction 역할, 이를 확장한 JavaMailSender는 Refined Abstraction 역할, 그리고 JavaMailSenderImpl 클래스는 Implementor 역할
  • 이러한 구조를 통해 Spring의 메일 발송 기능은 다양한 메일 발송 구현체를 유연하게 사용할 수 있으며, 변경이 용이한 구조를 갖춤

 

참고

코딩으로 학습하는 GoF의 디자인 패턴 - 백기선 강사님