Design Patterns in Swift
4.7 (6 ratings)
Instead of using a simple lifetime average, Udemy calculates a course's star rating by considering a number of different factors such as the number of ratings, the age of ratings, and the likelihood of fraudulent ratings.
147 students enrolled
Wishlisted Wishlist

Please confirm that you want to add Design Patterns in Swift to your Wishlist.

Add to Wishlist

Design Patterns in Swift

Discover the modern implementation of design patterns with Swift
Best Seller
4.7 (6 ratings)
Instead of using a simple lifetime average, Udemy calculates a course's star rating by considering a number of different factors such as the number of ratings, the age of ratings, and the likelihood of fraudulent ratings.
147 students enrolled
Created by Dmitri Nesteruk
Last updated 8/2017
Current price: $10 Original price: $100 Discount: 90% off
5 hours left at this price!
30-Day Money-Back Guarantee
  • 8.5 hours on-demand video
  • 1 Article
  • 69 Supplemental Resources
  • 23 Coding exercises
  • Full lifetime access
  • Access on mobile and TV
  • Certificate of Completion
What Will I Learn?
  • Recognize and apply design patterns
  • Refactor existing designs to use design patterns
  • Reason about applicability and usability of design patterns
  • Implement each pattern in a coding exercise
View Curriculum
  • Good understanding of Swift
  • Familiarity with latest Swift features
  • Good understanding of object-oriented design principles

Course Overview

This course provides a comprehensive overview of Design Patterns in Swift from a practical perspective. This course in particular covers patterns with the use of:

  • The latest versions of the Swift programming language
  • Use of modern programming approaches: dependency injection, reactive programming and more
  • Use of modern developer tools
  • Discussions of pattern variations and alternative approaches

This course provides an overview of all the Gang of Four (GoF) design patterns as outlined in their seminal book, together with modern-day variations, adjustments, discussions of intrinsic use of patterns in the language.

What are Design Patterns?

Design Patterns are reusable solutions to common programming problems. They were popularized with the 1994 book Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, John Vlissides, Ralph Johnson and Richard Helm (who are commonly known as a Gang of Four, hence the GoF acronym).

The original book was written using C++ and Smalltalk as examples, but since then, design patterns have been adapted to every programming language imaginable: Swift, C#, Java, PHP and even programming languages that aren't strictly object-oriented, such as JavaScript.

The appeal of design patterns is immortal: we see them in libraries, some of them are intrinsic in programming languages, and you probably use them on a daily basis even if you don't realize they are there.

What Patterns Does This Course Cover?

This course covers all the GoF design patterns. In fact, here's the full list of what is covered:

  • SOLID Design Principles: Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle and Dependency Inversion Principle
  • Creational Design Patterns: Builder, Factories (Factory Method and Abstract Factory), Prototype and Singleton
  • Structrural Design Patterns: Adapter, Bridge, Composite, Decorator, Façade, Flyweight and Proxy
  • Behavioral Design Patterns: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Null Object, Observer, State, Strategy, Template Method and Visitor

Who Is the Course For?

This course is for Swift developers who want to see not just textbook examples of design patterns, but also the different variations and tricks that can be applied to implement design patterns in a modern way.

Presentation Style

This course is presented as a (very large) series of live demonstrations. All demos are single-file, so you can download the file attached to the lesson and run it in CLion, XCode or another IDE of your choice (or just on the command line).

This course does not use UML class diagrams; all of demos are live coding. I use Visual Studio Code for the demos.

Who is the target audience?
  • Beginner and experienced developers
  • Anyone interested in design patterns
Compare to Other Design Pattern Courses
Curriculum For This Course
113 Lectures
1 Lecture 05:35

A taste of things to come...

Preview 05:35
SOLID Design Principles
7 Lectures 57:11

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.

Single Responsibility Principle

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.

Open-Closed Principle

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

Liskov Substitution Principle

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.

Interface Segregation Principle

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?

Dependency Inversion Principle

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

6 Lectures 25:48

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.

Life Without Builder

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


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

Fluent Builder

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.

Preview 08:28

Builder Coding Exercise
1 question

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

7 Lectures 29:05

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.

Point Example

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

Factory Method

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!

Inner Factory

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

Abstract Factory

Factory Coding Exercise
1 question

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

4 Lectures 19:00

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

Copy Constructors

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.

Explicit Deep Copy Interface

Prototype Coding Exercise
1 question

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

6 Lectures 29:26

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.

Singleton Implementation

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!

Testability Issues

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

Singleton in Dependency Injection

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!


Singleton Coding Exercise
1 question

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

4 Lectures 19:26

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. 

Vector/Raster Demo

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

Adapter Caching

Adapter Coding Exercise
1 question

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

3 Lectures 09:26

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


A simple illustration of how to build a bridge.


Bridge Coding Exercise
1 question

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

4 Lectures 20:17

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.

Geometric Shapes

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

Neural Networks

Composite Coding Exercise
1 question

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

6 Lectures 23:24

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.

Custom String Builder

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

Multiple Inheritance

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

Dynamic Decorator Composition

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

Static Decorator Composition

Decorator Coding Exercise
1 question

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

16 More Sections
About the Instructor
Dmitri Nesteruk
4.6 Average rating
1,316 Reviews
12,119 Students
15 Courses
Quant Finance • Algotrading • Software/Hardware Engineering

Dmitri Nesteruk is a developer, speaker and podcaster. His interests lie in software development and integration practices in the areas of computation, quantitative finance and algorithmic trading. His technological interests include C#, F# and C++ programming as well high-performance computing using technologies such as CUDA. He has been a C# MVP since 2009.

Dmitri is a graduate of University of Southampton (B.Sc. Computer Science) where he currently holds a position as a Visiting Researcher. He is also an instructor on an online intro-level Quantitative Finance course, and has also made online video courses on CUDA, MATLAB, D, the Boost libraries and other topics.