Python's abstract factory model of object-oriented programming--a more pythonic abstract factory

In the previous article, we talked about Diagramfactory and its svgdiagramfactory subclasses and the analogies they used, such as (Diagram,svgdiagram and so on), that were able to implement the functions of the reservation and also conform to the design pattern of the abstract factory.

However, our implementation is not very perfect, at least with the following deficiencies:

1) We do not need to save the state of each factory, so when passing parameters to Create_diagram, there is no need to pass the factory instance.

2) Svgdiagramfactory code is almost identical to diagramfactory, the only difference is that its return value is prefixed with the SVG prefix in text or rectangle, i.e. Svgtext svgrectangle, and so on.

3) All classes are saved in our top-level namespace: Diagramfactory, Digram, Rectangle, text, and all of the SVG-related classes. In fact, however, we really need only two factory classes that are called externally.

4) in order to avoid the conflict of class names, we have to add the SVG prefix in front of the name of the subclass, which in practice does not look neat. (Another solution to resolving class name collisions is to put each class inside of its own module, but this still doesn't solve the problem of code duplication).

This article focuses on solving the above four points problem.

The first change we have to make is to encapsulate the Diagram,rectangle and text classes into the Diagramfactory class. This means that these classes can only be accessed in a form similar to Diagramfactory.diagram. But now we can have the same name for these classes, because the class name conflict will no longer exist, such as Svgdiagramfactory.diagram. We also encapsulate some of the constants on which the class depends, all within the internal top-level name of the module: Main (), Create_diagram (), Diagramfactory, and Svgdiagramfactory.

Class Diagramfactory: @classmethod def make_diagram (class, Width, height): return class.diagram (width, height) @ Classmethod?def Make_rectangle (Class, x, y, width, height, fill= "white", stroke= "Black"):? return Class.rectangle (x, Y, width, height, fill, stroke) @classmethod def make_text (Class, x, y, text, fontsize=12): Return Class.text (x, y, text, fon Tsize) ...

diagramfactory class. One of the make_ ... () The method is all class methods. That means, too. When called, the class is passed as the first argument to the function (just like self is passed to the normal class method). So, in this case, calling diagramfactory.make_text () means diagramfactory as class parameter is passed in, Thus a diagramfactory.text object is created and returned.

diagramfactory Svgdiagramfactory class, no longer need to implement make_ ... () The function of the . For example, when we call svgdiagramfactory.make_rectangle () This method, because svgdiagramfactory does not have this method, so it calls its base class Diagramfactoy.make_rectangle () method, but passed in class parameter is indeed svgdiagramfactory. Therefore, it causes svgdiagramfactory.rectangle object to be created and returned.

def main (): ... txtdiagram = Create_diagram (diagramfactory) txtdiagram.save (textfilename) Svgdiagram = Create_di Agram (svgdiagramfactory) svgdiagram.save (svgfilename)

These changes also mean that we can simplify the design of the main () function because we no longer have to create an instance of the factory factory.

The rest of the code is basically the same as before. The obvious difference is that because we encapsulate both constants and non-factory classes in the factory class code, we now have to use the factory name to access them.

Class Svgdiagramfactory (diagramfactory): ... class text:def __init__ (self, x, y, Text, FontSize): x *= svgdiagramfactory. Svg_scale?y *= svgdiagramfactory.svg_scale fontsize *= svgdiagramfactory.svg_scale//10?self.svg = SvgDiagramFactory.SVG_TEXT.format (**locals ())

This is the Text class in the code encapsulated into the Svgdiagramfactory class, demonstrating how the encapsulated constants are accessed.

Well, this is the further optimization of the abstract factory code, we will also be involved in other design patterns later, please look forward to!

Python's abstract factory model of object-oriented programming--a more pythonic abstract factory