Facade Pattern

정의

어떤 sub-system의 interface에 대한 통합된 interface를 제공하고 facade에서 고수준 interface를 정의하기 때문에 sub-system을 쉽게 사용할 수 있다.

장점

더욱 더 간단한 interface를 만들 수 있다는 것이다. 

또한 client부와 sub-system을 분리할 수도 있다. 

만약 client를 facade로 만들었다고 하면 interface가 달라졌을 때 client는 변경할 필요 없이 facade만 변경하면 된다. 

그리고 표면에 드러나 있는 interface를 사용하고 그 내부는 알 필요가 없다.

l  최소지식원칙(=Law of Demeter)

system design에 있어서 어떤 object든 그 object와 상호작용하는 class의 수에 주의해야 하며, object들과 어떤 식으로 상호작용하는지도 주의해야 한다는 원칙이다.

위 원칙을 지키기 위해서는 4 종류의 object의 method만 호출하면 되는데, 다음과 같다.

1.    객체 자체

2.    Method에 parameter로 전달된 object

3.    그 method에서 생성하거나 instance를 만든 object

4.    그 object에 속하는 구성요소 (A has B)

Adapter Pattern, Facade Pattern, Decorator Pattern의 차이점

l  Adapter Pattern : 한 interface를 다른 interface로 변환하는 것이다. Interface를 변경해서 client에서 필요로 하는 interface로 적응시키는 위한 용도로 호환성을 위한다.

l  Facade Pattern : interface를 간단하게 바꾸는 것으로, 어떤 sub-system에 대한 간단한 interface를 제공하기 위한 용도로 사용되며 간편할 때 사용한다.

l  Decorator Pattern : interface를 바꾸지 않고 기능만 추가하는 것으로 Object를 감싸서 새로운 기능을 추가하기 위해서 사용한다.

정리

1.    기존 class를 사용하려고 하는데 interface가 맞지 않으면 adapter pattern을 사용한다.

2.    큰 interface 또는 여러 interface를 단순화 시키거나 통합시켜야 한다면 facade pattern을 사용한다.

3.    Adapter Pattern은 interface를 client가 원하는 interface로 바꾸는 역할을 하고 Facade Pattern은 복잡한 sub-system과 분리하는 역할을 한다.

4.    Adapter Pattern은 다중 Adapter로 만들 수 있고 Façade Pattern은 한 sub-system에 여러 개 만들 수 있다.

Adapters Pattern

정의 : 한 class의 interface를 client에서 필요로 하는 다른 interface로 변환한다. Adapter를 이용하면 interface 호환성문제로 쓸 수 없는 class들을 연결해서 쓸 수 있다.

위 그림과 같이 Adapter의 소스만 변경하여 Existing System과 Vender Class를 연결해 준다.

1.    Class Adapter Pattern

A.    장점 : Adapter 전체를 다시 구현할 필요가 없다.

B.     단점 : 상속을 활용하기 때문에 유연성이 떨어진다.
(java는 다중상속 -지원 X)

C.    Class Adapter에서는 다중 상속을 이용하기 때문에 JAVA에서는 사용할 수 없다 (간접적 다중상속 지원 à Interface를 이용)

2.    Object Adapter Pattern

A.    장점 : Composition을 사용하기 때문에 유연성이 뛰어나다.

B.     단점 : Adapter Class의 대부분의 코드를 구현해야 하기 때문에 효율성이 떨어진다.

사용방법

1.    Client에서 Target Interface를 사용하여 method를 호출함으로써 adapter에 요청을 한다.

2.    Adapter에서는 adapter interface를 사용하여 그 요청을 adapter에 대한 하나 이상의 메소드를 호출로 변환한다.

3.    Client에서는 호출 결과를 받긴 하지만 중간에 Adapter의 역할이 있었는지 전혀 알 수 없다.

기존의 Duck interface

Duck interface를 implement하는 MallardDuck

public class MallardDuck implements Duck{

    @Override

    public void fly() {

     // TODO Auto-generated method stub

     System.out.println("Quack");

    }

    @Override

    public void quack() {

     // TODO Auto-generated method stub

     System.out.println("I'm flying");

    }

}

하지만 turkey가 오고싶다. 그래서 interface를 만들어준다.

public interface Turkey {

    public void gobble();

    public void fly();

}

그 후, Duck interface를 사용하기 위해 Adapter를 사용한다.

public class TurkeyAdapter implements Duck{

    Turkey turkey;

     public TurkeyAdapter(Turkey turkey){

     this.turkey=turkey;

    }

     @Override

    public void quack() {

     turkey.gobble();

    }         

    @Override

    public void fly() {

     turkey.fly();

    }

}

Turkey interface를 implements 하는 WildTurkey

public class WildTurkey implements Turkey{

    @Override

    public void fly() {

     // TODO Auto-generated method stub

     System.out.println("Gobble gobble");

    }

    @Override

    public void gobble() {

     // TODO Auto-generated method stub

     System.out.println("I'm flying a short distance");

    }

}

Main 소스

public class DuckTestDrive {

    public static void main(String[] args) {

     MallardDuck duck = new MallardDuck();

     WildTurkey turkey = new WildTurkey();

     Duck turkeyAdapter = new TurkeyAdapter(turkey);

     System.out.println("The turkey says...");

     turkey.gobble();

     turkey.fly();

     System.out.println("The Duck says...");

     testDuck(duck);

     System.out.println("The TurkeyAdapter says...");

     testDuck(turkeyAdapter);

    }

    public static void testDuck(Duck duck){

     duck.quack();

     duck.fly();

    }

}

결과 화면

The turkey says...

I'm flying a short distance

Gobble gobble

The Duck says...

I'm flying

Quack

The TurkeyAdapter says...

I'm flying a short distance

Gobble gobble

UML