Application of factory method pattern in Python program in detailed design pattern

The factory methods (Factory method) mode, also known as the virtual Constructor mode or the Polymorphic factory (polymorphic Factory) mode, belongs to the class's creation pattern. In the factory method pattern, the parent class is responsible for defining the public interface that creates the object, and the subclass is responsible for generating the concrete object, which is done by deferring the instantiation of the class to the subclass, which is the subclass that determines which class should be materialized.
In simple Factory mode, a factory class is positioned at the center of the instantiation of the product class, knowing the details of each product class and deciding when and where the product class should be instantiated. The advantage of the simple factory model is the ability to make the client independent of the product creation process, and to introduce new products into the system without having to modify the client, the disadvantage is that when a new product is added to the system, the factory class must be modified to incorporate the necessary processing logic. The Achilles heel of the simple factory model is the factory class at its core, because it cannot be used when it cannot determine which class to instantiate, and the factory method pattern avoids the problem well.
Consider an application framework (framework) that can be used to browse documents in various formats, such as TXT, DOC, PDF, HTML, etc., in order to allow the software architecture to be as generic as possible, defining the two abstract parent classes application and document , customers must process a specific type of document through their subclasses. For example, to use the framework to write a PDF file browser, you must first define the two classes Pdfapplication and Pdfdocument, which should inherit from application and document respectively.
Application's responsibility is to manage the document and create them when needed, such as when the user chooses open or new from the menu, application is responsible for creating an instance of the document. It is obvious that the particular document subclass being instantiated is related to the application, so application cannot predict which document's subclass will be instantiated, it only knows when a new document was created, However, it is not known which (which) specific document will be created. There is a very awkward situation when you persist in using the Simple Factory mode: The framework must instantiate a class, but it knows only abstract classes that cannot be instantiated.
The solution is to use the factory method pattern, which encapsulates the information that the document subclass will be created and is able to separate that information from the framework. As shown in 1, the subclasses of application redefine application's abstract method CreateDocument () and return an instance of an appropriate document subclass. We call CreateDocument () a factory approach (factory method) because it vividly describes the instantiation of a class, which is responsible for "producing" an object.

In short, the function of the factory method pattern is to generate instances of classes based on different conditions, which typically belong to multiple similar types and have a common parent class. The factory method pattern encapsulates the creation of these instances, simplifying the writing of the client program and improving the scalability of the software architecture, allowing new subclasses to be added at the lowest possible cost in the future. Factory method This model is suitable for use in the following situations:
When it is not possible to know which class the object must be created in, or when the object belonging to that class is to be returned, it is only if these objects conform to certain interface standards.
When a class wants its subclasses to decide which objects to create, its purpose is to make the program more extensible and more resilient when other classes are added.
When the responsibility for creating an object is delegated to one of several helper subclasses (helper subclass), and you want to place which subclass is the agent this information is localized.
It is important to note that creating objects using the factory method pattern does not necessarily make the code shorter (often longer in fact), and may require more auxiliary classes to be designed, but it does have the flexibility and flexibility to create an object that has not yet been determined, thus simplifying the logical structure of the client application. and improves the readability and reusability of the code.

Take an animal factory to illustrate

Class Animal (object):  def eat (self, food):    raise Notimplementederror () class Dog (Animal):  def eat (self, Food):    print ' dog eat ', Foodclass Cat (Animal):  def eat (self, food):    print ' cat eat ', Foodclass animalfactory (object) :  def create_animal (self):    raise Notimplementederror () class dogfactory (animal):  def create_animal (self ):    return Dog () class Catfactory (animalfactory):  def create_animal (self):    return Cat () def client ():  animal_factory = dogfactory ()  animal = Animal_factory.create_animal ()  animal.eat (' Meat bones ')  Animal_factory = catfactory ()  animal = Animal_factory.create_animal ()  animal.eat (' Fish Bones ')

The following is the implementation of the Simple factory pattern:

Class Animal (object):  def eat (self, food):    raise Notimplementederror () class Dog (Animal):  def eat (self, Food):    print ' dog eat ', Foodclass Cat (Animal):  def eat (self, food):    print ' cat eat ', Fooddef create_animal (name):  if name = = ' dog ':    return Dog ()  elif name = = ' Cat ':    return Cat () def client ():  animal = Create_animal (' dog ')  Animal.eat (' Meat bones ')  animal = Create_animal (' cat ')  animal.eat (' Fish Bones ')

It seems that the factory method is a lot more complicated than the simple factory model, why should we use the factory method mode? The advantages of the simple factory model are obvious, the factory functions encapsulate logical judgments, and the client is much less burdensome to use. The corresponding problem is also obvious, in order to add a new product type, it is necessary to modify the factory function, which violates the opening and shutting principle. But the factory method pattern seems to go around a circle and back to the original era, the following is not written on it, why the outside set a layer of factory:

Class Animal (object):  def eat (self, food):    raise Notimplementederror () class Dog (Animal):  def eat (self , food):    print ' dog eat ', Foodclass Cat (Animal):  def eat (self, food):    print ' cat eat ', Fooddef client ():  dog = Dog ()  dog.eat (' Meat bone ')  cat = Cat ()  cat.eat (' Fish Bones ')

Factory method patterns are useful in organizing code for languages such as Java, C + +, which require strong type checking. For a dynamic language like Python, the feeling does not reflect much value, perhaps I have not yet understood the true meaning of the factory method pattern.

