Design Patterns in Swift

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 a protocol because then all its users will have to implement things they do not need. Instead, split the protocol 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 discussion of the Builder pattern and what it's used for.

A look at why you'd want to have a builder in the first place.

We implement a simple builder for constructing trees of HTML elements.

We make the builder fluent by returning self from builder methods.

We look at a more complicated builder facade that exposes several sub-builders (builder facets) for building up parts of an object in a fluent manner.

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

A discussion of the general concept of factories and the two design patterns: Factory Methods and Abstract Factory.

A scenario where having a factory interface actually makes sense.

Implementing a factory method, as an alternative to an initializer, is easy.

When you want all the factory methods in a separate class.

An external factory needs the created object's constructor to be public. But what if you want it to be private? The solution is simple: stick a factory into the class whose instance it creates!

Sometimes, you want abstract factories with abstract objects; we support DIP but break OCP in the process.

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

A discussion of the Prototype factory (not to be confused with a rather good game of the same name) and what it's used for.

A copying approach straight from the land of C++.

What do you think about the idea of simply defining a protocol for deep-copyable reference types? Sounds like a simple idea, but we're going to encounter a problem with casting the result of out own initializer to Self. Don't worry, there is a fix for this.

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

Ahh, the much maligned Singleton? Is it really that evil? Let's find out...

Avoiding all the philosophical nonsense surrounding double-checked locking (it’s not thread-safe) and implementations involving inner static classes, we simply look at the safest possible singleton. But just because it's safe doesn't mean it's useful.

The singleton works fine, so what's the problem? Turns out, hard reference to a type means we cannot fake it in our tests. Oops!

The only socially acceptable way of using a singleton is with a DI framework. 
Typically, marking a component as a singleton is trivial.

A variation on a Singleton pattern, the Monostate lets the client instantiate as many copies of the singleton class as they want, but all those copies refer to the same static data. Is this a good idea? Let’s find out!

A summary of all that we've learned about the Singleton. As you can see, it's not really that evil provided it can be substituted by a different type (polymorphism). Also, lifetime management is best left to a specialized system (i.e. a DI container).

A look at the Adapter design pattern.

We are going to build a simple adapter for the rending of vector data where only a raster renderer is available. 

An adapter can generate a large number of temporary objects. Caching helps us avoid doing extra work more than once.

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

A discussion of the Bridge pattern and what it's used for.

A simple illustration of how to build a bridge.

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

A discussion of what the Composite pattern is for and how it's used.

Let's implement the Composite pattern by considering individual geometric shapes as well as grouping of shapes.

Let's apply the Composite pattern to the implementation of simple neural networks (individual neurons and layers of neurons).

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

A look at the Decorator design pattern.

Building strings is a common concern. Let's see how we can have its de facto inheritor as a Decorator.

When you implement pseudo-multiple inheritance using interfaces, you quite often end up implementing the Decorator pattern.

A look at how to make decorators-of-decorators.

Can decorators be composed as nested generic type arguments? They can, but things aren't as rosy in Swift as they are in C++.

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

A look at the Façade design pattern. Also an explanation of that weird letter Ç.

An illustration of what a typical Facade looks like.

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

A discussion of the Flyweight design pattern and what it's used for.

An example of string space optimization when storing users' names.

Text formatting is a classic example of a Fliweight. Instead of keeping formatting flags for every single character in a line of text, let's implement ranges!

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

A look at the Proxy design pattern.

Let's implement a proxy which adds access control to the object.

One very common scenario is where developers replace ordinary properties with Property<T>-typed objects. Let's build out own implementation and discuss what it's for.

A comparison of the Proxy and Decorator design patterns.

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

A look at the Chain of Responsibility design pattern and discussion of what it's used for.

Brief discussion of the concept of Command Query Separation (CQS).

Chain of Responsibility implemented by chaining method calls together.

A more sophisticated approach to implementing the chain of responsibility.

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

A look at the Command design pattern.

Let's implement the Command design pattern in a simple scenario.

A simple demonstration of how to implement Undo functionality while using Command.

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

An overview of the Interpreter design pattern, which actually brings with it a whole field of Computer Science typically called Compiler Theory.

Lexing is the process of splitting textual input into lexical tokens.

Parsing is the process of converting a series of tokens into an Abstract Syntax Tree (AST).