The course opens by introducing the conceptual logic behind design patterns: what they are; what they are not; what makes a pattern; major pattern types; and what role they play in the bigger picture of Web development. We then dive straight into a real-world case study, building a mock application with in-built issues that design patterns can solve.
About The Author
Ben Fhala discovered his passion for data visualization while he was working at Parsons in New York, in their data visualization department, PIIM. He is the owner of the online video training school, 02geekcom, and an Adobe ACP. He enjoys spending most of his time learning and teaching, and has a love for visual programming and visualization in general. Ben has had the honor of developing applications for members of the US Congress, Prime Ministers, and Presidents around the world.
He has built many interactive experiences for companies such as Target, AT&T, Crayola, Marriott, Neutrogena, and Nokia. He has technically directed many award-winning projects and has been part of teams that have won three Agency of the Year awards.
This video will offer an overview of the course.
Before we can confront the actual problem at the global level, we need to first build the core application that is going to be used throughout this section. In this video, we are going to work to develop a pseudo chat application between a user and computer to see how design patterns rescue with application issues.
With over 11 global scope references, we have 11 possibilities to get our code overwritten by other code. Let’s condense our code into an object and move it into a unique namespace protecting it from mistaken overrides.
While the Module design pattern is very powerful, it has a few limitations and they are related mainly to the fact that we have to treat public and private members differently. Moreover, this split has made it hard for us to call and use the public members from the private areas of our code. The Module Reveal Pattern comes to our rescue to solve this issue.
Let’s now turn our attention to the global scope. Our goal in this video is to remove access altogether to the global scope and define and control how and who has access to our objects.
The Singleton design pattern restricts instantiation to a single instance and enables a delayed instantiation. This enables a public constant API to retrieve the instance while validating that only one instance of it can ever be created. This makes it easy to share the object with multiple objects.
An Abstract Factory, similar to a Factory, creates objects or instances of things that are not in it. The difference is that an abstract Factory doesn't refer directly to what kind of a Factory it is; instead, it refers to the implementation of an interface. This comes in handy when the actual objects that will be registered are vast.
The Builder design pattern is in many ways a continuation of the Abstract Factory design pattern. The Builder pattern enables us to create complex shapes that are split into steps. It also helps us merge more than one object with another to create the outcome that we need. Most of the time, you would start with a Factory, and as it grows old, you would move it into an Abstract Factory. If at this stage, it's logical to break it through to a Builder, you would move into one.
In this video, we will continue to implement the logic of our Builder into our Singleton. We can remove more layers of information out of our main construct, thus enabling us to implement drastic changes in the way we implement the content within.
Our goal is to make our Singleton abstract so it can be less aware of the items that it is controlling, thereby opening the doors for us to change the interface that will be used.
The Adapter design pattern enables us to switch logic bases very easily within an application. This is commonly used when we want to simplify interface usage or need to modify our code to fit an interface that already exists.
The Composite design pattern enables us to control multiple elements, which have the same public API, at the same time. This is very useful in situations when we need to control a large number of items and want to have them react together to an action
The Decorator enables us to add functionality to an existing object without creating a new inheritance chain or updating a prototype. The idea is to add functionality to items based on need instead of adding them to the object from the get-go. This can become very useful when you have multiple objects with partially shared functionality.
The Fly Weight design pattern is focused on memory optimization. Its goal is to reduce the size of objects and extract functionalities that aren't vital to the object into sub-objects that would enable these features based on needs only.
A Façade design pattern provides a simplified interface to a larger body of code, such as a class library or larger object. Facades come in handy when you want to minimize an API to protect some methods (or hide them from the end user/developer).
In the last video, we introduced the Façade design pattern, and in the process, we broke our application. In this video, we move things around and get our application to work again.
The Bridge design pattern is more or less the same as the Adapter design pattern with one exception. The Adapter design pattern is intended to be used when you can't change the original API, while the Bridge design pattern goes to the way the objects are built to have a shared API in advance.
The Chain design pattern enables us to connect objects to each other as if they were chains. Before we can implement this design pattern, we will need to update the logic of our core circle to enable it to store the next link in a chain.
Now that we have the logic needed to create chains, let’s implement the Chain design pattern.
The name Observer might not sound familiar, but you are probably working with it a lot. If you have ever worked with an event, you've been working with an implementation of the Observer. The Observer enables us to let an object update other objects for changes in its state without explicitly knowing who is listening to it.
In the previous video, we created an event dispatcher. In this video, we will add a functionality to remove events as well.
An application doesn't need to always be aware of its state. Awareness tends to add more complexity to an application (such as multiple conditions). By extracting the different states into separate implementations, all that is left for the application to do is update its state to change its functionality.
Packt has been committed to developer learning since 2004. A lot has changed in software since then - but Packt has remained responsive to these changes, continuing to look forward at the trends and tools defining the way we work and live. And how to put them to work.
With an extensive library of content - more than 4000 books and video courses -Packt's mission is to help developers stay relevant in a rapidly changing world. From new web frameworks and programming languages, to cutting edge data analytics, and DevOps, Packt takes software professionals in every field to what's important to them now.
From skills that will help you to develop and future proof your career to immediate solutions to every day tech challenges, Packt is a go-to resource to make you a better, smarter developer.
Packt Udemy courses continue this tradition, bringing you comprehensive yet concise video courses straight from the experts.