5 Design Patterns Every Engineer Should Know

So when we think about career progression in technology, we tend to think junior to senior to go from architect to director and I think that misses the point to some extent because there's an axis of technical competency that's missing in that and I think that that is. It is most easily described as moving from a framework consumer to a framework creator, so you start using something like Spring, react or view depending on the paradigm you are working within and you are moving up that chain of technological competence from where are you. it actually just consumes that framework to where you end up creating a framework that is used by tens of hundreds of thousands of other

engineer

s and they become your consumers, so to get there you have to develop your technology and your skill set.

Well, and you start with a basic command of the language of your choice and you

know

, you learn all the ways of doing conditionals and loops, creating functions, methods, classes, instantiating objects and all that, then you work on data structures and algorithms. and finally in

design

patterns

and

design

patterns

are ways of expressing robust architectures that are reusable and extensible and that are industry standards, so in this video we will look at five different design patterns from this original book by The Gang of FourDesign. The pattern book is in c plus but the concepts are usable and understandable in any language and also in any environment so in android browser or ios on server wherever you go design patterns will help you to going from a framework consumer to framework creator, well let's start with the first one and see how quickly you can identify it to have a database driver that you are connecting to and you want to get a list of all your clients so you can do that query and you will get a list of all objects that are client objects, so in this case you have the client object or client class of which you can have many and then the database controller of which there can only be one and you may have guessed that that is the singleton pattern as specified here and it means that for that given class there can only be one instance and that is really good for doing things like a database driver or listing all settings for your application or if it is on the client, maybe the data stores the current state of the application which is stored in a singleton, the pro is that you can access that data anytime you want, all you have to do is just

know

ing how to get the singleton and that's it, the downside in your evolution to the framework builder is that you can jump on the singleton bandwagon too early and once you've gotten there, once you've said there can only be one and added that constraint, it's really hard to reverse that, it means that instead of

every

one being able to just go and access it directly, now you have to pipe in the current well database driver.

In this case, it is an example, it must be channeled to whoever the consumers are. As with all of these design patterns, you need to make sure you use them in the right way and at the right time, otherwise they will bite you. The second design pattern we will look at is the facade pattern. and many of these design patterns are actually modeled on real world building style architecture and this is no different, so a facade in the real world is the front of a building and hides all the mechanics of the building inside of the insulation of the rooms. the infrastructure plumbing and electrical and the basement and all those things that you don't want to see are hidden behind this pretty facade, it's got a door and some windows and

every

thing that looks really pretty has great curb appeal, so, as a framework creator this gives you the façade pattern it gives you the ability to put a nice outer shell on your application now the example they use in the book is a compiler so a compiler has all kinds of cool stuff inside of it you have a parser you have a lexical analyzer you have a tokenizer, you have all kinds of fun stuff, but from a consumer point of view, when you as a framework creator think about your customer and empathize with what they want to do in their priorities , he tells himself, oh, and maybe.

I don't want to give them access to all the internals, maybe I just want to give them a nice compiler façade where they give me something, I compile it, return it and voila, I hide all those internals, so that's the big advantage, it gives you and your consumer a nice interface and if you allow them, if they want, they can walk through that interface and go inside, if they choose to do so now. The downside is that you can have a leaky paradigm there. you may have a leaky abstraction, in other words, you've oversimplified that the compiler interface is so simple that it's not really usable or really valuable and that can be a problem.

Another issue is verticalization, which means you've created a façade that is so specific to a single use case that it's no longer widespread enough to be generally useful, so those are things to keep in mind when uses a facade pattern so the next design pattern we'll look at is the bridge pattern which I call is the adapter pattern but they have a different definition in the book for the adapter pattern but let me use a visual example in um so here's a Sony mirrorless camera like the one I'm using now and it's actually two pieces so you have the camera body and then you have the interchangeable lens and that allows this camera body to be multipurpose.

In this case, this is a wide angle lens good for giving nice big contact lenses like This is a 55 millimeter lens, which is much better if we're doing some sort of headshot portrait and I use it when I'm doing zoom calls. , so the reason that's important in this context is from a software perspective. By doing something like that you're creating an API or in this case the API is a similar connector here in the software world that would be an interface, so now on the server side you might have that database we talked about before. you would have an abstract interface for your database driver and then you would have concrete implementations for, say, dynamodb or whatever else you're going to get into and the nice thing about this pattern is that it allows you to create a product that is usable by a wide variety of clients in a wide variety of situations, something similar on the client side, you could do an abstract parsing interface and then have concrete implementations to go to something like omniture or adobe segment or your own home brew, whatever . want and that it can work on both website and mobile, the problem is that the big disadvantage of this is when you use it too much, so in this case there is only one extension point for this camera and it is this interchangeable lens, so when they didn't go and go and create modules for this little dial here or the eyepiece, they used that pattern judiciously, so you

should

do the same thing when it comes to your software, don't overuse this pattern and the best thing about this is that you can also introduce it later and that's what you can do with many of these design patterns.

You don't have to start right away by creating the world's most modular system. Make something work and then when you see the points where you need modularity. and this bridge pattern, then bring in the fourth pattern that we're going to look at, it's the strategy pattern and it's one of my personal favorites, so let's take a scenario where you have this hairball code that will go and find a A bunch of clients filter them and then send them email and text notifications and no one likes working on this piece of code because it does multiple things and it's just a hairball.

You can use the strategy pattern to clean this up significantly and how you do it. that is, you take the mechanics of getting access to customer records, sending text messages and emails and then creating that as an infrastructure layer and then factoring the filtering of those customers into a strategy, which is the strategy that helps you find the target customers you want and then the notification strategy as a different strategy and it helps you decide when, where and how you want to contact those customers so that the pattern of the strategy becomes clean and makes it very easy to use and then you can use it. library or that system in a bunch of different scenarios and it becomes a lot less complicated, so one thing you have to keep in mind with this is to always make sure you have decent default strategies, so in the case of our refactoring we go and take existing logic around customer filtering and customer submissions and make them default strategies and then people can extend them; otherwise you will get a system where by default you will be asked to do a lot upfront and no client wants to do that.

I want to go and take your library off the shelf, just use it right away and then if it doesn't match With what I want to do, I'll see what extension points I can take advantage of to modify the behavior. where I want it and the strategy pattern is a great way to do it. The fifth pattern we are going to look at is my favorite of all the patterns and it is the observer pattern or what we now know as pub sub. because it's everywhere, it's on the server like message queues between applications, it's on the client like event systems, pub sub is everywhere and there's a good reason for that because it allows loose coupling between the editor that creates events and the subscriber or subscribers who are listening. for those events and you can use it anywhere now, the downside of this particular pattern is that you can overdo it if everything is communicated using events, then you can get into nasty event loops and it becomes very difficult to debug a thing that publishes an event. it goes to another object which in turn posts its own events and ends up going back to the original event which ends up creating more events and so on and then you know you have a serious problem you're in.

We're ending up adding booleans to check if you're emitting events and it's getting complicated, so there are a couple of solutions to this: don't use the same message bus for everything, have a specific purpose for each message bus, and then you know, keep these systems localized. You know if you're in the client, you have a button and it emits an event. That's good. That's all you need. You don't need to go further. Again, as with all these patterns. use them wisely, but use them because most people understand those systems when they get a good look at them.

I hope you liked this quick tour of the five types of design patterns there are. I think they are almost wow. About 20 different design patterns in this book. This is a fantastic book.

should

be on every developer's shelf if you have any questions or comments make sure to put them in the comments section below if you like the video hit the like button let everyone know if you really like the video please subscribe to Brad or jump over to my channel and subscribe I would appreciate it have a great day be happy stay healthy and safe