[Study Notes] Design Pattern-based Facade

To facilitate readers, this article has been added to the index: Design Mode learning note index Facade (appearance) mode defines a high-level interface, it provides a consistent interface for a group of interfaces in the subsystem, making it easier to use. Welcome back to the magic world of the wizard. In the battle against the bad witch's magic creature (see the Bridge Mode Note), the key to white snow's chance to win a big reversal is the birth of the magic weapon. However, normal weapons workshops (see FactoryMethod mode notes) cannot produce magic weapons and can only be obtained through special magic workshops. After the first battle, we also felt that apart from weapons, we also needed armor that could protect our bodies against injury. Therefore, hobbies intend to build some armor workshops. As a result, more and more systems are used to produce combat supplies. If they need to obtain a set of suitable combat supplies, they have to call the production methods of each system separately. In fact, little hobbies don't care about the details of each system, they just want to get a finished product. For them, the powerful but low-level interfaces in these production systems will only complicate their tasks. To make the lives and battles of little hobbies more convenient, Glinda, a good witch (see the wizard of magic in Glinda prototype. Of course, you will not forget that I will not be loyal to the original work) provided them with a high-level interface, and shielded them from the production system class-Glinda's hut, which was officially opened in the forest. So little hobbies only need to come to the hut, tell Glinda what they need, and pay a little bit of compensation to get something they think. So what does this have to do with the theme of our notes today? In fact, this is an example of the Facade mode. We will discuss this issue in more detail in the sample analysis section. First, let's get familiar with the Facade mode! Key points: Sorting objective classification Object Schema scope criterion object (this mode processes the relationships between objects, which can be changed and more dynamic at runtime) the main function provides a consistent interface for a group of interfaces in the subsystem. The Facade mode defines a high-level interface, which makes the subsystem easier to use. Applicable when we want to provide a simple interface for a complex subsystem. Subsystems tend to become more and more complex as they evolve. In most modes, More and smaller classes are generated. This makes subsystems more reusable and easier to customize, but it also brings some difficulties for users who do not need to customize subsystems. There is a large dependency between the implementation part of the client program and the abstract class. Introducing Facade to separate this subsystem from customers and other subsystems can improve the independence and portability of the subsystem. When we need to build a layered sub-system, use the Facade mode to define the entry points for each layer of the sub-system. If subsystems are mutually dependent, we can make them communicate only through Facade, thus simplifying the dependency between them. Part of the involved Facade: It knows which sub-system classes are responsible for processing requests; it delegates the customer's requests to the appropriate sub-system objects. Subsystem Classes: implements various sub-system functions, processes tasks assigned by the Facade object, and does not have any related information about the Facade. In the collaboration process, the customer program sends a request to Facade to communicate with the subsystem. Facade forwards the message to the appropriate subsystem object. Although the objects in the subsystem are actually working, the Facade mode itself must convert its interfaces into sub-system interfaces. The customer program using Facade does not need to directly access the subsystem object. Structural chart Example Analysis-before we come to visit Glinda's hut, review the subsystems that produce combat supplies to better understand the working mechanism of the Facade model. As Weapon's design architecture has changed in the Bridge model notes, the design, including general weapons workshops, has also been adjusted accordingly. The first is our basic Weapon class: copy the Code 1 class Weapon: public VisualObject {2 public: 3 Weapon (int); 4 ~ Weapon () {delete _ impl;} 5 //... other... 6 protected: 7 WeaponImpl * getWeaponImpl (); 8 private: 9 WeaponImpl * _ impl; 10} 11 12 Weapon: Weapon (int type) {13 switch (type) 14 {15 case WEAPON_SWORD: 16 _ impl = new SwordImpl (); 17 break; 18 case WEAPON_SHIELD: 19 _ impl = new ShieldImpl (); 20 break; 21 case WEAPON_BOW: 22 _ impl = new BowImpl (); 23 break; 24 //... other cases... 25 default: 26 break; 27} 28} copy The Code also contains the adjusted WeaponFactory class and its subclasses: copy the Code 1 class WeaponFactory {2 public: 3 virtual Weapon * createWeapon () = 0; 4} 5 6 class HonorOfFighter: public WeaponFactory {7 public: 8 HonorOfFighter (); 9 Weapon * createWeapon () {return new Weapon (WEAPON_SWORD);} 10} 11 12 class BliefOfDefender: public WeaponFactory {13 public: 14 BliefOfDefender (); 15 Weapon * createWeapon () {return new Weapon (WEAPON_SHEILD) ;} 16} 17 18 class PrecisionOfHunter: public WeaponFactory {19 public: 20 PrecisionOfHunter (); 21 Weapon * createWeapon () {return new Weapon (WEAPON_BOW );} 22} 23 24 //... other weapon factories... copy the code and the enchantment workshop mentioned earlier: Copy code 1 # define ENCHANTED_ICE 1 2 # define ENCHANTED_FIRE 2 3 # define ENCHANTED_SHOCK 3 4 5 class EnchantedWeaponFactory {6 public: 7 Weapon * createEnchantedWeapon (int, int); 8 //... ot Her... 9} 10 11 EnchantedWeaponFactory: createEnchantedWeapon (int element, int type) {12 return new EnchantedWeapon (element, type); 13} copying the code has not yet completed the armor workshop: 1 class ArmorFactory: public VisualObject {2 public: 3 virtual Armor * createArmor () = 0; 4} Well, it's time to visit Linda's house HouseOfGlinda: copy code 1 # define NOTHING 0 2 3 class HouseOfGlinda {4 public: 5 VisualObject * onSale (int, int); // a simple interface. 6 7 //... It's a Singleton... 8 static HouseOfGlinda * getInstance () {9 if (_ instance = 0) {10 _ instance = new HouseOfGlinda (); 11} 12 13 return _ instance; 14} 15 16 protected: 17 Weapon * getWeapon (int); 18 Weapon * getEnchantedWeapon (int, int); 19 //... armor will be comming soon... 20 private: 21 HouseOfGlinda (); 22 static HouseOfGlinda * _ instance; 23} 24 25 VisualObject * HouseOfGlinda: onSale (int type, in T info) {26 if (WEAPON_SWORD = type | 27 WEAPON_SHIELD = type | 28 WEAPON_BOW = type29 //... other weapon... 30) {31 32 if (NOTHING = info) {33 return getWeapon (type); 34} 35 else {36 return getEnchantedWeapon (type, info ); 37} 38} 39 // else for armor... 40} 41 42 Weapon * HouseOfGlinda: getWeapon (int type) {43 WeaponFacotry * factory = 0; 44 Weapon * weapon = 0; 45 switch (type) {46 case WEAPON_SWO RD: 47 factory = new HonorOfFighter (); 48 break; 49 case WEAPON_SHIELD: 50 factory = new BliefOfDefender (); 51 break; 52 //... other cases... 53 default: 54 break; 55} 56 weapon = factory-> createWeapon (); 57 if (factory) delete factory; 58 return weapon; 59} 60 61 Weapon * HouseOfGlinda :: getEnchantedWeapon (int type, int info) {62 EnchantedWeaponFactory factory; 63 return factory. createEnchantedWeapon (info, ty Pe); 64} copy the code and notice that in the HouseOfGlinda class, the onSale interface shields the customer from the components in the subsystem (for example, WeaponFactory and EnchantedWeaponFactory, or even ArmorFactory in the construction phase ), as a customer's hobbyte, it only needs to send a request to the HouseOfGlinda object, so that it can forward the message to the corresponding subsystem for processing. For example, someone wants a common sword, the other wants a shield with a flame: 1 VisualObject * obj1 = HouseOfGlinda: getInstance-> onSale (WEAPON_SHIELD, ENCHANTED_FIRE); 2 VisualObject * obj2 = HouseOfGlinda :: getInstance-> onSale (WEAPON_SWORD, NOTHING); That's convenient. In addition, if necessary, the hobbies can still directly access the workshop to obtain customized weapons. Of course, it will be more convenient to go through Glinda's hut, so they have more time to enjoy beer and food. A simple UML diagram: Features Summary The Facade mode is simple and easy to understand, and is also very common for us. It has the following advantages: it shields sub-system components from the customer, thus reducing the number of objects processed by the customer and making the sub-system more convenient to use. It implements loose coupling between subsystems and customers, while functional components inside the subsystems are usually tightly coupled. The loose coupling makes the Component Changes of the subsystem do not affect its customers. The Facade mode helps you establish a hierarchical system and layer dependencies between objects. The Facade mode eliminates complex circular dependencies. This is especially important when the customer program and subsystem are implemented separately. If the application needs it, it does not limit the use of sub-system classes. Therefore, we can choose between the ease of use and versatility of the system.