17. 도어 모드(Facade Pattern)

1. 정의
하위 시스템의 외부와 그 내부의 통신은 반드시 통일된 대상을 통해 이루어져야 한다.외관 모델은 높은 차원의 인터페이스를 제공하여 서브시스템을 더욱 쉽게 사용할 수 있게 한다.겉치레 모델은'통일된 대상'을 중시한다. 즉, 서브시스템에 접근하는 인터페이스를 제공하는 것이다. 이 인터페이스를 제외하고는 서브시스템에 접근하는 어떠한 행위도 허용하지 않는다.겉치레 대상은 외부에서 서브시스템 내부를 방문하는 유일한 통로로 서브시스템 내부가 아무리 어지럽고 무질서해도 겉치레만 있으면'금옥의 겉치레'를 할 수 있다.
 
2. 외관 모드의 사용 장면

복잡한 모듈 또는 서브시스템에 외부 접근 인터페이스 제공

서브시스템은 상대적으로 독립적이다. - 외부에서 서브시스템에 대한 접근은 블랙박스만 조작하면 된다

저수준 인원에 의한 위험 확산 예방

외관 모드는 매우 간단하다. 단지 외관 노출에 필요한 API를 대외적으로 제공하는 것일 뿐이다. 아래의 통용 코드를 보십시오.
 

package _17FacadePattern;

/**
 *  A 
 */
public class ClassA {

	public void doSomethingA() {
		
	}
}

 

package _17FacadePattern;

/**
 *  B 
 */
public class ClassB {

	public void doSomethingB() {
		
	}
}

 

package _17FacadePattern;

/**
 *  1, API
 */
public class Facade {

	private ClassA classA = new ClassA();
	private ClassB classB = new ClassB();
	
	//  API
	public void methodA() 
	{
		classA.doSomethingA();
	}
	public void methodB() 
	{
		classB.doSomethingB();
	}
}

 
 
3. 겉치레 모드의 두 캐릭터

Facade 인터페이스 역할: 클라이언트가 이 역할을 호출할 수 있는 방법.이 역할은 서브시스템의 모든 기능과 책임을 안다.일반적인 상황에서 본 역할은 클라이언트에서 보낸 모든 요청을 해당하는 서브시스템에 위임한다. 즉, 이 역할은 실제 업무 논리가 없고 하나의 위탁류일 뿐이다.

sub시스템 서브시스템 역할: 한 개 이상의 서브시스템을 동시에 가질 수 있습니다.모든 서브시스템은 하나의 단독 클래스가 아니라 하나의 클래스의 집합이다.서브시스템은 문면의 존재를 모르고 서브시스템에 있어 문면은 단지 다른 클라이언트일 뿐이다.

4. 외관 모델의 장점

시스템의 상호 의존을 감소한다. 외부는 문면의 API에만 의존하고 서브시스템 내부에 대해 완전히 결합한다.

유연성 향상: 의존도가 감소하고 유연성이 자연히 향상되었다.서브시스템 내부가 어떻게 변화하든지 간에 겉치레에 영향을 주지 않는다면 자유롭게 활동할 수 있다.

안전성 향상: 서브시스템에 접근하고 싶은 업무에 대해 논리를 개통하고 겉으로 개통하지 않는 방법은 방문할 생각을 하지 마라.

5. 겉치레의 단점
문면 모델의 가장 큰 단점은 개폐 원칙에 부합되지 않는다는 것이다. 수정, 닫기, 확장, 개방에 대해 우리의 문면 대상을 살펴보자. 이것은 가장 중요한 것이다. 일단 시스템이 생산에 들어간 후에 작은 오류가 발견되면 어떻게 해결합니까?개폐 원칙에 완전히 따르면 근본적으로 해결할 수 없다.상속과 덮어쓰기는 모두 쓸모가 없다.유일하게 할 수 있는 것은 겉치레 캐릭터의 코드를 수정하는 것이다. 이 위험은 매우 크다.
 
6. 외관 모드의 주의사항 6.1 언제 한 개의 서브시스템이 여러 개의 외관을 필요로 하는가

겉모습은 참을 수 없을 정도로 거대해졌다. 같은 종류의 코드가 수천 줄이나 될 때 나는 네가 잘 이해할 수 있다고 생각한다.

서브시스템은 서로 다른 접근 경로를 제공할 수 있다. 위의 유니버설 코드에서 Facade 클래스는 ClassA, ClassB, ClassC의 모든 API를 대외적으로 폭로했다. 그러나 이런 API는 X 클라이언트에게만 폭로하고 싶을 수도 있다. Y 클라이언트에게 나는 ClassB의 API만 폭로하고 싶은데 어떻게 현실화합니까?다음 코드를 보십시오.

package _17FacadePattern;

/**
 *  2, ClassB API
 */
public class Facade2 {

	private Facade facade = new Facade();
	
	//  ClassB API
	public void methodB() 
	{
		facade.methodB();
	}
}

 
 
추가된 외관은 간단하다. 이미 존재하는 외관 대상인Facade에 위탁하여 처리한다. 왜 위탁이 있으면 서브시스템에 위탁하는 방법을 작성하지 않는가?대상을 대상으로 프로그래밍을 할 때 가능한 한 같은 코드를 한 번만 쓰고 나중에 도처에서 비슷한 코드를 수정하는 비극을 피하기 때문이다.
 
6.2 서브시스템 내의 업무 논리에 관여하지 않음
이것은 무슨 뜻입니까? 다음 코드를 보십시오.
 

package _17FacadePattern;

/**
 *  3, 
 */
public class Facade3 {

	private ClassA classA = new ClassA();
	private ClassB classB = new ClassB();
	
	//  API
	public void methodA() 
	{
		classA.doSomethingA();
	}
	public void methodB() 
	{
		classA.doSomethingA();
		classB.doSomethingB();
	}
}

 
 
어떤 요구 사항이 바뀌었기 때문에, 우리는 겉면의methodC에서 다른 방법을 사용했다.사실 이런 디자인은 매우 믿을 수 없는 것이다. 왜?당신은 이미 겉치레 대상을 업무 논리에 참여하게 했기 때문에 겉치레 대상은 서브시스템에 접근하는 경로를 제공할 뿐이다. 이것은 구체적인 업무 논리에 참여하지 말아야 한다. 그렇지 않으면 거꾸로 의존하는 문제가 생길 수 있다. 서브시스템은 반드시 겉치레에 의존해야만 방문할 수 있다. 이것은 설계상의 심각한 오류로 단일 직책 원칙에 위배될 뿐만 아니라 시스템의 봉인성도 파괴한다.그래, 이렇게 많이 말했는데, 어떻게 바꿔야 하는지 보자. 먼저methodC의 논리를 다른 종류에 봉합하자.
 

package _17FacadePattern;

/**
 *  
 */
public class Context {

	private ClassA classA = new ClassA();
	private ClassB classB = new ClassB();
	
	//  API
	public void methodB() 
	{
		classA.doSomethingA();
		classB.doSomethingB();
	}
}

 
 
그리고 문에서 봉인 클래스를 호출합니다.
 

package _17FacadePattern;

/**
 *  4, 3 
 */
public class Facade4 {

	private ClassA classA = new ClassA();
	private Context context = new Context();
	
	//  API
	public void methodA() 
	{
		classA.doSomethingA();
	}
	public void methodB() 
	{
		context.methodB();
	}
}

 
 
이렇게 한 번 봉인을 한 후에 문면 대상은 업무에 참여하지 않는다. 문면 모델에서 문면 역할은 안정적이어야 한다. 문면 역할은 자주 변화해서는 안 된다. 한 시스템이 일단 운행에 들어가면 바뀌지 말아야 한다. 문면 시스템은 대외적인 인터페이스이다. 네가 자주 변화하면 어떻게 다른 모듈의 안정적인 운행을 보장할 수 있겠니?그러나 업무 논리는 자주 바뀐다. 우리는 이미 그것을 서브시스템 내부에 봉했다. 당신이 어떻게 변화하든지 외부 방문자들에게 똑같은 겉모습, 같은 방법 - 이것이야말로 구조자가 가장 바라는 구조이다.