This is the seventh day of my participation in the August More text Challenge. For details, see: August More Text Challenge
preface
Weekend study, time flies and more than half a month, the recent time is relatively tight, and the study of design mode is a long process, not impatient, this week, I spent more than two hours to write this article, it is the fifth kind of structural mode —- appearance mode.
First, appearance mode entry
1.1 an overview of the
The experience of physical examination must be experienced by all of you, and this process can actually be associated with the appearance pattern we are going to talk about today. (At the time of writing this article, I picked up the physical examination report and read it, and muttered in my heart: XDM, pay attention to your health!)
The general physical examination process is that we go to the physical examination center on an empty stomach according to the date booked online. According to the scheduled items, there are general examination, internal medicine, surgery, ophthalmology, color ultrasound, electrocardiogram, blood routine, urine routine and so on.
And we often do not know where these rooms are the first time to go, so we usually go to the reception staff on the scene, through it to find the specific location of our physical examination target, this process can be regarded as the appearance mode, also known as the facade mode.
Ok, now that we understand what it means, let’s take a look at the professional explanation of it.
Wikipedia definition:
Facade pattern is a kind of software design pattern commonly used in software engineering. It provides a unified high-level interface for a set of interfaces in a subsystem and makes the subsystem easier to use.
It is a structural design pattern that provides a simple interface to a library, framework, or other complex class. Also known as facade pattern, is a pattern that makes multiple complex subsystems more accessible by providing a consistent interface to those subsystems. This pattern has a unified interface, and the external application program does not have to care about the specific details of the internal subsystem, which will greatly reduce the complexity of the application program and improve the maintainability of the program.
The Facade pattern is a typical application of Demeter’s law, as in the star and agent example.
1.2 structure
The following is a general structure of the appearance pattern. Without the role of “receptionist”, we would be running around the hospital, but with such a “facade”, we are only responsible for dealing with it, through which we can achieve our purpose.
The role of the appearance mode is also very simple:
- Facade roles: Provide a common interface to multiple subsystems
- Subsystem roles: Implement parts of the system that can be accessed by the customer through a facade role.
Through these two roles, the following goals can be achieved:
- 1. After the appearance role is introduced, the user only needs to interact with the appearance role
- 2. The complex logical relationships between users and subsystems are implemented by facade roles
Ii. Case study
Here, let’s take this physical examination case to use code to achieve it.
Define three physical examination items, and one receptionist, and one test class.
/** * InternalMedicine **/ public class InternalMedicine {public void here(){system.out.println (" no exception "); }} /** * Ophthalmology **/ public class Ophthalmology {public void here(){system.out.println (" eye care!"); ); }} /** * Surgical **/ public class Surgical {public void here(){system.out.println (" no exception "); } /** * Receptionist **/ public class Receptionist {private InternalMedicine inner; private Ophthalmology eye; private Surgical out; public Receptionist(){ inner=new InternalMedicine(); eye =new Ophthalmology(); out=new Surgical(); } public void say(String message){if(message.equals(" I need a checkup ")){this.gohere(); }} private void gohere() {system.out.println (" welcome to our physical checkup center!! There's the checkup. Go ahead." inner.here(); eye.here(); out.here(); }}Copy the code
Output results:
Welcome to our physical examination center!! Physical examination item is there, go ~ internal medicine did not see abnormal eye care to maintain! No abnormalities were observed in surgeryCopy the code
3. Pattern analysis
3.1 the advantages and disadvantages
Advantages:
- The coupling between the subsystem and the client is reduced so that changes to the subsystem do not affect the client classes that call it, and you can keep your code independent of complex subsystems.
Disadvantages:
- Not conforming to the open closed principle, all classes are coupled together, modification is very troublesome.
3.2 Application Scenarios
- Use the facade pattern when you want to provide a simple interface to a complex subsystem. This interface meets the needs of most users, and users can access the subsystem directly over the facade classes.
- 2. The introduction of appearance classes can decouple subsystems from customers and other subsystems, which can improve the independence and portability of subsystems.
- 3. In the hierarchical structure, the appearance pattern can be used to define the entrance of each layer in the system. The connection between layers is not directly generated, but the connection is established through the appearance class to reduce the coupling degree between layers.
3.3 Appearance Mode Is different from adapter mode
The adapter pattern is to transform the interface of a class into another interface that the customer expects. The adapter allows classes whose interfaces are not compatible to work together.
The facade pattern is a set of interfaces that provide a unified, high-level interface for accessing a subsystem to make it more useful.
In short: The adapter pattern is responsible for transforming one object interface into different interfaces. The adapter pattern is responsible for wrapping multiple objects together to provide a unified interface to simplify the interface
3.4 Points to Note
- A system has multiple facade classes
In the appearance pattern, there is usually only one appearance class, and there is only one instance of this appearance class, in other words it is a singleton. In many cases, in order to save system resources, the appearance class is generally designed as a singleton class. Of course, this does not mean that there can only be one appearance class in the whole system. In a system, you can design multiple appearance classes, each of which is responsible for interacting with some specific subsystem to provide the corresponding business function to the user.
- Do not try to add new behavior to your subsystem through facade classes
It is a mistake not to add new behavior to a subsystem by inheriting a facade class. The purpose of the facade pattern is to provide a centralized and simplified communication channel for subsystems, not to add new behavior to subsystems. The new behavior should be added by modifying existing subsystem classes or adding new subsystem classes, not by facade classes.
- Appearance patterns and Demeter’s law
The look and feel pattern creates a look and feel object that minimizes the number of clients involved in collaborating with objects that belong to a subsystem, so that client interactions with objects inside the subsystem are replaced by look and feel objects. The appearance class acts as a “third party” between the customer class and subsystem class, reducing the coupling degree between the customer class and subsystem class. The appearance pattern is a powerful weapon to realize the code refactoring to meet the requirements of “Demeter’s law”.
- Introduction of abstract appearance classes
The biggest disadvantage of the facade mode is that it violates the “open closed principle”. When new subsystems are added or removed, the facade class needs to be changed. To some extent, this problem can be solved by introducing abstract facade classes, which the client programs against. For new business requirements, the original appearance class is not modified, but a new concrete appearance class is added. The new concrete appearance class associates the new subsystem object. At the same time, the source code is not modified and the appearance class is changed by modifying the configuration file.
3.5 summary
The appearance pattern is relatively simple to understand. By dealing with the facade, it avoids the operation of the following complex subsystems, thus achieving the purpose of simplifying the system and making the complex system easy to use. If used properly, it can help us to better divide the level of access, hide some of the complex details to the subsystem, and leave a simple interface for the appearance to show, appearance mode, as simple as that!
Finally, I wish my brothers can all pass the physical examination indicators and all the examination results reach the standard.
Design pattern itself has certain difficulty in the application, need certain business experience, if one day you suddenly revealed in which the underlying source code which you read mode, the value, if which day, you in the face of the business was in a hurry, suddenly the forehead a beat, ah, maybe a model appearance, that you may be insight, hope that one day a little closer to you. I am Xiao Lei, if you find this article helpful or inspiring, please give me a like, it will be the best motivation for my creation!
Reference documents:
- Refactoringguru. Cn/design – patt…
- www.kancloud.cn/digest/xing…
Iv. Brief introduction to design mode series 👏👏👏
- (1): The foundation of great oaks from little acorns
- (2): Singleton patterns — there is only one example
- (3): Factory pattern — the generation of instances to subclasses
- (4): Prototype pattern — generate examples by copying
- [Design Patterns] (5): Builder pattern — assembling complex examples
- (6): Agency mode — look at the influence of intermediary
- (7): Adapter mode — Let Obama see that the three-body is not a dream
- (8): Decorator mode — nesting doll + “grasping cake case” quick introduction
- (9): Bridge mode — re-entry by “grasping cake case”