본문 바로가기
Theory/Design Pattern

Bridge Pattern

by y.j 2022. 4. 24.
728x90

Bridge Pattern

abstraction과 implementation을 분리하여 이 2가지를 독립적으로 다양하게 할 수 있다.

abtraction과 implementation을 어떻게 독립적으로 다양하게 할 것인가?
어떻게 implementation을 run-time에 선택하거나 교환할 수 있을까?

서버를 사용할 때, 여러개의 다른 하드웨어를 가진 환경이 존재 할 수 있다. application을 서로 다른 하드웨어 환경에 적절히 동작하기 위해서 필요 할 수 있다.

Solution

Abstraction을 통해 Implementor의 구현부를 사용 한다. 따라서, run-time에 implementor를 상속받은 클래스만 바꿔주면 되기 때문에 Abstraction과 implementation이 독립적으로 움직 일 수 있다.

package BridgePattern;

public class Abstraction1 implements Abstraction {

    private Implementor imp;

    public Abstraction1(Implementor imp) {            // run-time에 Implementor를 교환할 수 있다.
        this.imp = imp;
    }

    @Override
    public String operation() {
        return "Abstraction1: Delegating implementation to an implementor.\n"
                + imp.operationImp();
    }
}

Advantages

• Subclassing의 대안책으로 유동성을 제공한다.

  상속을 받아 abstraction을 구현한다면, implementation을 compile-time에 abstraction에 범위에 있을 수 밖에 없어 run-time에 교환 할 수 없다. Bridge는 contructor에서 Implementor만 교환하면 되기 때문에 abstraction과 implementor를 유동적으로 움직 일 수 있다.

Disadvantages

• 우회 할 수 있는 추가적인 class나 interface가 필요하다.

 

[전체 소스]

https://github.com/jKyounju/adapterPatterns/tree/master/src/BridgePattern

728x90

'Theory > Design Pattern' 카테고리의 다른 글

Composite Pattern  (0) 2022.05.05
Proxy Pattern  (0) 2022.04.24
Prototype Pattern  (0) 2022.04.23
Factory Method Pattern  (0) 2022.04.10
Builder Pattern  (0) 2022.03.29

댓글