- 3.5 hours on-demand video
- 1 downloadable resource
- Full lifetime access
- Access on mobile and TV
- Certificate of Completion
Get your team access to 4,000+ top Udemy courses anytime, anywhere.Try Udemy for Business
- Understand how to modularize and condense code, optimize memory, and negotiate design problems
- Explore Creational design patterns including the Singleton, Factory, and Prototype
- Implement greater abstraction into application design, and control multiple objects sharing APIs with the help of Structural design patterns
- Chain objects together and manage events and states using Behavioural design patterns
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.
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.
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.
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 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.
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.
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.
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.
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.