[펌] The Bridge Pattern

The Bridge Pattern

    브리지 패턴은 클래스의 구현으로부터 인터페이스를 분리하는데 사용되어진다. 브리지 패턴은 추상화 정도에 의한 계층으로 구분되어 있고 또 이를 구현하는데 있어 몇 개의 계층으로 나누는 경우에 유용한 패턴이다. 추상화 정도와 구현에 따라 완전히 구별되는 여러 클래스로 나누기 보다는 이를 동적으로 조합되는 몇 개의 상이한 클래스로 관리한다. 

    어떤 생산물의 목록을 하나의 화면에 나타내고자 한다 가정해 보자. 나타내기 위한 가장 간단한 방법은 "JList" 클래스를 사용하는 것이다. 그러나, 생산물의 일부분은 팔리게 되었다면, 우리는 판매와 관련하여 하나의 표안에 생산물을 나타내고자 할 지도 모른다. 

    우리는 앞에서 어댑터 패턴에 대하여 공부했는데, 어댑터에 기반의 클래스를 생각하게 될 지도 모른다. 간단한 예제프로그램은 잘 작동을 하겠지만, 접근에 몇몇 제한사항이 있다는 것을 알게 될 것이다.

    우리의 생산물의 데이터로부터 두 가지의 디스플레이가 필요하다고 해보자. 우리가 언급했던 생산물의 목록은 단지 customer view에서 나타나고, executive view에서는 선적된 양을 보여 줄 것이다.  생산품 리스트는 보통 JList 를 이용하여 나타내고, executive view는 JTable로 나타낼 것이다. 

            ##########0*

    상위의 프로그래밍 단계에서는 단지 JList 와 JTable에서 파생된 테이블과 리스트의 인스턴스만을 생성하였다.

      pleft.add("North", new JLabel("Customer view"));
      pleft.add("Center", new productList(prod));
      
      //add in execute view as table
      pright.add("North", new JLabel("Executive view"));
      pright.add("Center", new productTable(prod));

또, 작성된 JawList 클래스로부터 직접 productList 클래스를 파생시켰다.

public class productList extends JawtList {

  public productList(Vector products) {   
      super(products.size());    //for compatibility
      for (int i = 0; i < products.size(); i++) {

         //take each strig apart and keep only
         //the product names, discarding the quntities
         String s = (String)products.elementAt(i);
         int index = s.indexOf("--");  //separate qty from name
         if(index > 0)
            add(s.substring(0, index));
         else
            add(s);
      }
  }
}

Building a Bridge

이제 데이터를 나타내는 리스트 방법에서 몇 가지 변경사항이 필요하다 가정해보자. 예를 들어, 생산물의 목록을 알파벳 순으로 정렬하고자 할 수도 있다. 이렇게 하기 위해서는 상속된 클래스들의 수정을 필요하게 된다. 우리가 나타내야 할 것이 두개 이상이 된다면 더더욱 끔찍한 작업이 될 것이다. 변경된 내용을 나타내기 위해 새로운 클래스를 파생시키는 것보다는 brige를 만들어 작업하는 것이 더 나을 것이다. 

##########1*

우리가 가시적인 컴포넌트를 반환하고자 한다면, 스크롤이 있는 패널의 일종으로 만들 수 있다.

public class listBridge extends JScrollPane

브리지 클래스를 설계할 때, 여러 클래스의 인스턴스를 브리지가 어떻게 결정할 것인지를 결정해야 한다. 나타날 데이터의 값이 성질에 기인하여 결정할 수도 있거나, 간단한 상수에 의해서 결정될 수도 있다. 여기서는 브리지 클래스 내에 두개의 상수를 정의하는 방식을 사용하였다. 

static public final int TABLE = 1, LIST = 2;

우리는 메인 클래스의 대부분은 유지하였으며, 새로운 listBridge의 생성자만을 약간 수정하였다.

pleft.add("North", new JLabel("Customer view"));
pleft.add("Center", new listBridge(prod, listBridge.LIST));

//add in execute view as table
pright.add("North", new JLabel("Execute view"));
pright.add("Center", new listBridge(prod, listBridge.TABLE));

listBridge 클래스를 위한 생성자는,

public listBridge(Vector v, int table_type) {
	Vector sort = sortVector(v);	//sort the Vector
	
	if(table_type == LIST)
		getViewport().add(makeList(sort));	//make list
	
	if(table_type == TABLE)
		getViewport().add(makeTable(sort));	//make table
}

브리지 클래스에서 중요한 차이점은 JTable 과 JList클래스를 수정없이 직접 사용할 수 있다는 것이고 그렇게 때문에 리스트나 테이블을 위한 데이터를 생성하는 데이터 모델에서 어떤 인터페이스 컴퓨팅을 시도할 수 있다는 것이다.

private JList makeList(Vector v) {
	return new JList(new BridgeListData(v));
}

private JTable makeTable(Vector v) {
	return new JTable(new prodModel(v));
}

정렬된 결과는 다음 그림과 같다.

##########2*

Consequences of the Bridge Pattern

1. 브리지 패턴은 나타내거나 사용하는 클래스의 실제적인 종류의 변경을 허용하는 반면에 클라이언트 프로그램 상수에 인터페이스를 유지하는 것을 의도한다. 이것은 복잡한 사용자 인터페이스의 모듈들을 다시 컴파일하는 것을 방지하고 브리지와 실제로 보여지는 말단의 클래스만 재컴파일하는 것을 요구한다.
2. 구현되는 클래스와 브리지 클래스를 분할하여 확장할 수 있고, 상호간의 많은 상호작용을 제거해 준다.
3. 훨씬 쉽게 크라이언트 프로그램에서 상세한 구현을 숨길 수 있다.