Design Patterns in Python

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.

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.

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.

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.