Metadata-Version: 2.2
Name: design_pattern_toolkit
Version: 1.0a2
Summary: Collection of design patterns implemented in Python
Home-page: https://gitlab.com/frier17/toolkit.git
Author: https://gitlab.com/frier17/
Author-email: frier17@a17s.co.uk
License: MIT
Classifier: Development Status :: 3 - Alpha
Classifier: Intended Audience :: Developers
Classifier: Topic :: Software Development :: Build Tools
Classifier: License :: OSI Approved :: MIT License
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.7
Description-Content-Type: text/markdown
Dynamic: author
Dynamic: author-email
Dynamic: classifier
Dynamic: description
Dynamic: description-content-type
Dynamic: home-page
Dynamic: license
Dynamic: summary

# Design Pattern Tool Kit
**A collection of design patterns implemented in Python programming language**

The 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 base 

## Project status: 
Prototype

## Installation
The application can be installed by cloning the repository: 
[https://gitlab.com/frier17/toolkit](https://gitlab.com/frier17/toolkit). Future development may be made available
 through the PiPy directory.

## Usage
Use the toolkit to build application with features fitting the design pattern as described below.

1. 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 parameters
    + you 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 execution

2. Mediator: 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 coupled
    + classes are to be reused but cannot be adapted without the need to create subclasses in order to customise them
     for target system
    + where so many subclasses will be needed to simply use basic features but cannot because of tight coupling

3. Mementos: 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.

4. 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. 

5. 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.

6. 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 implementation

7. Singleton: 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.

8. 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 of `type`. Furthermore, the `type` class 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 via `type`. 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 using `type` as members and
            parent classes can be passed to the `type`. The major drawback with using `type` is 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 to
               `type` within 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 native `copy` function 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 the `copy.deepcopy
        ` and `copy.copy` modules. 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, the `type` function is used to create objects through the 
       `Factory.produce(*,bases=(), specification={})` class method. 
