Appearance mode (the Facade the Pattern) :
It provides a consistent interface subsystem is a set of interfaces. Façade pattern defines a high-level interface that makes the subsystem easier to use. (Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.)
Appearance mode core : to provide a unified subsystem entrance. Package subsystem complexity, ease of client calls. So that the client and the decoupling between subsystems, allowing internal module functional subsystems easier to extend and maintain;
According to the Law of Demeter (the principle of least knowledge): a software entity should be as little interaction with other entities.
Development of common scenarios : high frequency applications. Where I will encounter. Various techniques and frameworks, both
have to use the appearance pattern. Such as: the JDBC package, provided commons DbUtils class, Hibernate provides tools and tools like the Spring JDBC
Briefly, this model is the complex processes encapsulated into a user interface to an external supply easier to use. This mode, designed to three characters.
1) subsystems role: to achieve a functional subsystems. It is unknown when the customer roles and Facade. It can have another internal interactions within the system, the interface can also be called by the external supply.
2) the role of the facade: a core aspect mode. It is called the client role, it is familiar with the subsystem functionality. According to the internal needs of customers booked the role of a combination of several functions.
3) Customer role: to fulfill the functions to be implemented by calling Facede.
Case :
For example, a registered company processes, in three steps:
Step 1: Define Subsystem role
/**
* 工商局
*/
public interface 工商局 {
void checkName(); //核名
}
class 海淀区工商局 implements 工商局 {
@Override
public void checkName() {
System.out.println("检查名字是否有冲突！");
}
}
/**
* 质检局
*/
public interface 质检局 {
void orgCodeCertificate(); //办理组织机构代码证
}
class 海淀质检局 implements 质检局 {
@Override
public void orgCodeCertificate() {
System.out.println("在海淀区质检局办理组织机构代码证！");
}
}
/**
* 税务局
*/
public interface 税务局 {
void taxCertificate(); //办理税务登记证
}
class 海淀税务局 implements 税务局 {
@Override
public void taxCertificate() {
System.out.println("在海淀税务局办理税务登记证！");
}
}
/**
* 银行
*/
class 中国工商银行 implements 银行 {
@Override
public void openAccount() {
System.out.println("在中国工商银行开户！");
}
}
Step 2: Define roles facade
/**
* 门面角色：办理注册公司流程的门面对象
*/
public class RegisterFacade {
public void register(){
工商局 a = new 海淀区工商局();
a.checkName();
质检局 b = new 海淀质检局();
b.orgCodeCertificate();
税务局 c = new 海淀税务局();
c.taxCertificate();
银行 d = new 中国工商银行();
d.openAccount();
}
}
Step 3: Define Customer role
/**
* 客户端调用
*/
public class Client1 {
public static void main(String[] args) {
new RegisterFacade().register();
}
}
Execution results as shown below:
The client need not know the internal implementation details of the system, even without knowing the internal configuration of the system. The client just keep up Facade interaction on it.
Finally, a picture to explain the benefits of the facade pattern:
If you want to know more design patterns, you can visit: Introduction Overview of design patterns and 23 kinds of design patterns