[Design pattern] Bridge

Bridge pattern : '다리 건너편의 일은 신경쓰지않는다. 단지 건너갈 뿐이다.' Bridge pattern은 이처럼 다리건너편의 기능에 대한 구현을 감춰준다. 단지 다리를 통해 그 기능에 접근해 사용하기만 할 뿐이다.

OOP에서 interface의 목적도 작은 Bridge pattern의 실체라 볼 수 있다. interface를 구현하는 클래스는 사용하는측에게 구현내용을 공개할 의무가 없다. 사용하는 측도 단지 interface를 통해 그 기능에 접근할 뿐이다.

 

 

이처럼 하나의 구현에 대해 interface로 감추고 클라이언트에 자신의 interface만 노출시켜 interface를 다리로 이용하도록 할 수도 있으며 이를 확장하여 Factory pattern을 사용하여 Strategy pattern을 구현한 Bridge로도 응용할 수 있다.

/* SodaDispenser.java */

public class SodaDispenser {

private SodaFactory sodaFactory;

public void setSodaFactory(SodaFactory sodaFactory){

this.sodaFactory = sodaFactory;

}

public Soda dispenseSoda(){

Soda soda = sodaFactory.createSoda();

soda.bubbling();

return soda;

}

}

/* Soda.java */

public interface Soda {

public void bubbling();

}

/* SodaFactory.java */

public abstract class SodaFactory {

public abstract Soda createSoda();

}

/* CokeFactory.java */

public class CokeFactory extends SodaFactory {

public class Coke implements Soda{

@Override

public void bubbling() {

System.out.println("Bubbling likes volcano!");

}

}

@Override

public Soda createSoda() {

Coke coke = new Coke();

return coke;

}

}

SodaDispenser는 탄산음료를 담았다가 편하게 뽑아먹을 수 있는 기계이다. SodaDispenser에서는 어떤 탄산수든 뽑아먹기만 하면 되며, 나오는 소다의 맛은 Soda를 구현하는측의 일이다. 여기에 SodaFactory를 더하여 탄산수의 생성에 Factory pattern을 적용하였다. 위의 예에서는 Soda가 SodaDispenser와 Coke의 Bridge가 되어준것이다.

디자인패턴을 공부하면서 매번 느끼지만, 패턴간에 명확한 구분은 없는것같다. 애초에 여러가지 패턴의 조화로운 조합을 단지 설명을 위해 이리 쪼개고 저리쪼개 ~패턴  이란 이름을 붙여놓은 듯한 형태이다. 이렇게 쪼개진 패턴을 익히고 다시 조화롭게 합쳐 하나의 시스템을 구성하는것도 어려운일인것같다.