Shulou(Shulou.com)06/01 Report--

Today, the editor will share with you the relevant knowledge of what is the motivation of the abstract factory in web design. The content is detailed and the logic is clear. I believe most people still know too much about this knowledge, so share this article for your reference. I hope you can get something after reading this article. Let's take a look.

Motivation of Abstract Factory pattern

Consider a user interface toolkit that supports multiple l o o k-an d-f e e l standards, such as M o ti f and Presentation Manager. Different visual styles define different appearance and behavior for user interface "window components" such as scroll bars, windows, and buttons. To ensure portability between visual style standards, an application should not hard-code its window components for a specific visual appearance. Instantiating window component classes with a specific visual style throughout the application will make it difficult to change the visual style in the future.

"Design patterns" was written very early, so there will be many past software and technologies in the book, such as Moti and Presentation Manager above. It is suggested that we should not pay too much attention to these nouns and be able to understand the author's intention. There will be no problem ignoring the example in the above text, as long as you can find a similar scenario, such as the theme of the Linux operating system is a good example. In addition to different ways of expression, the way of action will also be different. As you can imagine: if you write all the code related to the topic in one class, the code is bound to become very complex and the end result is unmaintainable and unextensible.

To solve this problem, we can define an abstract Wi d g e t F a c t o r y class that declares an interface for creating each class of basic window components. Each type of window component has an abstract class, while the concrete subclass implements the specific visual style of the window component. For each abstract window component class, the Wi d g e t F a c t o r y interface has an operation that returns a new window component object. The customer invokes these operations to get the window component instance, but the customer does not know which specific classes they are using. In this way, the customer does not rely on the general visual style, as shown in the following page.

Each visual perception standard corresponds to a specific Wi d g e t F a c t o r y subclass. Each subclass implements the operations used to create window components with the appropriate visual style. For example, the C re at e S c r o l l B a r operation of M o ti f Wi d ge t F a c t o r y instantiates and returns a M o ti f scroll bar, while the corresponding P M Wi d ge t F a c t o r y operation returns a Presentation Manager scroll bar. Customers create window components only through the Wi d g e t F a c t o r y interface, and they don't know which classes implement specific visual style window components. In other words, the customer only interacts with the interface defined by the abstract class and does not use the interface of the specific concrete class.

There is only one way to solve this kind of problem in object-oriented, which is to use polymorphism to first establish abstract classes of various window constructs, and then prepare concrete classes for corresponding constructs in each topic. The Windows and ScrollBar in the figure above are the abstract classes of window composition, and PMWindow,MotiWindow,PMSrollBar,MotiScrollBar is the corresponding concrete class.

For Client, the user of window composition, you don't need to know the concrete class of each window composition, just know that the component is some kind of Window or some kind of ScrollBar. But there is another problem: although Client may not know the component representation class information when using components, there is no way to continue to pretend to be confused when building components.

The idea to solve this problem is to encapsulate the part of the building window component into a class. The name can be WidgetFacroty, which generates the corresponding window components based on the topic information and leaves the bad things to others to do. This is the simple factory model. The simple engineering model is still not perfect: because when adding themes, you still need to make some changes to the factory class.

Finally, it's time for the protagonist to come out.

Here, let's continue with the trick of facing up to the object: polymorphism. We can prepare an abstract class for a factory, and then prepare a concrete class for each topic. Each figurative factory class is responsible for generating window components for the corresponding theme. When you need to change the theme, you can change the concrete factory class.

Wi d g e t F a c t o r y also enhances dependencies between specific window component classes. A M o t i f scroll bar should be used with the M o t i f button and the M o t i f body editor, and this constraint is automatically added as a result of using M o t i f Wi d g e t F a c t o r y.

Client can only get window components through the specified concrete factory class, which determines which concrete window building classes work together.

That's all of the article "what is the motivation of an abstract factory in web design?" Thank you for reading! I believe you will gain a lot after reading this article. The editor will update different knowledge for you every day. If you want to learn more knowledge, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.