Package: design-pattern-toolkit
Design Pattern Tool KitA collection of design patterns implemented in Python programming languageThe design pattern tool kit is aimed at achieving quick and efficient application on tested design patterns.
Furthermore, the tool kit will enable development with a minimal need for refactoring code baseProject status:PrototypeInstallationThe application can be installed by cloning the repository:https://gitlab.com/frier17/toolkit. Future development may be made available
through the PiPy directory.UsageUse the toolkit to build application with features fitting the design pattern as described below.Command: This pattern is useful for managing request of classes in a manner in which commands are passed as
standalone objects. These object can be stored in structures such as list or dictionary. Furthermore, commands can
be prioritized or called when certain conditions are satisfied.Use the command pattern when:an application or system needs to pass method calls as objects. In Python this can be easily implementing the__call__function or passing functions as parametersyou want to implement commands that can be stored and later called or are reversible. Example executing an
"undo" command.a robust execution model is required, that is, method invocation can be treated as objects and more organized
in executionMediator: This pattern is used where a collection of components or classes working together are not closely
coupled and do not directly communicate with each other. This pattern is best used where:classes working together should not be tightly coupledclasses are to be reused but cannot be adapted without the need to create subclasses in order to customise them
for target systemwhere so many subclasses will be needed to simply use basic features but cannot because of tight couplingMementos: The mementos pattern is suitable for capturing the state of object or system (as snapshots) in a manner
in which the state can be restored without associated classes being aware of the internal structure of the object
. The stored state can only be accessed by clearly defined interfaces. The captured state can only be modified
, viewed and accessed by the source class (originator) which was captured.Observer: The observer pattern is suitable where multiple classes may need to update their state or perform a
function when a given event or object is changed.Chain of Responsibility: The chain of responsibility resembles the State and Strategy pattern.
All three design patterns are focused on changing the behaviour of the object but differ in the manner in which they
achieve their goal.
The State pattern changes behaviour by delegating to a state object which can change the observed object's state at
will and have knowledge of the approved system state transition or sibling states. The strategy pattern is also
achieved via composition. Desired behaviours are delegated to concrete strategy objects which cannot change the
object state or may not be aware of other sibling strategies. The CoR is also based on composition.
In this scenario, a task is accomplished by passing it along a linked number of handlers.
Each handler may handle the given task, component of the task, or simply pass the task to the next handler till the
entire task is accomplished.State: The state design pattern is useful where an object needs to change its behaviour based on its current state
. The state can be measured by some set values or external object.
Implementing a state pattern requires abstracting the behaviour of the class when a given state is reached into
concrete object which implements a state interface. A context class is then used to retain other attributes and
behaviour of the desired class. This context object will have accessor/mutator to the state object enabling the
class to change its states through a defined protocol. In most practical cases, transition in state is well
defined and each state object may be implemented in a manner in which they can determine the allowable state(s
) they can be changed to. Considering Python a programming language which has functions as first class objects
, alternative mechanism can be adopted to reach similar goal. For instance, behaviour can be captured as
functions or methods. The required context information can be passed as parameters to these functions. Also
, since functions can be passed as parameters, various states can be mapped to respective functions thereby
making it possible to simply have a context class and respective state behaviours which can be called directly
within the context without need for extra state interface or concrete implementationSingleton: The singleton pattern is a creation pattern. This pattern is suitable where only one copy or instance
of a given class is needed. In Python this can be achieved using metaclasses.Factory, AbstractFactory, Prototype Design Pattern: The three creation pattern while different in their approach
share a common factor: they are tailored to creating objects while delegating the detail implementation to children
classes or composite class with sole responsibility of making copies or creating instances. From this view point
, and considering the nature of the Python language, the following deductions can be reached:Factory, AbstractFactory, and Builder design pattern delegate creation to subclasses. The concrete implementation
then
relies on the class constructor to create/instantiate a class. Python uses a different approach from a number of
OOP languages. All objects in Python are subclasses oftype. Furthermore, thetypeclass is a callable (can
be called as a function) hence objects can be created not only through their concrete class implementation but
also through a general/central mechanism viatype. The need for having pletheora of subclassses is then
removed. Added to this, the__new__and__init__functions work together to create any object when using
the
conventional class call: that is,a = ClassA(). The instance created in__new__is passed to the__init__function for initialization. Both function behaviour is fully captured when usingtypeas members and
parent classes can be passed to thetype. The major drawback with usingtypeis that dynamic
attribute access cannot be restricted as in the case where__slots__may be used in a class or
descriptors are defined. However, this is a negligible trade off. Based on this, wrapping calls totypewithin a Factory class method makes for more efficient and pythonic means of generating various
types of objects.Prototype design pattern uses the approach of making copies or clones of objects which can then be modified
without affecting the original object. This approach is attained naturally in Python through the copy or pickle
mechanism. Python provides the nativecopyfunction which relies on the metaclass function or dunder methods
:__copy__and__deepcopy__. Depending on one's goals, either the shallow copy (__copy__) or the deep
copy(__deepcopy__) can be implemented in the source class which is used to make prototypes. Copies or clones
can then simply be made by calling the function, example:b = copy(object_a)or through thecopy.deepcopyandcopy.copymodules. Either ways, by simply wrapping the copying methods, prototypes can be made
without the overhead of creating a prototyping class or mechanism.
The design approach adopted in toolkit package is to have all four creation pattern embedded in a base Factory
class. This class will provide access to producing objects using class methods. For efficiency, already created
classes can be registered in a cache-like dictionary object of factory. This will enable creating copies of
created classes rather than re-creating them. Also, since the goal of the factory patterns is tailored at
producing objects not defining classes, thetypefunction is used to create objects through theFactory.produce(*,bases=(), specification={})class method.