Course Overview
This course provides a comprehensive overview of Design Patterns in Go from a practical perspective. This course in particular covers patterns with the use of:
Course Overview
This course provides a comprehensive overview of Design Patterns in Go from a practical perspective. This course in particular covers patterns with the use of:
The latest versions of the Go programming language
Use of modern programming libraries and frameworks
Use of modern developer tools such as JetBrains GoLand
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 GoF book used C++ and Smalltalk for its examples, but, since then, design patterns have been adapted to every programming language imaginable: C#, Java, Swift, Python, JavaScript and now — Go.
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, Observer, State, Strategy, Template Method and Visitor
Who Is the Course For?
This course is for Go 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. For example, the use of the Composite pattern allows structures to be iterable and lets scalar objects masquerade as if they were collections.
Presentation Style
This course is presented as a (very large) series of live demonstrations being done in JetBrains GoLand and presented using the Kinetica rendering engine. Kinetica removes the visual clutter of the IDE, making you focus on code, which is rendered perfectly, whether you are watching the course on a big screen or a mobile phone.
Most demos are single-file, so you can download the file attached to the lesson and run it in GoLand, or another IDE of your choice (or just run them from the command-line).
This course does not use UML class diagrams; all of demos are done via live coding.
Welcome to the course!
An overview of the SOLID design principles.
A look at the Single Responsibility Principle that states that a type (package) should have a single primary responsibility. Also discussed principles of Separation of Concerns and the God Object antipattern.
A look at the Open-Closed Principle that states that types should be open for extension, but closed for modification.
This principle is not particularly applicable to Go, but you can still make it work... sort of.
The Interface Segregation Principle is simple: don't put too much into your interfaces.
The Dependency Inversion Principle is a rather convoluted way of saying that you should depend on abstractions rather than implementation details.
A summary of the things we've learned about the SOLID design principles.
An overview of the Builder design pattern.
Here we look at the builtin strings.Builder and construct our own HtmlBuilder.
Sometimes you need several builders to build up an object.
A look at how to coerce your users to use a Builder.
An alternative approach to implementing a Builder.
A summary of the things we've learned about the Builder design pattern.
An overview of the Factory design pattern.
Go doesn't have constructors, but factory functions are a close equivalent.
A factory function that yields an interface rather than a concrete struct.
Manufacturing preconfigured libraries and storing them as variables. Can be done with a functional approach (function returning function) or a structural approach.
A generalized factory that can produce prepackaged objects.
A summary of the things we've learned about the Factory design patterns.
An overview of the Prototype design pattern.
To implement Prototype, we need to master deep copying.
One approach to deep copying is to give your structs a method called DeepCopy().
Serialization makes deep copying easy!
Factory functions tailored to different prototypes make the Prototype pattern easy to use!
A summary of the things we've learned about the Prototype design pattern.
An overview of the much-maligned Singleton design pattern.
We implement a lazy, thread-safe singleton.
Direct dependencies on singletons are painful because they violate DIP and ruin testability.
Let's introduce abstractions and make our singleton more usable.
A summary of the Singleton design pattern. That wasn't so scary, was it?
An overview of the Adapter design pattern.
A real-life example of an adapter.
Adapters can generate temporary data so here's how to avoid it.
A summary of 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.
A demo of how the Composite pattern can be useful in a drawing application.
An implementation of Composite with neural networks.
A summary of the Composite design pattern.
An overview of the Decorator design pattern.
There's no 'multiple inheritance' in Go and multiple aggregation doesn't work that well, either.
A look at how to implement the Decorator pattern.
A summary of the Decorator design pattern.
An overview of the Façade design pattern.
A demo of how a Facade would be implemented.
A summary of the things we've learned about the Façade design pattern.
An overview of the Flyweight design pattern.
An implementation of the Flyweight design pattern in the context of a text editor application.
Users often have similar first/last names. Flyweight can help us optimize memory usage.
A summary of the things we've learned about the Flyweight design pattern.
An overview of the Proxy design pattern.
A proxy that guards access to a resource.
A proxy that masquerades for an object that might not even be there.
The differences between the Proxy and Decorator design patterns.
A summary of what we've learned about the Proxy design pattern.
An overview of the Chain of Responsibility design pattern.
A linked list of method invocations.
An important note before we implement an event broker.
A complicated CoR demo involving the Mediator and Observer design patterns as well as CQS.
A summary of the Chain of Responsibility design pattern.
An overview of the Command design pattern.
Let's implement the Command design pattern!
Commands can also be made undo-able.
A merger of the Command and Composite design patterns.
If you don't need to preserve information about the command for future reference, you can wrap command as functions in a function slice.
A summary of the things we've learned about the Command design pattern.
An overview of the Interpreter design pattern.
The first stage of interpretation is the lexing, which turns textual input into a sequence of tokens.
The second stage of interpretation is the parsing, which turns a sequence of tokens into an Abstract Syntax Tree (AST).
A summary of the things we've learned about the Interpreter design pattern.
An overview of the Iterator design pattern.
A look at the different ways structures can be made iterable.
An example iterator for tree traversal.
An overview of the Mediator design pattern.
Let's code the classic Mediator demo: a chat room!
A summary of the Mediator design pattern.
An overview of the Memento design pattern.
OpenCourser helps millions of learners each year. People visit us to learn workspace skills, ace their exams, and nurture their curiosity.
Our extensive catalog contains over 50,000 courses and twice as many books. Browse by search, by topic, or even by career interests. We'll match you to the right resources quickly.
Find this site helpful? Tell a friend about us.
We're supported by our community of learners. When you purchase or subscribe to courses and programs or purchase books, we may earn a commission from our partners.
Your purchases help us maintain our catalog and keep our servers humming without ads.
Thank you for supporting OpenCourser.