Design Patterns in Python

An overview of the Design Patterns in Python course.

What are SOLID principles, where do they come from and why do we care?

A look at the Single Responsibility Principle, which states that a class should only have one reason to change. Also tied to the concept of Separation of Concerns which is basically stating the same thing.

A discussion of the Open-Closed Principle, which states that classes should be open for extension, but closed for modification. In other words, you should extend functionality using interfaces and inheritance rather than jumping back into already-written/tested code and adding to it or changing it.

The Liskov Substitution Principle states that subtypes should be substitutable for their base types.

The Interface Segregation Principle is simple: don't throw everything in the kitchen sink into an interface because then all its users will have to implement things they do not need. Instead, split the interface into several smaller ones.

Not to be confused with dependency injection, dependency inversion specifies that high-level modules should not depend on low-level ones; both should depend on abstractions. Confusing, huh?

A summary of the things we've learned in this section of the course.

A brief note about the three categories of design patterns: creational, structural and behavioral.

An overview of the Builder design pattern.

An overview of the Builder design pattern.

A look at how several builders can work together through a common fluent interface.

Addendum: there's a small mistake in the PersonBuilder initializer; instead of =Person() it should read =None, see the attached source code for the updated example.

How to combine the functionality of several builders without breaking OCP.

A summary of the things we've learned about the Builder design pattern.

An overview of the Factory design pattern.

A constructor is a rather limited tool. A factory method adds flexibility.

A factory is a separate class for creating objects.

If you have a hierarchy of objects, you can have a corresponding hierarchy of factories.

A summary of the things we've learned about the Factory design pattern.

An overview of the Prototype design pattern.

Learn about deep copying and the Prototype pattern.

Well known prototypes can be put into a factory for additional convenience.

A summary of all the things we've learned about the Prototype design pattern.

An overview of the much-maligned Singleton design pattern.

You can make an allocator that keeps returning the same object. Trouble is, the initializer still gets called more than once!

Let's implement the Singleton as a decorator!

Note: if you don't know how Python decorators work, see the Decorator pattern lectures.

Let's implement the Singleton using a metaclass!

A peculiar variation on the 'canonical' singleton, Monostate objects all share the same static dictionary.

Why is the Singleton problematic? What can we do to fix it?

A summary of the things we've learned about the Singleton design pattern.

An overview of the Adapter design pattern.

Let's implement the adapter pattern — perhaps not in the most efficient manner.

Let's improve our Adapter implementation with some caching!

A summary of what we've learned about the Adapter design pattern.

An overview of the Bridge design pattern.

Let's implement the Bridge design pattern!

A summary of the things we've learned about the Bridge design pattern.

An overview of the Composite design pattern.

Note: for more information on iteration, please consult the Iterator pattern lectures.

First, a simple example: grouping geometric shapes.

Implementing connections between neurons and neuron layers with the Composite pattern.

A summary of the things we've learned about the Composite design pattern.

An overview of the Decorator design pattern.

To some extent, the Decorator pattern is built right into the Python language. Let's take a look at how Python's functional decorators work.

A classic GoF decorator is a class that gives additional functionality to the underlying class. The only problem is the original class' attributes are now inaccessible.

A dynamic decorator lets us treat the decorator as if it were the object it decorates. This works for purposes of ordinary programming, but won't work with any sort of metaprogramming.

A summary of the things we've learned about the Decorator design pattern.

An overview of the Façade design pattern.

An illustration of what a typical Facade looks like.

A summary of the things we've learned about the Façade design pattern.

An overview of the Flyweight design pattern.

Many online games store actual user names. But is it worth storing every first-last name pair individually?

We want to apply formatting to plain text. What's the most memory-efficient way of doing this?

A summary of the things we've learned about the Flyweight design pattern.

An overview of the Proxy design pattern.

A protection proxy can be used to add access control to a resource.

A virtual proxy can masquerade as a real object even when the object has not yet been materialized.

Proxy and Decorator look like similar patterns. So what's the difference?

A summary of the things we've learned about the Proxy design patterns.

An overview of the Chain of Responsibility design pattern.

A chain of responsibility implemented as a linked list of function references.

Our next example uses queries, so now is a good time to mention CQS, another concept closely related to design patterns.

A more sophisticated Chain of Responsibility implementation! An event broker is a centralized component that can process queries by letting all subscribers handle and possibly modify them.

A summary of the things we've learned about the Chain of Responsibility design pattern.

An overview of the Command design pattern.

Let's implement the Command design pattern and also support Undo operations.

A Composite Command (a.k.a. a Macro) is a merger of the Composite and Command design patterns. Let's see how they play together.

A summary of the things we've learned about the Command design pattern.