OpenCourser
Learn skills that shape your future
Visit OpenCourser.com
Course Overview
This course provides a comprehensive overview of Design Patterns in JavaScript from a practical perspective. This course in particular covers patterns with the use of:
The latest versions of the JavaScript programming language
Use of modern programming libraries and frameworks
Use of modern developer tools such as JetBrains WebStorm
Discussions of pattern variations and alternative approaches
Course Overview
This course provides a comprehensive overview of Design Patterns in JavaScript from a practical perspective. This course in particular covers patterns with the use of:
The latest versions of the JavaScript programming language
Use of modern programming libraries and frameworks
Use of modern developer tools such as JetBrains WebStorm
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 and now — 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, Observer, State, Strategy, Template Method and Visitor
Who Is the Course For?
This course is for JavaScript 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 Symbol.iterator allows objects (including iterator objects) 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 WebStorm 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 WebStorm, Atom 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.
A look at what we're going to learn in this course.
Your first lecture is outside of a section. Create a section to hold this lecture. — umm, no, no I won't.
Some info about JavaScript, Node.js, Jasmine and WebStorm — the things used to present this course.
An overview of the SOLID design principles.
SRP: a class should have one reason to change.
OCP: classes should be open for extension, but closed for modification.
LSP: if a function or method takes a parent type, it should be able to take a derived type and continue working properly.
ISP: don't put too much into interfaces. Then again, JS doesn't have interfaces.
DIP: high-level modules should not depend on low-level modules; they should instead depend on abstractions.
A summary of the things we've learned about SOLID. Admittedly, some of them are less applicable to JavaScript than others.
A brief note about the three categories of design patterns: creational, structural and behavioral.
An overview of the Builder design pattern.
A look at the implementation of the Builder pattern.
Multiple builders working together.
A summary of the things we've learned about the Builder design pattern.
An overview of the Factory design pattern.
We look at why a factory method can be more convenient than a constructor.
If we move all the factory methods into a separate class, we get... a factory!
Hierarchies of types can have corresponding hierarchies of factories. And yes, JS doesn't have 'abstract' classes.
A summary of the things we've learned about the Factory design pattern.
An overview of the Prototype design pattern.
The most direct way of cloning objects is to do it manually. But does it scale?
Serializers help us write entire object graphs to a string. So a serialize-deserialize cycle lets us fully clone an object including all its members.
A factory that makes it convenient to reuse prototypes.
A summary of all that we've learned about the Prototype design pattern.
An overview of the Singleton design pattern.
A basic implementation of Stringleton that basically gets the constructor to return one instance on each call.
A weird (and not very practical) implementation of Monostate that lets you make multiple instances but they all share the same data.
A look at why the Singleton is so hated and how these problems can be overcome.
A summary of the things we've learned about the Singleton design pattern.
An overview of the Adapter design pattern.
Let's build an adapter for a (somewhat contrived) scenario!
Some adapter generates temporary objects. Let's see how we can avoid extra work using caching.
A summary of what we've learned about the Adapter design pattern.
An overview of the Bridge design pattern.
Let's go build a Bridge!
A summary of the things we've learned about the Bridge design pattern.
An overview of the Composite design pattern.
Grouping geometric shapes is something you'd do in a drawing app. Let's implement this and get the Composite pattern in it, too!
Instead of using a base class, let's see if we can get scalars to behave as collections.
A summary of what we've learned about the Composite design pattern.
An overview of the Decorator design pattern.
Let's build a Decorator!
A summary of the things we've learned about the Decorator design pattern.
An overview of the Façade design pattern. And yes, an explanation of the letter ç.
We build a simple Facade that represents a console (terminal) window.
A summary of the things we've learned about the Façade design pattern.
An overview of the Flyweight design pattern.
Let's implement text formatting without too much data duplication.
Any multi-user online system stores people's names. Can we store them efficiently?
A summary of the things we've learned about the Flyweight design pattern.
An overview of the Proxy design pattern.
The simplest kind of proxy is a proxy for a primitive value. But why would you want this?
Properties are neat, but sometimes you want entire classes to serve as backing fields.
A protection proxy controls access to a component.
A virtual proxy can present itself as a resource even when the resource is not yet available.
A summary of the things we've learned about the Proxy design pattern.
Overview of the CoR design pattern.
The simplest CoR implementation is a singly linked list of methods.
A note about CQS and, specifically, the idea of treating Queries as Commands.
An advanced CoR/Observer/Mediator implementation of an Event Broker.
Summary of the CoR design pattern.
An overview of the Command design pattern.
Let's implement Commands!
We implement Undo functionality with Commands.
Summarizing the Command design pattern.
An overview of the Interpreter design pattern.
The first stage of interpretation is the separation of the input into separate lexical tokens. Also known as 'lexing'.
Second part of interpretation is 'parsing', turning a sequence of tokens into some parseable object-oriented structure.
Summary of what we've learned about the Interpreter design pattern.
Save
Covers a wide range of design patterns.
Effective use of live coding demonstrations.
Instructor explains complex concepts clearly.
Focuses on practical application with modern JS.
SaveOpenCourser 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.
