I. Overview
Facade Pattern is a structural design pattern that provides a unified high-level interface for operations in multiple subsystems to access the functions of complex subsystems. Its core idea is to encapsulate the complex operations of the subsystem through a facade class, and the client only needs to interact with the facade class without knowing the specific operation details of the subsystem. This greatly simplifies the use of the client, while reducing the coupling between the client and the subsystem.
In layman's terms, to implement a function, we may need to call multiple operations in a subsystem, or combine operations in different subsystems. The appearance mode is to provide a facade, that is, to provide a unified external access platform on top of a bunch of subsystems, through which complex subsystem functions can be completed with one click.
Today is Children's Day, let's celebrate innocence together. Let's use an amusement park as an example. A large children's amusement park will have a lot of charging items. We can buy tickets for each item separately, or we can directly purchase tickets for all items on the comprehensive ticketing platform at the gate of the playground or on the online platform, or even buy tickets for all items. Tickets, which greatly shorten the waiting time in line. This is the application of the appearance mode. The ticket office of each project represents each subsystem, and the integrated ticketing platform is our appearance, which provides a unified way to access each sub-ticketing system.
Roles Involved in Facade Patterns
- Facade role (Facade): A separate object that internally holds a reference to the subsystem, which defines a series of methods to access the functions in the subsystem.
- Subsystem role (SubSystem): A group of interrelated classes or objects, each subsystem can operate independently.
- Client (Client): interacts directly with facade objects, thereby indirectly accessing subsystem functions.
Realization principle
- Clients access the subsystem by instantiating a facade object.
- Facade objects internally hold instance references to subsystems.
- The façade object delegates the client's requests to the appropriate components of the subsystem.
- Subsystem components handle specific work and return results to facade objects.
- The facade object returns the result to the client.
advantage
- Hide the complexity and specific details of the subsystem and simplify the use of the client: the appearance mode allows the client to interact with the complex subsystem through a simple interface without paying attention to the specific implementation of the subsystem, which reduces the difficulty of using the client.
- Reduce the coupling between the client and the subsystem: the client does not directly interact with the subsystem, so that the change of the subsystem will not have a great impact on the client, which is the embodiment of "Dimit's law".
- Easy to maintain: Encapsulate the operation of the subsystem in a facade class, making maintenance and modification easier.
shortcoming
- Does not comply with the open-closed principle: adding new subsystems may require modification of the facade class or client code.
- May lead to underutilization of functionality: Uniform high-level interfaces may limit the functional usage of subsystems.
- Potential for abuse: Putting too much functionality in a facade object can result in a large and complex facade object.
Applicable scene
- Facade mode can be used when you need to provide a unified operation interface or simple entry for multiple complex subsystems.
- Facade mode can be used when you want to hide the complexity of the system and only expose the necessary interfaces to the client.
- When there are many dependencies between the client and multiple subsystems, and you want to reduce the degree of coupling, you can use the facade mode.
2. Case realization
case analysis
As shown in the example above, we have three children's play items: building block park, bumper car and carousel, which represent three subsystems respectively. First, we can define an abstract interface ChildrenPlayItem, which represents the public interface of all play items, which defines ticket purchase and play The public behavior, and then the three subsystems respectively implement this interface to complete the functions of the subsystem. Next, define an appearance class PlayEntry, which represents the game entry, and we will enter from this entry for any items we want to play. No matter how many items you choose, you can buy tickets and play through this entrance, and finally you can calculate the total fare spent.
Code
Step 1 : Create the abstract interface ChildrenPlayItem of the amusement park project, which declares the methods of purchasing tickets and playing.
public interface ChildrenPlayItem {
int ticket();
void play();
}
Step 2 : Implement three subsystems respectively: building block park, bumper car, carousel
public class BlockPark implements ChildrenPlayItem {
private int price=12;
@Override
public int ticket() {
System.out.println("购买积木乐园项目票,票价"+price);
return price;
}
@Override
public void play() {
System.out.println("堆积木咯...");
}
}
public class BumperCar implements ChildrenPlayItem {
private int price=88;
@Override
public int ticket() {
System.out.println("购买碰碰车项目票,票价"+price);
return price;
}
@Override
public void play() {
System.out.println("玩碰碰车咯...");
}
}
public class Carousel implements ChildrenPlayItem {
private int price=39;
@Override
public int ticket() {
System.out.println("购买旋转木马项目票,票价"+price);
return price;
}
@Override
public void play() {
System.out.println("玩旋转木马咯...");
}
}
Step 3 : Create the appearance class PlayEntry as the game entry
public class PlayEntry {
private ChildrenPlayItem blockPark; //积木乐园
private ChildrenPlayItem bumperCar; //碰碰车
private ChildrenPlayItem carousel; //旋转木马
private int charge;
public PlayEntry() {
this.blockPark = new BlockPark();
this.bumperCar = new BumperCar();
this.carousel = new Carousel();
this.charge=0;
}
//玩积木
public void playBlockPark(){
int itemPrice=blockPark.ticket();
blockPark.play();
charge+=itemPrice;
}
//玩碰碰车
public void playBumperCar(){
int itemPrice=bumperCar.ticket();
bumperCar.play();
charge+=itemPrice;
}
//玩旋转木马
public void playCarousel(){
int itemPrice=carousel.ticket();
carousel.play();
charge+=itemPrice;
}
//计费
public void pay(){
System.out.println("一共要支付的项目票价总额为："+charge);
}
}
Step 4 : The client calls the method declared in the appearance class to play the game experience of the three projects respectively
public class Client {
public static void main(String[] args) {
PlayEntry entry=new PlayEntry();
entry.playBlockPark();
entry.playBumperCar();
entry.playCarousel();
entry.pay();
}
}
Test Results
3. Summary
Facade mode provides a simplified interface for complex subsystems, allowing clients to manipulate subsystems more easily, while reducing the coupling between clients and subsystems. Facade mode also has some disadvantages, such as not complying with the principle of opening and closing, which may lead to underutilized functions. Of course, in the right scenario, these shortcomings are the benevolent see benevolence and the wise see wisdom. I hope that everyone can discover and learn more from energy codes in the usual software development process, so that they can truly learn the essence of design patterns.
Thank you for reading this article on the explanation of appearance patterns. The beauty of design patterns column has been updated halfway. If you are learning design patterns, you can subscribe to my column. I will try my best to help you with the most classic cases and the most concise codes. Better understanding and mastery of design patterns. If there are any omissions or inappropriateness in the column article, you are very welcome to leave a message to correct me, and I hope everyone can make progress together.
