Appearance mode, some information is also called “appearance mode”, appearance mode is relatively simple to use, the frequency of use is not high, mainly this idea. Take an example in life, we know that before if a certificate for the latter procedures, before the Internet, we want to run each unit department, may not be a trip; Before, it was either to mock the efficiency of government agencies on the Internet, or to prove that “I am myself”.

Now all industries have stepped on the information, do not have to run back and forth, directly on the Internet can do a lot of things, of course, there is no lack of need to go to the scene. Everyone mobile phone will have alipay this APP, above the “citizen center module”, the function covers a lot of things we often do, what life payment, social security for inquiry, accumulation fund inquiry extraction, talent employment…. And so on. These sub-functions after we go in, will jump to the specified service page; Although provided by a different system, the entrance now has only a “civic centre”.

Back to software design level, what time do you will use to the scene, said to our design specification has said in front of the “interface responsibilities oneness” problem, the problem with this is probably the granularity of the interface is very fine, if a business needs to design multiple interfaces call, is bound to increase the use of the client or caller more complex. If our interface changes, the caller needs to change as well, violating the “open close principle” of the design specification. At this time, we can aggregate some interfaces with single responsibilities according to the business and expose them to the user (the aggregation class here is our facade). The user only needs to adjust the interface provided by the facade. After the subsequent change of relevant business, our facade does not need to be modified. However, if you add subinterfaces, you may need to change the facade.

The structure and implementation of the facade pattern

The pattern has the following primary roles.

  • Facade Role: Provides a common interface externally for multiple subsystems (or interfaces).
  • Sub System roles: Implement some functions of the System, and users access them through appearance roles.
  • Client role: Access the functionality of each subsystem through a facade role.

Appearance mode structure diagram:

Case code: Here in accordance with the beginning of this article to pay alipay case to achieve the use of the following appearance mode

  • Subsystem Role 1 Provident Fund management center
public class AccumulationDund {
	
	public void transaction(a){
		System.out.println("Provident Fund Management Centre - Provident Fund Business"); }}Copy the code
  • Subsystem Role 2 Social security processing center
public class SocialSecurity {
	
	public void transaction(a){
		System.out.println("Social Security Center - Social Security Business"); }}Copy the code
  • Subsystem Role 3 Mobile phone recharge center
public class MobileTopup {
	
	public void transaction(a){
		System.out.println("Mobile Phone Top-up Centre - Mobile Phone Top-up Service"); }}Copy the code
  • Observer role alipay APP civic Center
public class ZFBFacade {
	private SocialSecurity socialSecurity;
	
	private AccumulationDund accumulationDund;
	
	private MobileTopup mobileTopup;

	public ZFBFacade(SocialSecurity socialSecurity, AccumulationDund accumulationDund, MobileTopup mobileTopup) {
		super(a);this.socialSecurity = socialSecurity;
		this.accumulationDund = accumulationDund;
		this.mobileTopup = mobileTopup;
	}
	
	// Business center
	public void businessCenter(a){
		// Social security business
		socialSecurity.transaction();
		// Provident fund business
		accumulationDund.transaction();
		// Mobile phone recharge servicemobileTopup.transaction(); }}Copy the code
  • Users of the client
public class Client {
	
	public static void main(String[] args) {
		SocialSecurity socialSecurity = new SocialSecurity();
		AccumulationDund accumulationDund = new AccumulationDund();
		MobileTopup mobileTopup = new MobileTopup();
		
		ZFBFacade zfbFacade = newZFBFacade(socialSecurity, accumulationDund, mobileTopup); zfbFacade.businessCenter(); }}Copy the code

Execution Result:

Social Security Center - Social Security Business Accumulation Fund Management Center - Accumulation fund business Mobile phone Top-up center - Mobile phone top-up serviceCopy the code

Case Structure Diagram:

Pros and cons of appearance patterns

The Facade pattern, a typical application of Demeter’s Rule, has the following major advantages.

  • The coupling degree between subsystem and client is reduced, so that the change of subsystem does not affect the client class that calls it.
  • Shielding subsystem components from the customer reduces the number of objects the customer processes and makes the subsystem easier to use.

The main disadvantages of the Facade pattern are as follows.

  • The subsystem classes are not well restricted to customers, which can easily lead to unknown risks.
  • Which subsystems should be adapted to the facade mode, which increases the difficulty of facade design;
  • Adding new subsystems may require modifications to the facade class or client source code, violating the “open close principle.”

Usage scenarios for appearance patterns

The use of facade patterns is usually considered in the following situations.

  • When constructing hierarchical system, using appearance pattern to define the entry point of each layer in subsystem can simplify the dependency between subsystems.
  • When a complex system has many subsystems, appearance mode can design a simple interface for the system to be accessed by the outside world.
  • When the user calls multiple subsystems, multiple network interactions may affect the performance of the entire service, so the unnecessary network overhead can be reduced by means of facade.

Application of appearance pattern in source code

1. The use of Tomcat source code in Tomcat extensive use of appearance mode, here is an example of Tomcat use appearance mode to wrap Request, first look at the class diagram

Refer to the online information org. Apache. Coyote. Request the underlying implementation is the application layer to get the Request object, inconvenient to use. Org. Apache. Catalina. Connector. Request class encapsulates the org. Apache. Coyote. Request, implements it interface, has the ability of actual use, However, it also contains many Catalina methods that should not be exposed to the application layer for compatibility issues with other container implementations. Org. Apache. Catalina. Connector. RequestFacade class that implements it interface, and in which contains an org. Apache. Catalina. The Request object, All call it interface, agent for org. Apache. Catalina. The Request object, thus shielding the catalina relevant internal method, the user can focus on standard method of the servlet.