hey my name is Forest welcome back in today's video you're going to learn about seven different software design patterns many of which you already use whether you realize it or not because simply put there solutions to Common programming problems that appear over and over and over and over regardless of what language or platform you're using it's not complicated it's just a matter of knowing them so you can understand when to use them and to actually use them because they are common practice for a reason because they're good back in 1994 these four developers known as
the gang of four wrote this book they documented cataloged and formalized 23 commonly used design patterns so i' highly recommend reading that book reading all the way through it because all of those are heavily applicable today we're not going to go over all 23 but I must note that all 23 do fall into three buckets creational patterns are all about object creation so instead of creating objects directly these patterns give you more flexibility on how objects come into existence structural patterns it's a second in category deal with how objects relate to each other think of
them as blueprints for building something building larger structures from Individual pieces like Legos so creational patterns object creation structural patterns the structure of how they relate to each other in the third category behavioral patterns which handle communication between objects how they interact and distribute responsibilities which includes the greatest pattern of all time the strategy pattern just just always use a strategy pattern if you take anything nothing from this video take that but let's dive deeper into these three creational patterns starting with the Singleton pattern everyone hates it until they need it think of the Singleton
pattern as your apps logging system when errors happen across your app which we all know will happen since you're the one coding it you want one Central logger handling everything using consistent formatting and and writing to the same file or service you don't want you don't want different loggers in interfering with each other for example this is where you have multiple loggers and creating chaos logger one new logger logger two new logger which is another logger writing to the same file the single T pattern you have a single logger that everyone uses and you get
the instance from said logger logger one logger two one logger get instance of that logger stored in logger you'll want to use the Singleton pattern when you absolutely need a single instance that's accessible globally like a database connection pool or the logger but it does have some trade-offs the good is that you get guaranteed single instance and Global access the bad is that well it's a bit of a nightmare to test and that's because you can't easily mock it you can mock it but you can't easily mock it and if you want to call that
a skill issue by all means try it yourself then get back to me and tell me how it went but also in multi-threaded environments you need special handling to prevent creating multiple instances but if you want me to really scare you I'm going to I'm going to use this analogy a Singleton is basically just a global a glorified Global variable yeah think about that for a second makes me nervous just thinking about it but I'm not trying to scare you it's not all bad or anything like that it's like a using a hammer to solve
your problems sure it works great on nails but not everything is a nail that's that's the thing just use it when you genuinely need single instance guarantee not when you just want a global state next up is the Builder pattern never tried to create something that has like 15 different optional parameters just me no all right anyway you can think of the Builder pattern as uh well think about creating a complex API request you've got headers query prams body data data data timeout settings rry logic trying to do all of that in a single Construction
will look something like this as you can see new HTTP requests and we're just throwing in API example.com post and all of this based on our HTTP request class like this however the beauty of the Builder pattern is that you can chain methods in any order you can skip the optional ones and your code actually reads like English check this out so here's our class request Builder which starts off similar to our HTTP request URL string method string headers record string string however here we're assigning it an initial value in the below we have all
of our methods as you can see and our Constructor results in a beautiful Builder P pattern as such and what's great about this is that if you want to add any new options later you just have to add a method to the class no need to go through and update every single place you're creating an object you want to use a builder pattern every time you're staring at a Constructor that has more parameters than you have fingers or when you need to construct object step by step like cooking you don't just throw all the ingredients
in at once you follow a recipe step by step the downside is you end up writing more code up front that is but trust me your future self and all of your teammates will than you when they can actually understand what in the world's going on and can create objects without you know playing the game oh I wonder what this parameter does next is the factory pattern you know how an object-oriented programming like my beloved Java we're always creating objects with new this and new that as you've seen here well the factory pattern says hold
up let me handle that for you think about creating different types of users in your app you got admins you got regular users you got moderators here's what that could look like without a factory yeah not the cleanest thing under the sun if type admin user create new admin or type moderator user new moderator or else user new regular user but if we were to follow the factory pattern boom that's it that's it we use user Factory we create an admin id1 Nam John as you can see up here and then the type is thrown
into a switch statement so all of that messy Logic the object creation logic is hidden in the factory class and all we have to do to create a new user is this it's just like when you're driving down the road and you look at a factory oh that's a that's a car plant you know that cars pop out of there but you don't see all of the intricacies and complexity and this and that of what's going on inside the factory because you don't need to know any of that or at least you don't need to
focus on that every single time you see a car come out of there so just like with the code you have you have the macro idea of what's being popped out instead of worrying about all of the logic every single time you need to create a new user and then for us if we want to change how an ad is created just update the factory need to add logging every time a moderator is created update the factory want to start pulling and reusing user objects update the factory you want to use factories every single time
you see yourself using that new keyword all over your code base the downside of a factory is that you're adding another layer of abstraction but is that really a bad thing I don't think so the real downside in my opinion is that there annoyingly coupled H they are very dependent on the factory class but the flexibility you get in return overall it it's worth the trade-off for sure and your code becomes way more maintainable because all of the creation logic is in the same place in that factory class it manages the complexity just like twin
gate manages the complexity of dealing with vpms for accessing development environments and internal tools and just to be clear twin gate the sponsor of this portion of today's video is not a a VPN it's a modern replacement if you will here's the difference instead of exposing your services to the public internet or dealing with slow VPN connections twin gate creates secure direct connections to exactly what you need when you're working remotely as a developer that could be your staging environment internal tools Cloud resources whatever you get instant access with Incredible performance while everything stays completely
PR you can manage everything as code with their terraform provider it has a kubernetes operator for service deployment and the setup is remarkably simple in short twin gate allows developers to securely access work resources remotely via zero trust network access with the Speed and Performance you need for development work this means that you can easily control exactly who has access to what which is perfect for development teams want to learn more and try it out well click the link in the description and see how twin gate can transform your development workflow okay now on to
the second category that was a creational category this is the structural structural patterns starting with facade the facade pattern is exactly what it sounds like putting up a a pretty front to hide everything behind it and you may be saying well isn't this kind of similar to what we just discussed the factory hides all of the stuff inside the factory remember creational patterns are for object creation structural patterns are how objects relate to each each other and the facade pattern it is kind of odd how it's like it's a pattern I mean it makes sense
it's fully detailed they uh it is a design pattern with specific implementation patterns and use cases but really it it's really just good programming technique I guess all of these are good programming technique but this one is really hard to miss anyway uh let me move on to my analogies you guys know how much I love my analogies so if you're watching this video you like how I EXP explain things trying to put them into layman's terms because that always helps me out make sure you subscribe because that's how I explain everything if you don't
like it you're not going to like the rest of my videos but you know how when you order something online and you put in your card d da and you click buy now and then well I mean magically everything else happens well behind that simple button a payment is being processed there are inventory checks there are shipping calculations fraud detection but you as the customer you don't really care I mean you care about fraud detection things of that nature but you don't really care about everything that's going on behind the facade right behind the buy
now button that's that's the idea here it's it's kind of just a really fancy word for encapsulation yeah I kind of like that it's a fancy word for encapsulation let's look at some code so without the facade oh Lord help us this is what it's like so new payment processor stored over here new inventory system stored over here so on and so forth everything that we just disced us and then we run through if fraud Checker if inventory system if payment processor bless your heart if you got to maintain all this and that is without
a facade and you'd have to write this every single time however with the facade you create a new order facade and you may be wondering well what happened to all of these aspects in the facade well all of that code is within our order facade class payment processor payment processor as you can see here then we have our instructor and then we have place order which has all of our if statements here to check through everything and this is all the code you need to write because we're using a facade where again if you weren't
you'd have to write this every single time use a facade pattern when you just have a mess of complex subsystems that you need to simplify so for programming it's exactly like that we get the outward appearance of the interface or class that we're interacting with and it hides all of that information all the complexity within it so we don't have to worry about it every single time the only real downside of a facade or at least the downside that I would like to point out is when it could become a god object I'm what's called
a Celestial sweetheart a Celestial like a god small G son knowing too much and doing too much but compared to spreading the complexity everywhere I'll take the trade-off and you're probably using facades all the time without realizing it think of a HTTP client you just call fetch API users and you get your data right you don't care about TCP connections or retry logic or header parsing or any of that low-level stuff and I mean this is actually built into programming languages like an array list in Java it's hiding all sorts of array resizing complexity behind
a clean interface array list that's the beauty of facades they're everywhere in good code next is the adapter pattern which is a very easy one simple one to understand because we deal with adapters in real life all the time have you ever had a laptop that you wanted to connect to a TV that it didn't have like any like what the 2016 MacBook Pro it didn't have the proper ports so you used an adapter to go from a USB port to a HDMI port the naming of these design patterns is not supposed to be complex
it is very simple very um intentional very specific it it's an adapter and you want to use the adapter pattern when you're integrating third-party libraries or apis that don't quite match what your code expects so let's say the third-party weather API gives us information in Celsius in kilometers and I've created this weather API interface however our app is expecting Freedom Units of Fahrenheit and Miles without an adapter we'll do something like this create implementation of thirdparty API with class thirdparty weather API that implement weather API which is the getting our Celsius and getting our kilm
per hour and then in order for it to work in our app we would have to come down here create the new thirdparty weather API stored in weather API and then do the conversion from Celsius to Fahrenheit conversion from kilometers to miles and well that's what you'd have to do every single time however with the adapter we implement the weather app which is what has temp F and speed miles hour we'd create class weather adapter that implements weather app which has our freedom units in Constructor private weather API weather API and then in our Constructor
we say hey weather API interface we need you because we're going to get the temp c from that weather API we're going to convert it to Fahrenheit and it'll be all done in this method and same idea with kilometers to miles and all of this is being done within the class so when we want to get that information from our API we can do something like this all of the logic is hidden right here and then we're using that information oh is it above 75 oh it's hot oh is the wind speed above 10 mph
oh it's windy that's it so instead of changing your code everywhere and putting that logic every single time you need to use celsius and kilometers from the weather API or if it was a library trying to modif modify the entire Library good luck with that all you have to do is wrap it in and adapt sounds like I was almost saying rapid Dash wrap it in and adapter rapid in an adapter say that five times fast the only thing is it can get real tedious trying to make an adapter for everything best case scenarios that
your library and API match up with what your app needs but that's again that's not always the case and an adapter is always going to be better than having all of this logic spread throughout your entire code base and what's interesting about the adapter pattern I don't know if this is just my mind trying to connect things but since it's all about making different implementations work together through a common interface it's kind of like the application of the strategy pattern which is the first behavioral pattern we'll be discussing and just to clarify again the structural
pattern is how objects interact with each other behavioral patterns is exactly how they behave how they communicate with one another so let's talk about the strategy pattern think about how you get to work some days you may drive to work other days you may ride your bike to work other days you may ride the bus I I live in the middle of nowhere where we don't have public transportation nor am I close enough to ride my bike anywhere so I just I do drive everywhere but this is how I imagine city Folk do it oh
let me change it up today let's take the subway today let's take the train let's let me drive let me bike let me walk I don't know regardless what I'm trying to get at is uh you have a common goal you need to get from point A to point B you are trying to get to work you just have different strategies of going about it one is driving one is walking one is taking the bus that's exactly what this pattern is all about so without the strategy pattern you have the efl's nightmare you have a
class of commuter that's you you're the commuter and you are going to work and if you're transport car then you know you got to start car check gas navigate traffic parking garage all of the logic is here else if you're taking the bus this logic taking the bike that logic and then this keeps growing with each transport type however with the strategy pattern you just have an interface of Transport strategy and then you implement transport strategy in the specific class foreset strategy so car strategy you put in the car specific logic bus strategy same idea
bike strategy same idea so that way once you come down here and actually create a better Commuter class within the class you can set the strategy and then just have one single if statement that utilizes whatever strategy you set up here and runs this Logic for for all of them and again instead of having if else if else if and then keep on going for walking and Subway and this and that so the usage would be just like this with the better Commuter you would store that in commuter and then you could set your strategy
to car strategy and then just call go to work and it'll do all of that logic with thing go to work and then if you need to switch the strategy let's do bike strategy instead that's how we're going to set the strategy and go to work with bike strategy and that's where again each individual strategy has their specific logic within it it is just so much cleaner this is how you need to be writing code don't don't don't if else if else if else if El every single time because the beauty of the strategy pattern
is that it it allows you to define a a family of algorithms you put each into its own class and then make them completely interchangeable or in other words it's just a fancy way of saying programming at an interface level letting you swap implementations without you needing to change any of your code you just make the thing into an interface and you do all the logic below the interface when should you use it all the time if you got different ways of doing the same thing then the strategy pattern is going to be your best
friend it follows the open closed principle perfectly you can add new strategies without touching any existing code and again that is just creating a new class that implements the transport strategy is whatever strategy we have car bus bike walk strategy and implement the transport strategy have your logic within that class the the walk strategy class you're good the downside downside is that you end up with a bunch of classes but that's a whole lot better than if eling if eling if eling and having the logic here and then having 20 different small classes all with
their own L statements like I was just saying yeah I'm going to take the strategy pattern every day of the week and I know I know this is going to hurt some feelings because I know a lot of y'all are just if elsing if elsing everything you know who you are don't you know who you are all right the last but not least the Observer pattern and I'm going to use the you a YouTube example because you're watching this on YouTube and you're the Observer to my video but let's focus on like notifications when I
upload a video and you're subscribed actually when you click the Bell make sure you click the Bell make sure you're subscribed all that when you click the bell I upload a video you get notified that's it the Observer pattern in code we'll go over it lets objects subscribe to events that happen to other objects objects subscribe to events that happen to other objects so here's the code without the Observer you have a class called user account this is the class to create you the user and right down here you create the user account array and
you are put in an array with all of the other subscribers of this video channel right and then when I upload a video what do I want to do I want to bloop through users and notify you somehow that 500 600,000 of y'all I don't think so so instead we use the Observer so that subscribers get notified automatically same idea but we create an interface called subscriber and then we're going to create a class we I just called it better video channel just so I can have two video channel classes in here and it is
the same idea we have the subscriber array and then you are added when you subscribe or removed when you unsubscribe and then when I upload a video we would notify with the title of the video to the subscribers down here as you can see this is our private notify method and we pass in the title so that it notifies all of my subscribers each of my subscribers I should say with that information does that make sense I think it's a good example it's just a little as long as you know how to read code you
know exactly that it makes sense otherwise you're going to have to Loop through millions and millions of people for many other channels every single time you upload a video which is not very uh performant so this in code like you see how it works in the code here but this could be like uh servers looking for system errors or monitoring for them so anytime there's a system error boom it gets notified or a component listening for uh State changes so remember object subscribing to events that happen to another object now there is one gotcha though
if you uh well if you go overboard on a vent you could enter into what is known as event callback hell where one event triggers another event which triggers another event and then all of a sudden you're wondering why your app is sending you a notification from 3 weeks ago but use responsibly The Observer pattern is is an amazing way to handle the uh if this happens do that and there you have it like any good tool it's knowing when to use each one so study them use them practice to get them in GR in
your head for more programming Concepts and developer stuff explained with too many analogies make sure you subscribe to the channel I'll see you in the next one
