브리지 패턴

브리지 패턴? 

객체의 확장성을 향상하기 위한 패턴으로,

확장을 객체간의 상속이 아닌 구현으로 처리하며,

객체에서 동작을 처리하는 구현부와 확장을 위한 추상부를 분리한다.

이 두개의 개별 계층 구조를 각각 독립적으로 개발한다.

 

이러한 브리지 패턴을 구현하기 위해서는 4개의 구성 요소 가 필요하다.

• Abstract
  • 상위 추상부 
  • 상위 수준의 제어 논리 제공, 구현부에 의존하여 실제 하위 수준 작업 수행
• RefinedAbstract
  • 자식 추상부 (선택 사항) 
  • 제어 논리의 변형을 제공 
• Implementor
  • 상위 구현부( Abstrct 에 포함 )
  • 공통적인 인터페이스 선언 추상부는 여기에 선언된 메서드를 통해서만 구현부와 소통할 수 있다.
• ConcreateImplementor
  • 자식 구현부
  • 플랫폼별 맞춤형 코드 작성된다.

 

왜 상속이 아닌 구현으로?

클래스를 상속하게 되면, 구현과 추상의 개념이 영구적으로 결합되어 

향후 클래스를 수정하거나 확장하기 어려워지게 되며,

불필요한 구현 코드 또한 상속되므로 최종 클래스가 무거워 지게 된다.

 

브리지 패턴의 장점

• 개방/패쇄 원칙
• 단일 책임 원칙
• 플랫폼 독립적인 클래스들을 만들 수 있다.
• 객체의 확장성  이 향상된다.

 

브리지 패턴의 단점 

• 코드가 복잡해진다.

 

브리지 패턴의 구현

// Abstract
public interface Alert {
    void alert();
}

// RefinedAbstract
public class KoreaAlert implements Alert{
    @Override
    public void alert() {
        System.out.println("안녕하세요");
    }
}

// RefinedAbstract
public class EnglishAlert implements Alert{
    @Override
    public void alert() {
        System.out.println("hello");
    }
}

// Implementor
public abstract class Language {

    protected Alert alert;

    public abstract void alert();
}

// ConcreteImplementor
public class AlertByLanguage extends Language{

    AlertByLanguage(Alert alert){
        this.alert = alert;
    }

    @Override
    public void alert() {
        this.alert.alert();
    }
}

 

 

언제 사용해야 할까?

• 객체의 확장성을 향상시키고 싶을 때 
• 객체의 확장 가능성이 높은 경우
• 런타임간에 구현 전환이 필요한 경우 => 추상부의 구현부를 갈아 치우면 된다.

 

 

 

 

---

참조

https://refactoring.guru/ko/design-patterns/bridge