Structural Patterns (comparison) – Design Patterns (ep 12)

welcome back this video is going to be a quick comparison video between a few structural patterns more specifically we're going to talk about bridge adapter decorator proxy and facade pattern by the way apologies for the band-aid I was fine tuning my moustache and then apparently I cut my nose sorry but but anyways so let me repeat the patterns that we're talking about first of all we are talking about structural patterns and which patterns are we talking about we are going to talk about decorator adapter facade proxy and bridge now if this is the first video you're watching in this playlist be aware that there are already specific videos on each of these different patterns so this video is just a comparison video because what we're doing in this playlist is that we're going through all of the patterns in these books all of the design patterns for object-oriented languages mentioned in these books and if you're new to design patterns I would highly recommend that you get this book head first design patterns and if you're not necessarily new to design patterns or if you're more like the reference kind of book person I would recommend this book design patterns elements of reusable object-oriented software and to play it safe just get both if you're in an object-oriented language makes total sense good books links are in the description but now to these patterns how are we going to approach this I'm thinking we do it this way how about we just look at the UML diagrams of all of these different patterns I'll try to draw them all at the same time here on this but white board just without texts sort of we just look at them visually and then we try to think about what the differences are between these patterns so let's get started let me remove this stuff so let me make a plan let's draw decorator here adapter here then facade here and then proxy here and then bridge here all right let's get going first up decorator pattern and I'm using the diagram from the head first book so with a decorator we've got an abstract component that is implemented by a concrete component but also implemented by a decorator which itself is an abstraction that has multiple concretions so instead of drawing multiple ones let me just do this sort of overlaying to emphasize that you can have multiple ones of these and these in turn have a decorator so think back about what the decorator pattern was doing the decorator pattern said that you had a particular sin and then you could take decorators and wrap that particular thing but you could stack any number of decorators so you could decorate a decorated thing where you could decorate the decorator that decorates a decorated thing and so forth right it's like layers so you have something at the core which is this thing and then you wrap decorators around that thing so it's like a layered onion you have this thing in the middle and then you wrap decorators around that one by one by one and then the computation happens you go inwards towards the core and then propagate the value outwards again I'm not thinking deeply into the patterns now since there actually are specific videos on these patterns so if you want to refresh your memory about these patterns do go back to the other videos but that's a decorator pattern let's now look at facade also from the head first book here's the class diagram but the thing about the class diagram for facade pattern is that it's extremely simple so the point where the facade is that you have a client in other words the user of the code and this client uses some kind of facade and this facade in turn is a facade over some complex logic or some some set of objects that are interacting in some complex manner or I should say non-trivial manner so literally this is the way they draw it in the book and not necessarily with these particular interactions but the gist of it is the same as in the headfirst book so the point is that here's the facade right this is the facade that introduces a liberal of indirection and the facade is a it's a facade over some complex behavior some some set of complex interactions you have all these different objects and you want to avoid having to force the client to interact with all of this complex stuff so instead you simply interact with the facade that interacts with all the disk complex stuff it's even borderline questionable whether this is really a design pattern because there is no abstraction here in terms of interfaces or inheritance there is no polymorphism here it's just that you have you have some nasty things that you want to call but instead of calling all of these things directly you call you call your nice wall here in between your facade you make a single call to that facade and then that facade makes all of these crazy complex calls let's move on let's look at the adapter pattern so what after pattern also from this book head first so man adapter pattern you to have a client let me put C here to emphasize that it's the client and the client has a target and this target is implemented by an adapter but P here for target a for adapter and adapter and this adapter has an ad of T so I'm sorry this turns out to be a and a but I don't mean the same thing this is the adapter and this is the ad of T so remember the point of the adapter pattern is that it converts an interface the point of the adapter adapter pattern is that the client wants to use some particular code using some particular interface and this T here is the interface that wants to use it wants to use it in a particular way that it's always been using it but for some reason you need the client to use another object which is the second a here and this second object the second a this object here doesn't follow the syntax of peor it doesn't follow the interface doesn't correspond to the interface doesn't respect the interface of T it has a different interface so C and a are incompatible to think of it as they are incompatible puzzle pieces they can't fit so what you do is you stick this adapter in between that makes I was a super bad drawing of a puzzle piece but I think you can see my point you stick this adapter in between these two things to make them actually work and the adapter here is this particular piece so this particular piece says I behave like the thing that you expect but when you call me I will delegate to this other particular thing that you actually want to interact with and that's the adapter pattern let's move on sorry for moving super quickly but we have a lot of ground to cover in this videos I've really got to move fast now let's look at proxy pattern so proxy pattern again from the head first book with the proxy pattern have a subject that's an abstract class or an interface and this abstract class or interface is implemented by two things or two has to concretions and these two concretions are the real subject and the proxy and then there's one error missing and that's that the proxy has a real subject so the proxy here says that there is an interface called the subject here there is some kind of interface so there is some set of families of things that you can interact with in some particular way this particular subject and then there's there's a concrete implementation this real subject here but then there's a proxy and this proxy has been introduced to control access to this real subject so when people want to interact with this real subject instead of interacting with that real subject what they will do is that they will interact with this proxy who will interact with the real subject you can immediately see the difference here that the adapter pattern here we had two different interfaces but with the proxy pattern we have the same interface the point with the adapter pattern is to adapt from one interface to a different interface right it's that translation so it changes the interface but it does not change the behavior the proxy pattern however the point of the proxy pattern is somewhat to change behavior but more specifically to control access to it so the intent is not necessarily to change behavior but the intent is to control access to the underlying thing but definitely the intent is to not change the interface so the real subject and the proxy has the same interface sorry I got carried away and got directly into the comparison let's now look at the bridge pattern so the bridge pattern is sort of an appendix pattern in this book so for the bridge pattern we have to get to this book design patterns elements of reusable object-oriented software let's look at the bridge pattern actually let me move this bridge pattern header here and put it here instead to give me some more space because we actually have a lot of space here so with the bridge pattern you have an abstraction and an implementer it's an abstraction that has an implementer leaving but I here and a here an abstraction that has an implementer and then there is an implement nation of this abstraction that they call the refined abstraction and I think they use the term refined here to emphasize that this is this abstraction here is probably an abstract class rather than an interface and then only on the right side here we have concrete implementations of this implementer and again I'll do sort of this 3d ish notation or like leaves on leaves notation to emphasize that there can be multiple ones here so you can have multiple concretions of this implement or abstraction and actually even though they didn't draw it explicitly in that diagram I would say that it's a key part of the bridge pattern to actually realize that you could have that you can have multiple implementations of this abstraction so we'll do the sort of Leafs on leaves or a 3d notation here as well and actually let me just immediately refine this this drawing of the bridge pattern I mean remove the letters and let's simply just think about this as a 1 a 2 and C 1 and C 2 point being that you have abstraction 1 and abstraction 2 and then you have a conclusion one of abstraction 1 and concretion 2 of abstraction 2 so or maybe that was an unhelpful way to think about it maybe what I should have done is that I should have said the hierarchy of ease and the hierarchy of bees or something like that so actually maybe that makes more sense let us think about this as the hierarchy of a let's think about this as the hierarchy of B and then let's think about the first one on top of this stack of leaves is as a1 and the first one here on top of this stack has b1 so here are a number of different A's and here are a number of different B's and A's have B's because of this has a arrow and that's the bridge pattern so let me add some dividers here and then let's start to do some comparisons all right but before we move any further let's also add some letters to the decorator pattern picture here because we have letters in all of the other patterns so in the decorator pattern this was a components let's write C here then we had a concrete component let me add CC so sorry these letters are just totally informal just so that we can have some kind of a reminder of what that thing actually was so we had a component the concrete component and then the other implementation of the component is the decorator so let's say thee and here we can have multiple implementations of a decorator in other words we can have multiple decorators in the decorator pattern so let me just put C B here to denote concrete decorator so these are concrete decorators but now let's talk about the differences let's start by reading in the definition for all of the different patterns one by one we start with a decorator pattern so the definition from the head first book of the decorator pattern is that the decorator pattern attaches additional responsibilities to an object dynamically decorators provide a flexible alternative to sub classing for extending a functionality so the point of the decorator pattern is in other words to say that instead of creating another subclass of a particular thing in order to change behavior of how some method of that thing behaves we instead achieve that a behavioral change through composition rather than through inheritance more explicitly through wrapping a decorator around a particular thing within the context of this pattern that means these decorators that can be treated uniformly because they share this the decorator interface or wrapped around a concrete component and the decorators since any decorator is a component any decorator cannot just wrap a concrete component but it can also wrap any other decorator so again sorry I'm kind of glancing over the details since there are specific videos on these different patterns so if you haven't watched those videos and you want to know more about the pattern do check out those specific videos so that's the decorator pattern then adapter pattern the definition of the adapter pattern also from this book head first is the adapter pattern converts the interface of a class into another interface that the client expects adapter let's classes work together that couldn't otherwise because of incompatible interfaces and this whole notion of incompatible interfaces is really the key point than the other after pattern just like a physical adapter like a physical plug that you use to adapt from one countries plug to another countries plug for example or from literally from one one kind of interface to another kind of interface just think about how you're adapting cables for example I just saw this laying around and this is actually a perfect example even this you could consider as an adapter I mean it it converts from I guess mini DisplayPort to DisplayPort or perhaps in the other direction depending on how you think about it so if you think about it then it becomes obvious how decorators and adapters are different because the intention of a decorator is that you want to change behavior whereas an adapter you don't care about behavior behavior is not the point the point is that you want to use one interface but the thing you want to use happens to have a different interface so you stick an adapter in between so that you can use the thing that you want to use that has a different interface but through your own interface so hopefully those two are clear adapter focuses on adapting an interface decorator focuses on extending behavior by wrapping the thing that you want to change the behavior of a potentially infinite number of times let's move on to the next facade let's look at the definition of assault so here's the definition of the facade pattern again from the head first book the facade pattern provides a unified interface to a set of interfaces in a subsystem facade defines a higher-level interface that makes the subsystem easier to use so think about it in terms of this picture the client wants to use some very complex subsystem but instead of using that complex subsystem directly the facade provides a higher level interface that the client can interact with instead and this higher level interface instead interact with this subsystem so the facade doesn't really necessarily wrap something in the same sense as the adapter because I mean if you think about these two they do kind of similar things because the adapter adapts from one interface to another and in some sense the facade does to adapt from one interface to another but the facade also has an additional responsibility with which is simplification the intention of the facade is to simplify this complex subsystem whereas the job of the adapter is simply to adapt from one interface to another so this is why we're drawing all of this complex stuff here so the facade probably wraps some thing which is unnecessarily complicated or or complicated to the extent where you don't want to interact with that directly I like to think of this as that this might be a third party library or something like this that you want to use and you don't necessarily have control over as you can't refactor for example but it could also just be that you have a highly decoupled system you have a system that you've built in a highly decoupled manner which is a good thing like you've you've managed to identify reusable small pieces that you can extract and then compose together in various ways but in order to do any meaningful work you perhaps have to compose you have to bring together a bunch of different pieces and use them in kind of intricate ways and so maybe the facade you use to simplify some of that so you have all of these super decoupled pieces that you can use in very powerful ways you have those you have the power of that but you still want to give yourself a simpler interface so that you you see that you sometimes don't have to deal with all of that when you want to do some particular task that you repeatedly do or that you for example want to give a particular name so that could potentially be a good a good use case for the facade pattern and again that is too complex to be an adapter it's not an adapter because it's not simply adapting from one interface to another there's more logic involved there also of course if we look at the UML it's different I mean here in the facade pattern notice that this is not an easy arrow it's not an implements arrow and it's not necessarily a has a arrow either we're just stating that somehow interacts with this complex subsystem we're asking the adapter pattern this adapter here actually is a target or implements the same interface as the target so the adapter behaves as the target before we go further let me just pause here for a second I should have said before that I mean interestingly if if you think about the way these pictures look let me move out of the frame think about these different these these different diagrams actually they are different I didn't really think about that but as we went through the different videos but it's not just the day different intent which is super important but they actually also differ structurally like notice how we haven't really given proper names to them but still structurally they are different I mean bridge is obviously not the same as adapter adapter is obviously not the same as proxy proxy is obviously not the same as facade and so forth and so forth they are actually different and if you think about which is kind of what we're doing here if you think about carefully what they actually do you realize that they are specialized for very different scenarios they're they're very good at solving specific problems that have and isn't when we get back to intent that have different reasons for appearing they're actually solving problems that are qualitatively different but anyways that's a quick side note let's now actually move forward next pattern so we've talked about decorator adapter and facade let's now talk about proxy so the definition of proxy pattern again from the head first book is the proxy pattern provides a surrogate or placeholder for another object to control access to it or if I'm even more specific provides a surrogate or placeholder for another object in order to control access to it think about it in terms of this picture the proxy pattern provides a surrogate or a placeholder this is the placeholder for another object to control access to it and the other object is this object and the intention is to control access to it so a client instead of using this particular real subject it uses the proxy which determines when or if to delegate to the real subject and of course importantly the reason that we have this subject interface or abstract class is that the real subject and the proxy needs to share some kind of common ancestry they need to share some common ancestor so that they have a similar interface so that they can be treated interchangeably or so that we can interchange a real subject for a proxy or a proxy for a real subject so in other words in order for a proxy to be able to stand in to stand in place of a real subject it needs to have the same interface as the real subject so if you think about it the proxy is almost like the inverse of the adapter pattern in the sense that the adapter changes the interface but not the implementation while the proxy changes the implementation but not the interface but this is not entirely true or rather the world is not that simple because you could also say the same thing we said about proxy we could also say about decorator because the decorator too does not change the interface but does change the implementation so what is the difference now between a proxy and a decorator well I interpreted this way here I think we get into the discussion of the intent rather than the structure of the pan because if you read these books it seems that they're saying that you can have proxies that are treated as a wrappers that can ramp wrappers in the same sense as decorators I mean decorators are sort of like the shells or or the layers of an onion who can decorate the decorator that decorates a decorator etc until we get into some core and you could sort of do the same thing with proxies where you have proxies that proxies a proxy and where you have a proxy that proxies some proxy that proxies some proxy that in turn proxies some some real subject my understanding from reading these two books is that that's not necessarily the common use case for a proxy pattern the common use case for proxy pattern is simply that you have a single thing that you want a proxy that you want to control access to while with the decorator pattern that's actually what you're looking for you're actually looking for this composability you're looking for if you watch the last video we talked a bit about Commendatore it's like well what happens when you have many combinations of different things and then you have a class explosion of different specializations that you have to implement those classes decorator solves that kind of problem where you want to be able to say let's let's say that we have CD one CD 2 CD 3 here so to represent that let me just put 1 & 2 & 3 here and the problem we're solving with the decorator pattern is when we want to be able to treat all of the different combinations of all these different classes as a special case that has some special implementation and formally I think this is called the number of K combinations for all K so if you have the set of 1 2 3 sorry I should have it written in like this if you have the set of 1 2 & 3 so when we talk about combinations as opposed to permutations order doesn't matter so when we say something like the number of K combinations of this set we mean the number of ways that we can take KL from this set without caring about the order in which we extract the elements so if K is 3 in other words we're looking for three elements out of this cent that means we only have one combination there is only one way to take that I mean it doesn't matter if we do one two three or three two one it's still the same set because order doesn't matter so for k3 there's just one but decorator pattern is not interested in that problem that crazy pattern is interested in the number of K combinations for all K so when we say for all K we mean for K for K equals 1 and K equals 2 and K equals 3 and if we talk about 2 for example then we have more ways of combining this because then we take two elements so then we have 1 and 2 and we have 2 and 3 and we have 1 and 3 so we have 3 ways of doing that and then for k1 we have 1 and we have 2 and we have 3 in other words we just take of one element and then again like in the beginning we said we have also 1 2 3 so the number of K combinations for all K for this set sorry for going a bit quickly but this is sort of tangent up to what we're looking at it was the number of K combinations for all K for this set would be this this set of 1 2 3 4 5 6 7 7 elements and actually I said that the answer here would be 7 but for money the answer would actually be 8 because the empty set also counts as a possibility just to be like mathematically accurate I just want to say that yeah answer here then actually is 8:00 and not 7:00 because in this set of sets the empty set also counts as 1 the answers but tangental so the point the reason I wanted to say this is that I'm saying that if you have three things three behaviors combining these in many different ways where sometimes you can have only this behavior sometimes yeah you have these sometimes you have these sometimes you have all of these sometimes you have only etc etc there are many different combinations so quickly you can reach a class explosion what's worse is that now we talked about combinations if you talk about permutations where order actually matters where 1 & 2 is different from 2 & 1 think about it this way if one of the behaviors is increase the price by adding 10 and the other behavior is double the price then it matters whether you first add 10 and then doubled double first and then add 10 so in that scenario we're actually talking about the permutations and then the number of different permutations essentially that we would have is a little more so sorry now I know I'm getting really off track let me remove this stuff here's where I'm trying the same decorator pattern is explicitly trying to solve that problem or specifically trying to solve that problem it's trying to solve the problem where you want to decouple different behaviors so that you can compose them in any way you like that's the problem that decorator pattern is trying to solve that's a different problem from what proxy is trying to solve because proxy is trying to say for some reason you need to control access to this underlying thing so let me just stick this thing in between so in some ways I would say that the proxy is kind of a simpler problem it's it's it's an access mechanism it's like we're saying here's something that I need to be careful about interacting with so just to make sure that I won't do it incorrectly let me stick this proxy in between and interact with the proxy instead kind of but yeah I mean if you would implement the proxy as that a proxy that can proxy a proxy that can proxy proxy etc you would probably make the proxy diagram look a lot like the decorator diagram it's not exactly like the decorator diagram so here I think the main point is that intent is different let's now talk about the final pattern bridge pattern the definition of the bridge pattern will get from this book design patterns elements of reusable object-oriented software the intent of the bridge pattern is to decouple an abstraction from its implementation so that the two can vary independently and if you've seen my video on bridge pattern you know I kind of think that that definition is a bit strange and the way I like to think about bridge pattern is this way I like to think of it this way we have two inheritance hierarchies or two polymorphic hierarchies and we want them to be able to vary independently so we want to be able to take anything of type a and combine it with anything of type B notice how this problem is very similar to what we talked about now with the decorator problem but with the decorator we had one set sorry for drawing here in the adapt I now mean that what we're talking about here has to do with the decorator we have one cent of some number of things one two three etc and we want to be able to combine these different things in different ways from from a single set whereas with bridge pattern is slightly different because here we have let's use the terminology from here let's say a 1 and a 2 one set and in the second set we have B 1 and B 2 here we had 3 like B 1 and B 2 and B 3 but in order to reduce the complexity let's just think about two elements in each of the different sets so we have the set of A's and we have the set of B's and the point is that we want to be able to combine anything from set a with anything from set B so it's like you have this problem where you have let's think about it this way you have two things that you want to be able to do and you have multiple ways of doing the first thing and you have multiple ways of doing the second thing and then you want to be able to combine any two of the many combinations of ways of doing these two things and that's why we have one hierarchy here and one hierarchy here so let's think about this in relation to the decorator I mean the decorator what the decorator does is that it changes the implementation of a single thing but the bridge then we have two ways of doing things I mean of course in the decorator here we have a concrete component but of course we could have multiple concretions of a component which means that you can have multiple different components and multiple different decorators which actually also means that we have two sets where you can combine any piece from the two sets and in fact you can actually have multiple decorators on the decorator end but the difference here is that the concrete component and the decorator both implement the same interface they are both components right think about it concrete decorators or decorators and decorators or components and the concrete component is also a component so that means that everything here in this pattern everything shares the same interface but in the bridge pattern it's different we don't share the same interface because here we have hired a one interface and hierarchy b-but actually a completely different interface and this is probably why we call it a bridge it's like bridging over to a different interface so the bridge Baron is actually really flexible way of architecture in your application so again we're solving different problems I mean yes these are even structurally different like if you look at the structure of this these images they are different but they are also different in the kind of problem that they're solving I actually I mean bridge pattern is a structural pattern and strategy pattern for example it's not a structural pattern strategy pattern is a behavioral pattern but I actually think that bridge pattern is is a lot like strategy pattern and we had some discussions about that in the comments like strategy pattern plus adapter pattern or something along these lines because if you think about strategy pattern strategy pattern is all about the pendency injection it's it's all about saying I have this thing that I want to do but I don't want to care about how that thing is performed so I will just declare that I will accept something of a of a particular interface and then you pass me a concretions that corresponds to that interface and I will call the methods of that interface whenever I need it so I have a method and my method accepts an argument of some particular type so you dependency inject that thing into me and then I can call methods on that thing and that's I mean kind of the same thing here it's like we have a s and A's expect a B right you dependency inject something of type B into A's but the key portion here is that we have as opposed to strategy pattern we have two different hierarchies in other words actually let's just draw the strategy pattern sorry for breaking the rules of going outside of structural patterns and into behavioral patterns so strategy pattern drawn from this book looks roughly like this you have a let me remove this stuff you have a context let's call it C that uses some strategy let's say s that can have any number of implementations let's say s1 and then we'll use this sort of leaf on leaf notation they know that there can be multiple different implementations so if you think about it this is like half the bridge what's missing let me actually before we go further you just draw a red line here and then state that this is strategy so again this is like half the bridge it's like all of the bridge except for these A's so to make this the bridge pattern we would simply have to add this implementations arrow and the different implementations that the complex could have the different implementations of the contacts that we have but let me remove that for now so if you think about it the bridge is almost kind of like a generalization informally it's like taking strategy a step further it's like saying actually this is a really good idea but what if the thing that uses this strategy also is abstract and also can have a number of different different implementations which again makes a lot of sense because it's very flexible and actually I mean if you think about the statement program two abstractions rather than concretions in other words avoid programming or coupling classes to classes in other words instead of coupling two concretions instead of copying two classes couple two interfaces because if you're always coupled two interfaces you'll naturally end up in this kind of scenario maybe the whole dependency injection thing but perhaps require a bit of thinking before you actually end up in that scenario but probably I mean if you start to always program two interfaces rather than implementations and really think about how you're doing it you'll probably end up in Enbridge pattern kind of naturally like it's sort of a natural extension and by the way this is maybe a good time to run in the statement where that I think somebody said that programming was discovered rather than invented sorry I can't remember who actually said that but I just think that a statement is kind of profound it's like it's kind of like logic like if you think about it long enough you'll discover these things that are inherent conclusions or natural conclusions from the first principles or from the from the axioms that we decide upon so like if you decide upon the axioms of object-oriented programming if you decide that okay these are the building blocks that I have in object-oriented programming it's kind of a natural conclusion to end up with things like bridge pattern because it's a very flexible way of thinking about it it's a very it's it's it's it's a way of actually being able even being able to to build small pieces that you can reuse so this whole whole notion our animals ID of the panacea where we would have different things that we compose together where these small things are really reusable so that we don't have to rewrite them like in object-oriented programming the way to get to that kind of flexibility is through things such as the bridge Palin or or or in some sense dependency injection into madness right okay yeah that's way too much of an aside let's wrap that up so I hope this overview kind of makes sense let me just quickly say again the decorator pattern extends behavior by decorating or component the strategy pattern we threw in here even though it didn't belong because what we were talking about were structural patterns but let's then just say it also that the intent of the strategy pattern is to define a set of algorithms or a family of algorithms where you can exchange one of the algorithms for the other you can vary the algorithms independently from the context of the thing that uses the algorithms next one adapter pattern and after pattern adapts from one interface to another interface you want to use a particular interface but the thing that you want to use has a different interface you stick an adapter in between so that you can use the thing you want to use the proxy controls access while the adapter says I only change the interface I don't want to change the implementation the proxy says I change the implementation but I don't want to change the interface so the proxy proxy is a thing but uses the same interface so you can place the proxy instead of the thing that you wanted to use because it has the same interface it's interchangeable but then the proxy controls access to that thing that you you placed it in front of the facade is super simple I mean the salt has none of this dependency injection or that stuff the facade is a term that we use simply when you have a scenario where you have some complex subsystem and then you throw a facade in between you say here's the wall use this simpler thing and this simpler thing will interact with all that complexity from the subsystem and again this is not the same as proxy because it doesn't necessarily require the facade to have the same interface as anything in the subsystem and it's not the same as the adapter because it doesn't necessarily adapt from one interface to another it I mean the facade has a single interface but the subsystem matter I have a bazillion interfaces so it's simply a way of hiding some complexity of some subsystem the bridge pattern is perhaps actually most easily thought of as as an extension of the strategy pattern it's like the strategy pattern but where the context that uses the strategy also is an inheritance hierarchy or also is a polymorphic hierarchy so you have two inheritance hierarchies or two polymorphic hierarchies and one of the hierarchies uses things from the other hierarchies so you can take anything from the first hierarchy and pair it up with anything from the second hierarchy and that's a valid pair so in some sense it's a way of avoiding duplication of code and increasing reusability oh okay so as usually I thought the video would be super short but then it turned out not to be a I'm sorry about that I hope this makes sense if you appreciate this kind of comparison video let me know in the comments and perhaps we'll do more after we've dug through these patterns but only if you actually think they're useful if it's just too much repetition let me know and we'll do them I really know which pattern is the next pattern in other words for the next video but there are lots of patterns left so remember to subscribe so that you won't miss the upcoming pattern and the upcoming videos before you go give it a thought you might want to get this book or you might want to get this book if you're learning object-oriented programming if you're working with object-oriented programming super good books to have as you can see people have been thinking a lot about these things and if you dig down they're actually a lot of interesting thoughts that have been thought I guess anyways beyond that I've actually started this side project where I'll try to write my own book on design patterns so if you think that sounds interesting be sure to check out the link in the description thank you super much for watching remember to subscribe and I'll see you in the next one

Channel: Christopher Okhravi

Views: 64,096

Rating: 4.9425836 out of 5

Keywords: design patterns, oop, head first: design patterns, elements of reusable object oriented software, programming, code, object oriented programming, structural patterns, structural design patterns, vs, comparison, adapter pattern, decorator pattern, facade pattern, proxy pattern, bridge pattern, strategy pattern

Id: lPsSL6_7NBg

Length: 36min 22sec (2182 seconds)

Published: Sun Sep 24 2017