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

This article focuses on "what are the effects of using the web factory method". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Now let the editor take you to learn "what are the effects of using the web factory method"?

Effect.

The factory method no longer binds classes related to a particular application to your code. The code only deals with the Product interface; so it can be used with any user-defined ConcreteProduct class.

One of the things you often do when writing extensible code is to distinguish between the common parts of the problem domain and the specific parts of the application. The most common entrance to a particular section is the location where the object is created. The factory method pattern just provides a way to separate the parts that build a particular class. With the common part of this method, you only need to program the Product interface, which structurally ensures that the common code can work with any concrete Product class.

A potential disadvantage of the factory approach is that customers may have to create subclasses of Creator just to create a specific ConcreteProduct object. When the Creator subclass is not necessary, the customer is now bound to deal with other aspects of class evolution; but when the customer has to create a subclass of Creator anyway, it is possible to create a subclass.

A potential disadvantage of factory methods is that clients might have to subclass the Creator class just to create a particular ConcreteProduct object.Subclassing is fine when the client has to subclass the Creator class anyway, but otherwise the client now must deal with another point of evolution.

The translation of the second half of this paragraph is not easy to understand and read together with the original English text. The factory method uses subclasses of Creator to create ConcreteProduct objects. This is a potential drawback. The reason for this potential is that if this Creator subclass is already necessary, then using the factory method does not impose a new burden, otherwise the customer will have to deal with other aspects of evolution if everything is OK;. The author of "Design pattern" here does not specify what other aspects refer to specifically, and the author guesses that it may refer to the burden of subclassing Creator classes.

Here are two other effects of Factory Method mode:

1) provide hooks for subclasses (hook)

Creating an object inside a class with a factory method is usually more flexible than creating an object directly. Factory Method gives a hook to the subclass to provide an extended version of the object.

In the case of Document, the Document class can define a factory method called CreateFileDialog, which creates a default file dialog object for opening an existing document. A subclass of Document can redefine this factory method to define a file dialog associated with a particular application. In this case, the factory method is no longer abstract but provides a reasonable default implementation.

Using the factory method to create an object within a class has two meanings: first, encapsulating the code that creates the object in a member function, and then declaring the function as a virtual function. This provides derived classes with the flexibility to choose to extend or not to extend.

2) join parallel class hierarchies

So far, in the examples we consider, factory methods are not often just called by Creator, and customers can find some useful factory methods, especially at the parallel class level.

The code that builds the ConcreteProduct can be used by Creator itself and sometimes by other customers. Especially in the structure of parallel class hierarchy.

When a class delegates some of its responsibilities to a separate class, a parallel class hierarchy is generated.

This sentence is not easy to understand, so don't worry and move on to the following example.

Consider graphics that can be manipulated interactively; that is, they can be stretched, moved, or rotated with the mouse.

We can think of the extension, movement, or rotation of graphics as part of the responsibility of the graphics class.

It is not always easy to achieve such interactions, and it usually requires storing and updating information that records the manipulation status at a given time, which is only needed when manipulating. So it does not need to be saved in the drawing object.

The implementation of the above interaction is difficult, and it is usually necessary to store the state of the operation. If really in the internal implementation of each graphics class will take up a lot of space. At the same time, this information is only needed in the operation, and is not an essential part of each graphics class. The hope of the author of "Design pattern" should be that there is a real need to delegate the responsibility of interoperability.

In addition, when users manipulate graphics, different graphics have different behaviors. For example, lengthening a line graph may have the effect of an end being moved, while stretching the body graph may change the line spacing.

Different graphics often have different treatments for stretching, moving, or rotating. What I'm talking about here is that different processing classes are required for different graphics.

With these limitations, it's best to use a separate Manipulator object to interact and save any required state related to a particular manipulation. Different drawings will use different Manipulator subclasses to handle specific interactions. The resulting Manipulator class hierarchy is parallel (at least partially parallel) to the Figure class hierarchy, as shown in the following figure.

The relationship between this graph class and the Manipulaotr class is the parallel class. In this example, the graphics class delegates the responsibility of controlling the extension, movement, and rotation of the graphics to the Manipulator class.

The Figure class provides a CreateManipulator factory method that allows customers to create a Manipulator corresponding to Figure. The Figure subclass redefines the method to return an appropriate instance of the Manipulator subclass. As an option, the Figure class can implement CreateManipulator to return a default Manipulator instance, while the Figure subclass can simply inherit the default implementation. Such a Figure class does not require a corresponding Manipulator subclass-so the hierarchy is only partially parallel. Notice how the factory method defines the connection between the two class levels. It localizes information about which classes should work together.

In this example, the relationship between the Figure class and the Manipulator class is established through the CreateManipulator factory method provided by Figure.

Similarly, we can design CreateSetupDialog factory methods for the Figure class to establish a relationship between the Figure class and the settings screen for each graph.

At this point, I believe you have a deeper understanding of "what are the effects of using the web factory method". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.