Chapter 7. Design Patterns in Python

Design patterns simplify building software by reusing successful designs and architectures. Patterns build on the collective experience of software engineers and architects. When faced with a problem that needs new code to be written, an experienced software architect tends to make use of the rich ecosystem of available design/architecture patterns.

Patterns evolve when a specific design proves successful in solving certain classes of problem repeatedly. When experts find that a specific design or architecture helps them to solve classes of related problems consistently, they tend to apply it more and more, codifying the structure of the solution into a pattern.

Python (given that it's a language which supports dynamic types and high-level object oriented structures such as classes and metaclasses, first-class functions, co-routines, callable objects, and so on) is a very rich playground for constructing reusable design and architecture patterns. In fact, as opposed to languages such as C++ or Java, you often find there are multiple ways of implementing a specific design pattern in Python. Also, more often than not, you find that the Pythonic way of implementing a pattern is more intuitive and illustrative than, say, copying a standard implementation from C++/Java into Python.

This chapter's focus is mostly on this latter aspect—illustrating how one can build design patterns which are more Pythonic than those in the usual books and literature on this topic. It doesn't aim to be a comprehensive guide to design patterns, though we would be covering most of the usual aspects as we head into the content.

The topics we plan to cover in this chapter are as follows:

  • Design patterns elements
  • Categories of design patterns
  • Pluggable hashing algorithms
  • Summing up pluggable hashing algorithms
  • Patterns in Python – Creational
    • The Singleton pattern
    • The Borg pattern
    • The Factory pattern
    • The Prototype pattern
    • The Builder pattern
  • Patterns in Python – Structural
    • The Adapter pattern
    • The Facade pattern
    • The Proxy pattern
  • Patterns in Python – Behavioral
    • The Iterator pattern
    • The Observer pattern
    • The State pattern

Design patterns – elements

A design pattern attempts to record those aspects of a recurring design in object-oriented systems that solve a problem or a class of problems.

When we inspect design patterns, we find that almost all of them have the following elements:

  • Name: A well-known handle or title, which is commonly used to describe the pattern. Having standard names for design patterns aids communication and increases our design vocabulary.
  • Context: This is the situation in which the problem arises. A context can be generic such as Develop a web application software, or specific such as Implementing resource-change notification in a shared memory implementation of the publisher-subscriber system.
  • Problem: Describes the actual problem that the pattern is applied to. A problem can be described in terms of its forces, which are as follows:
    • Requirements: The requirements that the solution should fulfill, for example, the publisher-subscriber pattern implementation must support HTTP.
    • Constraints: The constraints to the solution, if any, for example, the Scalable peer-to-peer publisher pattern should not exchange more than three messages for publishing a notification.
    • Properties: The properties of the solution which are desirable to have, for example, The solution should work equally well on the Windows and Linux platforms.
  • Solution: Shows the actual solution to the problem. It describes the structure and responsibilities, the static relationships, and the runtime interactions (collaborations) of the elements making up the solution. A solution should also discuss which forces of the problem it solves and doesn't solve. A solution should also try to mention its consequences, that is, the results and trade-offs of applying a pattern.

Note

A design pattern solution almost never resolves all the forces of the problem leading to it, but leaves some of them open to related or alternate implementations.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.118.226.66