Bridge Pattern – Design Patterns (ep 11)

this pattern below it's my mind because it's pretty awesome it's time to talk about the bridge pattern now if you've been following this series you're not probably feeling wait what the bridge pattern in the previous videos I've been saying that this video was going to be a comparison video between a few structural patterns I'm sorry apparently I lied this is what happens when I don't really think about what I do before I get started hopefully what's about to come is better because that's not the only correction I want to make here's the second one in the previous videos I've been saying that what we're doing in this playlist is that were walking through all of the patterns in this book had first design patterns but in the comments when I talked about the comparison video somebody mentioned the bridge pattern and then I realized actually bridge pattern is part of this book but not part of the main portion of this book but rather part of sort of the extra patterns that are almost like an appendix I mean they're just kind of shortly mentioned in the end so this book thoroughly talks about a few patterns and then not so thoroughly mentions a bunch of other patterns of course in this classic Gang of Four book you have sort of a lightweight explanation of almost any pattern because it seems that you peeps actually appreciated the contents in this playlist and by the way thank you super much to everyone who's watching the videos in this playlist because of that I'm wondering why I should limit myself to only talk about the sort of main patterns from this book I mean the original intent from my side was to just talk about the the main patterns in this book and not go into the extras but now what we're going to do is that we're simply going to take all of the patterns mentioned in these books honestly I haven't checked but there are some patterns that are mentioned in head first that are not mentioned in the Gang of Four book or vice versa but in some kind of semi structured order we'll make sure to get through all of the patterns hopefully you agree that that's good news and you will forgive me for changing the order of the videos but enough for that before we get started let me just mention as usual if you are new to design patterns get this book head first design patterns super pedagogical lots of images take spends a lot of time in in each of the patterns that it actually thoroughly explains and I guess the point is that they call it headfirst for a reason they try to think about how we learn and they're not just trying to bash contents into our brains links in the description if you're not new to design patterns or if you're more like the reference kind of book person get this book design patterns elements of reusable object-oriented design by gang of four old but super classic you can't go wrong with this book and if you're looking for world domination I would suggest that you get both of the books because how will you dominate the world if you are not I guess the most expert in design patterns moving on but now let's talk about bridge pattern because the bridge pattern is an extra pattern in this book they don't have a definition so let's instead read the definition from this book the intent of the bridge pattern is to the couple and abstraction from its implementation so that the two can vary independently let's replay the intent of the bridge pattern is to decouple an abstraction from its implementation so that the two can vary independently usually I try to decode these explanations but to be perfectly honest this confuses the heck out of me I mean in my mind this just sounds completely bonkers if you think about what we're saying is that we want to decouple an abstraction from an implementation so let's say we've got an abstraction which is animal and then we have implementations that are concrete animals or dogs and cats dogs and cats inherit from animal animal is the abstraction and dogs and cats are the concretions or the implementations and then we're saying that the implementations are the concretions can vary independently of the abstraction so I mean what does not even mean does that mean like we can change the method names or something like that I mean I'm sorry I'm just confused if somebody actually sharply knows what this means please do shoot something in the comments but if I would try to understand it here's the way I would think about it so it's about decoupling an abstraction from an implementation we first need to have an abstraction and an implementation so let's say that we have an abstraction which is I animal and we have an implementation which is dog so dog inherits from AI animal I animal or let's just say animal is the abstraction dog is the concrete or the implementation so I guess what they're saying is that this is somewhat coupled in the sense that what if I animal declares that to be an animal you need to have a speak method so dog needs to implement the speak method but that means that dogs have to follow the interface animals so if animals would change that means dogs have to change so so if animal would introduce another method which is for example move then that means that dogs now have to implement move which means that dogs have to change whenever animals change which means which means that they can't vary independently now again I'm not necessarily sure that this is a sensible way to think about the problem that the bridge patter is trying to solve so bear with me I think it makes sense that we just dive into the actual workings of this pattern and then think about what the intent is because I think about it more as a decoupling and interaction so more like adapter pattern because adapter pattern you stick an adapter in between something so that you can vary two interfaces independently but I've been sort of googling around and it seems that people say that adapter pattern is usually added ex-post so it's usually added after the fact whereas bridge pattern is applied precociously or it's applied beforehand to to allow yourself the flexibility to give yourself the flexibility for the future adapters you apply when you have a problem bridge pattern you use to avoid that kind of problem but I really think about it as the interaction being the key let's move on but let's start in this end let me remove this stuff why is it called the bridge pattern it's called the bridge pattern because it looks like a bridge here's the thing let me draw the UML diagram you've got one abstraction here one abstraction here any number of concretions here and any number of concretions here let's draw the arrows this down here is a concretion of this first abstraction this down here is a concretion of this abstraction and then what's the relationship between these well this abstraction has something of this abstraction this is why it's called the bridge banner because it looks like bridge pillar pillar plane so let's use the terminology from this book so they call this an abstraction and they called this an implement or and then they call this a refine abstraction and this a concrete implement or that just seems unnecessarily confusing so let's let's call this a concrete abstraction they might have said refined to emphasize that this is probably an abstract class rather than an interface while this is an interface but whatever I mean this is abstract this is concrete this is abstract as is concrete so here we have concrete abstraction and here we'll have concrete implement or and of course we could have any number of concrete abstractions here and we could have any number of concrete implementers here obviously we will talk about this in more detail but probably you can start to see now why they're using the term decouple the abstraction from the implementation so if this is an abstraction and this is an implementation then they're now decoupled in the sense that you can have any number of implementations and you can have any number of abstractions and you can pair these up in the sense that an abstraction uses an implementation this abstraction makes use of an implementation and for this to work if this is an abstract class or an interface probably an abstract class then this abstraction needs to be any one of these concrete abstractions and any one of these concrete abstractions in order for this error to work needs to have an implementer but seeing that the implementer is an interface we need to have or it needs to have one of the concrete implementers so this is a pairing of a concrete abstraction with a concrete implementation and if you think about that this is actually quite interesting if you think about the term Cartesian product so sorry for going math on your hair but so the term Cartesian product is is used to describe a set that's derived from two other sets super quickly just think about this let's say that you have set 1 s1 which contains a and B and then you have set to I'll say s tune that contains 1 & 2 so both of these scents have two elements each and the first one contains a and B and the second one contains 1 and 2 so what's the Cartesian product well the Cartesian product is a new set of all of the combinations you can kind of think of it as a multiplication over sense or the set of all ordered pairs so what would the Cartesian product of this be well it would be the set of the pair a 1 the pair a - the pair B 1 and the pair B 2 the reason I'm saying this is think about this what would happen if we added another element here into both of the sets what if set one contained ABC and set to contain one two three okay now we have to add a lot of more stuff to the Cartesian product here now it's not just enough to have a 1 and a 2 now we also need to have a 3 and then we have B 1 and B 2 but we now also need to have B 3 but we need to do the same thing again for seeing as well so we need to have somebody in the same set we also need to put the pair C 1 and C 2 and C 3 so you can see how as we add more elements to these sense the number of elements in the Cartesian product exponentially increases but what does this have to do with the bridge well if you think about it this is a set a and this is set B oh sorry I should say this is set 1 and this is set too so I mean if you think about what we said before we want to be able to pair up any of the concrete abstractions with any of the concrete implementations or any concrete implementers which means that if we have 10 concrete abstractions here and 10 concrete implementers here the Cartesian product is going to be huge this doesn't really seem like any kind of problem because we started in this but if we hadn't extracted these into two different pieces that could be composed together right that's the key point think about composition over inheritance we're saying that anything from here can be composed with anything here you can take any concrete abstraction and pair it with any concrete implement or so let's just think about it this way when we had three here and three here how many ordered pairs do we have assuming I did this correctly we have nine but we don't have nine classes we have three classes here three classes here and that's enough we don't need to build nine classes and that's the key point because as these start to become more we could potentially have a huge problem if we would have to create the nine classes let's look at a concrete scenario so we can see why this would be useful and what the potential problem would be if we didn't do it this way let's remove this stuff so here's the example imagine that we're building some kind of app where we have a screen where we want to show different kinds of media products let's say we want to showcase books songs albums artists maybe you've used the app Spotify if you think about that like in Spotify in some some list views or lists and playlists and albums are sort of mixed together like they look sort of the same but if you click them you end up in different locations so UI wise I mean that's that's not really a strange thing it might be very interesting so we have only all of these different sort of media types or media media things and we want to display them on different pages but we don't just have different media types we also have different ways of displaying these different things so let's say that we have just to make it simple let's say that we have short form and we have long form and if you think about it this is actually not that contrived I mean sorry maybe that makes me a douche but I would think that that's actually kind of a good example let's just think about it in terms of a UI like maybe maybe something like this would be the long form view so like I don't know like here's a here's a record album from some happy dude and here's some here's some text from that album and here's a button that takes you to album and then there's there's a short-form view where maybe we just take this image and we overlay maybe some title above it of course we should have had some title here just to make it a bit more complex actually let's add the title here just to make it a bit more complex so here is the title in color that so this is the title as well now I didn't draw it that way but let's say that size would be different so let's say that the image here is smaller and maybe we're displaying this on the web so we don't want to take so maybe if this is I know 150 times 150 pixels we don't want to take a picture that's 300 for example times 300 pixels and then scale it down we actually want to show the 150 150 image and here we instead want to show the 300 times 300 pixel image so I mean this is just some arbitrary stuff but I'm trying to emphasize that there are different views right let's call these views so let's call this this is the long-form view and this is the short-form view but then we also have the different media types so let's make it make it simple let's just think about yeah let's let's just make it super simple let's just think about artists and the books let's say so an artist as in a musical artist right an artist that has a song and we have a picture of the artist and the artist has a name it could be a band of course but whatever and then maybe a biography and the book has a title and again an image and maybe the cover text of that book so they're similar but they're also different so what we're saying now is that we want to be able to take any arbitrary media type actually I should stop saying media type since media type actually means something in regards to the web so so the lessons that say a resource or or even media resource so these things are media resources and these things are views there are ways of representing and what we want to be able to do is we want to be able to take any arbitrary resource and combine it with any arbitrary view I mean that's not a strange requirement right we want to take any of these and combine it with any of these so an artist can be displayed in this way or in this way but a book can also be displayed in this way or in this way if you think about it now this is what we talked about the Cartesian product if you think about the Cartesian product this means that we have what pairs it means we have long form artists we have long form book we have short form artists and we have short form book so if we would build this sort of specifically we would need four classes some sort of glancing over a bit of the details because we haven't literally looked into the scenario in detail but the key point the point here is of is of course that artists for example behave differently from books think of them as adapters so what if the artist isn't actually the artist object but the artist is and here is an artist resource that adapts to the read from the art from the artist interface to the resource interface and the book does the same thing for books so it adapts from the book specific interface to the resource specific interface because resources need to have a uniform interface and views need to have a uniform interface if we're going to make the bridge pattern work so any particular book resource perhaps contains a reference to a book object and the book object maybe has a method that gets you the back cover text and maybe an excerpt so like an excerpt from the book a short snippet from the book so those are two methods that are book specific so the book resource maybe needs the call book dog cover text for example whereas artist does the same thing for artists so artists maybe has a reference to an artist and it calls Dalt bio for example and saying bio to denote biography so you can get the biography of the author and that's that's an artist specific thing so so again like maybe there is this is not necessarily part of the pattern now I'm just giving you a lot of context so that we can have an exam that makes sense but so maybe you have two other classes one which is an artist for example in one which is a book right so this is an artist media resource and this is a book media resource not an actual artist or not an actual book right so this is a resource this these are part of the resource interface but maybe then again we have an artist and we have a book and these two things don't have anything in common or I mean they might have things in common but they're not sharing a common ancestry they are not interchangeable you can't just take an artist and then exchange it for a book and I guess we could have very good reasons for that it would be potentially dangerous to say that artists behave exactly as books think about the interface segregation principle the interface segregation principle states that clients should not be forced to depend on methods that they do not use so books should not be forced to depend on the method by oh just because artist wants to have the method by oh because books don't have biographies authors of books have biographies for sure but books don't have biographies so we might have very good reasons for not mixing artists and books like they might actually be separate but in this scenario we want to be able to somewhat equivalently treat artists and books in order to extract some pieces of information and that's when we treat them as media resources so a media resource that contains an artist is an artist media resource and it's in some sense just adapting over an artist and a book media resource is adapting over a book so the reason I introduced this sort of adaption portion of this example is that it's necessary for the example that the artists media resource is different from the book media resource their implementation needs to be different otherwise there is no point in having the bridge pattern but let's now move on so in this particular example if we built this using the bridge pattern this would mean that we would have four classes except for the abstract classes or the interfaces we would have an artist mini resource and a book resource and we would have a long-form view in a short form view so we'd have four classes in total if we would not do this using the bridge pattern we've instead just building a class for every item in the Cartesian product of these two sets we would also end up with four classes probably but again the key point is that as we extend it if we would add another thing here we have artists then we have book but what if we also add album or as we talked about before what if we had author then that would mean that the Cartesian product is now four times two right previously we had two times two giving us a total of four classes that we had to build but as we've extended this now now that our media resources our artist resources book resources album resources and author resources in other words four and then we have two types of views to then the Cartesian product of that would have to be four times two in other words eight so we'd have to build eight classes but if we stick to the bridge pattern approach we simply have four types here we have two types of here so instead of having four times two where we have four plus two just six so less or fewer and as you scale this up the payback gets more apparent of course this all assumes that there is something in artist that is specifiable without knowing whether the artist will be combined with a long or a short form view conversely it also requires that the long form view in other words the views that there is something that is specifiable for that thing without knowing whether it will be combined with an artist or a book so we need to be able to specify artist resource nests in isolation and we need to be able to specify view nests in isolation and then let the view delegate down to the resource whenever it needs to access some information from the resource so think about this this is what we were doing we would say there is the notion of a view it doesn't matter whether it's the long form or a short form the notion of a view entails two things one that it is show wobble it has a method called show for example the second one is that it has remember that we did when we drew the bridge we said that this abstraction has one of these abstractions and that's what we're talking about here the view has a resource I'll just put resource here so those are the two things that we're demanding from the view and what we're demanding from the resource is that the resource have a unified interface in other words here were not coupling to any particular concrete resource we are coupling to the notion of a media resource we're coupling to the abstraction media resource this means that we can create any number of different views long form view short form view scrollable view pop-up view whatever whatever and the view is responsible for asking the media resource for information whenever it needs it so the media resource will expose a bunch of methods here we said that artists not artist resources but actual artists have the bio method and books have the cover text method but if we try to generalize this this notion is maybe something like a summary or a snippet let's call it a snippet so a media resource may be defines that and then I don't mean a concrete media resource I mean the media resource interface says that the notion of being a media resource requires that you expose a method called snippet so you need to be able to ask a media resource what's your snippet and the artists media resource will ask its underlying author for the bio while the book will unmask its underlying book for the cover text but in terms of a media resource we refer to these as snippets which means that the long form view if we talk about it concretely the long form view since is a view it has a resource and since of view has a resource it can delegate to the resource that it has it can ask the resource let's say that it's an artist resource when when it needs to display this text it can delegate down to or if you think about the bridge over to rather rather over to than down over to the artist if it's an artist and ask it for its snippet the same thing goes for the short form but the short form actually the short form doesn't want the snippet so it simply doesn't ask the media resource for the snippet and if you think about the interface segregation principle we are now not breaking the interface segregation principle stating that we should not be forced to depend on methods that we don't use because that states that when you have an abstraction and multiple concretions of that abstraction let's say there's the abstraction a and the concretions one and two then the abstraction a should not define methods that one does not want methods that are uh applicable for one just because two wants them so the interface is segregation principles trying to Zone down on issues where we're we're using inheritance in an improper manner like if one doesn't want to have a particular method why do we say that it implements the interface a if a if a Ness is defined as implementing this method in this method and one only wants one of these methods then why are we trying to say that one is an a it's not if it doesn't actually want both of the methods there's a slight divergence but the point I want to emphasize is again that the fact that the short-form view don't use the the snippet method from the media resource does not mean that we're breaking the interface segregation principle because it's not that the short-form view does not want to implement one of the methods that it's forced to implement from above it's that the short-form view has something and it doesn't want to use all of the things that that the thing that it has as loose or this very confusing thing about the bridge here are the views and here are the resources and what we're saying now is that some of the concrete views don't want all of the methods that the resources define so resource Ness is defined as having this method and this method and this method but if we look at any concrete view they might only be interested in one or two of all of the methods that define a view miss and that's not breaking the interface aggregation principle okay so I want to redraw the UML diagram but this time around we're going to draw it and use the terms that we've used in this example then I want to quickly look at some pseudocode but before we do those two things I want to quickly just mention again how we would probably approach this if we didn't use the bridge pattern if we instead had to actually use this Cartesian product we would probably end up doing something like creating the class long-form artist resource and then long-form book resource and then short form artist resource and then short form book resource and of course this would just get worse as we're adding on more resources and more views perhaps more importantly though than the whole complexity point is what we talked about before when we said that the important point is that there has to be some resource nest that is specifiable outside the context of which view it will be viewed in conversely there has to be some munis some implementation details of a view that is specifiable without knowing what underlying resources we'll use and this is really the key point this is kind of back to if you watch the first strategy pattern video about sharing behavior sideways the really really devious problem about going down this Cartesian product route is that there is some behavior that is the same that is duplicated across this long-form book resource which is kind of indicated as as we can see by the repetition of the name like this notion of long for meanness is duplicated across long form artist resource and long form book resource so when we want to change the notion of long form let's say we accidentally introduced a bug in the in the long form code we have to go to two places and change it because it's not just that the long form is broken it's that the long form code that's embedded in the long form artist resource is broken and the long form code that's embedded in the book Reese long from book resource is broken and and again if we had more things like I mean it might be completely reasonable that we have artist and book and album and author and song and playlist and whatever whatever we would have duplicated that called over a lot of places I mean we'd scatter that called and I'd say probably that's the really important thing that we're trying to avoid rather than having to create lots of classes I mean if we created lots of classes that actually do specific things that do different things then we can't just share I mean it doesn't matter if the Cartesian product is large if if there is no actual underlying structure to the way that the behavior split how could we possibly merge it I mean if it can't be composed it can't but the key here is that we have behavior that can be composed we can extract it into reusable pieces and then reuse it so we should really do it if you're facing a Cartesian product problem and you can't actually compose behavior if there isn't actually any and you sort of reuse across I think this is more a problem that's suitable for visitor pattern but I might be wrong and I guess we'll see that when we dig into that pattern in more detail in the future so remember to subscribe so that you won't miss that stay tuned but now it's really about time to redraw the UML diagram so let me just remove all of this stuff so there's been quite a lot of repetition so I'll move fairly quickly so that we can get into the cold here's the thing let's redraw the bridge we had abstraction number one and abstraction number two I'm leaving some space over here because we might actually want to introduce the adapters to make the scenario bit more complete then we had a number of concretions here and a number of concretions here and then we had an implements arrow here an implementer is an arrow here and a has an arrow here let's now put down the names previously we talked about this as the abstraction the concrete abstraction the implementer and the concrete implementer so an abstraction has a single implementer but an abstraction is abstract so for an abstraction to be used we need to use any of the concrete abstractions so here we could have multiple concrete abstractions and an abstraction has an implementer but the implementer too is an abstraction so any concrete abstraction here needs to actually have any concrete implementer and again we're saying any because we might have multiple implementers but let's now use the terminology that we used in the different example so these would be views and these would be resources I'm saying resource instead of media resource just to save space and then this first view could for example be long form view and I'll just put long form to save space and then etc etc I mean the second one could be short form view and then the third one could be snippet view or thumbnail view or whatever I mean we have a bunch of different views then over here on the resource end on the resource portion the concretions of a resource what are these well this could be for example on artist resource but remember we had artists we had books we could have movies we'd have songs or playlists or whatever but here's an artist resource and this is outside the scope of this pattern but I just want to say that when we talked about the whole adaption portion when we were in this end of the whiteboard we said maybe the artist actually adapts over an artist then I really meant a concretion so let's say that we have a concretions all artists then this artist resource would have an artist and not an abstraction that is shared amongst these resources I mean hypothetically it could be right but but that's not necessarily the the point here so and if the second one was a book resource we have another class which is a book another concretions and the book resource has a book so the artists resource adapts over an artist and the book resource adapts over a book again though those pieces we use just to sort of make a more complete example but the point is that the the artists resource is somehow behaviorally different from the book resource and so forth across the resources there is some behavior that is fundamentally different as well as here right the point is that there is no sharing across these concretions that the lone form is fundamentally different from the short form and this is really it except the methods so we didn't really talk a lot about the methods but but I think we mentioned something like this we said that the view has a method called show and let's say that it returns a string which is the HTML representation of this of this view just an example but it returns a string and it's called show takes no arguments so let's say that this view is an abstract planet rather than an interface because then we can specify that this view has as a constructor so let's say view that takes an argument which is a resource so to construct a view you need to pass it a resource which means that this view upon construction definitely will have access to something which behaves as a resource which means that any concrete view can as we talked about before delegate to with any of the concrete or can delegate to the concrete resource that it has access to and then if the long form is an implementation of this abstract view we will here override string show we will here override so here we just specify that to be a view you need to have the show method and here we say a long form view has some particular implementation of the show method and so forth for the others the the short form view will have a different implementation the the thumbnail view will have a different implementation and so on and so on on this side we didn't really talk much about the interface but we mentioned the snippet method and we talked about the image as well so let's say that it also has an image sorry I'm not specifying the return types because it's not super relevant but let's also say that we have what think we have in that picture I mean we had a title right so a title I guess we had a link so maybe we have a URL as well some stuff like this right so this the notion of being a resource requires you to implement these methods and since the view then couples to the abstraction resource any concrete view can then be certain that whenever it has access to a resource whenever it has access to any concrete resource that resource will be able to respond to these methods it will be able to somehow give it a snippet somehow give it an image somehow give it a title or URL and and those concrete resources they are responsible for how to actually implement that so this we would probably make an interface let me just put I as an eye resource here to denote that it's an interface so then all of these different resources concrete resources such as for example the artist resource need to implement these methods so it needs to implement snippet image title and URL like so and the same goes for all of the other resources and that's really it so to go back to the definition from this book that states that the intent of the bridge pattern is to decouple an abstraction from its implementation so that the two can vary independently I guess that's what we've done here I mean again I'm a bit confused about this I don't want to dig too much into that if somebody has a good explanation please do absolutely shoot that in the comments that we masse to be appreciated but I mean so I guess these implementations now vary while the abstractions vary something like that I mean again I'd say that this is a pretty strange statement I think it makes a lot more sense to just think about it as says that we have two inheritance hierarchies or two polymorphic hierarchies we have sort of the views and we have the resources and views have resources and you can compose any view with any resource so there's a book called design patterns explain simply that's available on the site source making check out the link in description it's super good and the guy who wrote that book says something along the lines of that the bridge pattern separates the platform-specific from the platform in the pen and anything that is more of a sensible way to see it so we're separating the platform-specific stuff from the platform-independent or maybe I should say the platform dependent from the platform independent so lots of examples of bridge patterns or from you is that you're trying to make a platform independent and probably this is why we're talking about platforms so like we separated the stuff that is specific we separated the stuff that is artist specific and we have stuff that is book specific and stuff that is playlist specific so we've separated that into its own inheritance hierarchy where we keep all of the specific stuff but then on this side we have the platform independent stuff we have the stuff that's the same across the board like regardless of whether which one of these platform specific solutions you have you can always do some particular things like you can always I mean when we want to display a resource in a long-form format that long-form format largely looks the same there are just some specifics that are different than the specifics that are different is whether we're getting some stuff from an artist or rather been getting some stuff from a book but there is really a lot of stuff that is independent that is platform independent and that is again like the view actually actually looks like something and that view is is sort of the same regardless of whether we're displaying an artist or a book so that explanation I think also kind of it makes a lot of sense so before we wrap this up we'll have super quickly look at some pseudocode okay so let's start with the abstraction in other words the view so we've got an abstract class abstract class called view that already has a constructor public view the tanks from that side that we haven't specified yet something which is and let's specify eye resource so not just resource we'll actually explicitly say eye resource to denote that it's an interface it takes an eye resource let me call it or just to save space I'm terribly sorry about that and what this constructor does is that it assigns to an instance variable it says this don't resource equals this R that we were passed close the constructor and then I need to specify this variable so the abstract class view has an instance variable that is of type I resource resource and is called resource hmm no space okay good start then the view needs to have a method which we mentioned before which is show so we needs to have a public method that returns a string remember we said it returns a string because we want an HTML representation in a string format may be not a sensible choice but whatever it's just part of the example bear with me so public string the name of the method is show and it takes no arguments because it already has all the stuff it needs and we have no implementation because we need to override it in the subclass now maybe you need some other syntax here in order to define that it's a method that needs to be overridden but whatever it's pseudocode that's it for the abstract class the abstract class has three pieces it takes a resource through the constructor and it sets that resource to its own instance variable of type resource and then it specifies that to be a view you need to implement the method show next piece the specify the first you so one view would be let's only specify one we say a class which is let's say long form and I would name this long form view but in order to save space let me just say long form so the class long form is a view open that up so because it is a view it gets this constructor which means that it has access to an instance variable which is of type resource and is called resource but we need to specify we need to override this method show so let's say public override string because it returns a string and it's called show it takes an argument because it has all the data it needs let's open it up and what does it do let's not care about that here constructing this HTML would probably be a bit tricky and I mean it depends completely on what you're doing in your scenario but the key point right the key point of what happens here is that the long form would access let's if we I remember correctly from the image we drew before would access the image the title the snippet and the link I won't put out all of these right but let me just put one so that says so that well at least we've touched upon one of them so what it would do is that it's somewhere in the body of this method would access this thought resource in other words the resource that it was passed through the constructor this third resource dot snippet for example because that's the one we talked about the most so it would access this snippet and somehow make use of it so that it in the end can return some HTML string here so this this method let me close this here so the method show does a bunch of stuff and somehow interact with this resources that it's been passed and at the end the construct some HTML and then returns that HTML let me just close the long-form class as well so again and then we would do the same thing we'd have another one which is short form we'd have another one which is thumbnail and essentially they all do the same thing they implement the show method but in the show method they have their own magic they have their own way of displaying something and that's the point that's what we're trying to encapsulate in one of these in one of these views the specificness of of this particular concrete view so that's it for the views let's now move over to the concretion I mean this was the abstraction in the bridge this is the left side of the bridge in the other end of the bridge on the right side of the bridge what do we have here so this was the abstraction and I'm on the right side we have the concretion and the concretions or the implementation I should say the implementation we specify the we call the resource so let's let's begin by defining this interface by resource so we have an interface interface called I re source we open that up and what does it specify well we've already enumerated what it specifies before but what it specifies is that to be a resource you need to respond to some set of methods these methods are you need to return a string when I call the method snippet and a string when I call them at the title previously we didn't specify the types but now I'm specifying the types and then let's say actually also a string when I call image say that the the string is a URL to that particular image and then finally also a string when I call URL so what URL do I want to visit when I click this resource and it closes up and that's it for the Irie source that's it for the resource interface so let's do the same thing on the implementation side as we did on the abstraction side let's only write a single concretions of this abstraction resource and let's pick artists because we probably talked about that the most so there's a class called artist resource this time I'll specify resource just to make sure that we're not confusing it with any potential artist class so an artist resource that implements the interface eye resource and it's open that up and what does it do well this is super specific to this particular example but I mentioned in that in the example what we did is that we had an artist resource that adapted over an artist so this is not part of the pattern but in our example our artist resource would probably have to specify a constructor let's say public artist resource and in the constructor it would take an argument which is of type artist let's just call it a to save space I'll open up the constructor and then I would send this Dalt artist equals a so I set an instance variable called artist to whatever artist I was passed in which I called a here so that specified the existence of that instance variable as well so let's say that there's an instance variable of type artist that is called artist not specific to this particular artist resource because we said that the artist resource needs to delegate to a specific artist in order to get the information that it needs and and the reason we did this is that we wanted the resources to be different so it's just as a part of this example and then this resource need to implement all of these four methods snippet title image URL so let's list only do snippet so you would say public it needs to return a string and it's called snippet it takes no arguments and it has some implementation and what's the implementation actually we talked about this implementation before the snippet method simply delegates to the underlying artist so it has an artist here as as an instance variable that we got passed in through the constructor and now the snippet simply delegates to that arsed artist instance variables we say this dot artists don't bioW so in other words the snippet of an artist resource is the biography of an artist sorry I should of course a but return here so let's actually write return this dot artist dot bio invoke the method and then we'll just close this method and then it's the same thing for all of the other methods so the artists resource needs to implement title needs to implement the image needs to implement URL and it would be the same thing so let's just for the sake of the example we would say public string title takes no arguments let's open that method up and this method returns a string and how it gets the string is that it takes something from the artist so it says it to says this Dalt artist and then it asks the artists for let's say its name actually maybe we would even say this not artist to save space I'll just say F name to denote first name and then we say +1 space as a string literal here and then plus this dot artist dot M name as in last name and it will cost this method so the artists resource implements all the methods that it needs to implement since it is a resource and the implementation of these methods depend on what this artist resource actually does or I should say depends on what this resource actually does and this particular artist resource it adapts over an artist so the snippet when we ask it for its it snippet it's asking its delegating down to the underlying artist and asking it for its bio and when we ask the artist resource for the title write the title that we want to be able to use in for example in you then we're delegating down to or over actually constructing a new string here that's composed of the first name and the last name of all of the artists so so you can easily imagine that we if we also now add a book resource title would perhaps be different because we would then simply grab probably grab just the title of the book so there's no need for that concatenation and and actually the snippet would would be different as well because we're probably not asking for a bio we'd ask for I know we'd actually maybe ask for a snippet or maybe we'd ask for the the back cover text and and all of this stuff doesn't really matter in terms of the powder and the point is that every resource is potentially different every resource does a different thing and in our case we had resources that adapted over some other particular concrete class so just to recap we have two inheritance hierarchies or two polymorphic hierarchies on one end we have the view and on the other end we have the resource and in more general terms in one end we have the abstraction and in the other end we have the implementation and if you sort of squint you'll realize this looks exactly as the UML diagram that we drew in the beginning or multiple times actually so here is the bridge right this concretions inherits from this abstraction this concretions inherits from this abstraction and this abstraction has this abstraction so the view has a number of different concretions the resource has a number of different concretions and every view needs to have a resource which means that every concrete view will have some concrete resource and through that we can then compose different combinations of views and resources and the point is that we've then been able to separate the platform-specific from the platform-independent so some stuff is specific to an artist resource but when we want to display an artist resource there is a lot of stuff that is shareable across different resources so if we have an artist resource and a book resource doing the sort of layout stuff when we had this when we had this layout with the title here and an image here and some text here and some button here that actual layout logic shouldn't be nested within this artist resource because then we'll have a class explosion and then we're back into that Cartesian product problem instead we should say that let's keep that layout stuff general and say that that Liam stuff simply interacts with the resource regardless of what that resource is and let's call this of you so generally it's a view but specifically this particular view happens to be a long form view and this long form view interacts with the underlying resource or our sorry I should say interacts with the resource that it has delegates to the resource that it has been passed upon construction because it is responsible for simply constructing this view or constructing this layout what to actually put in this in this sort of location or this this in this place where we want to have an image what to actually display there right what the URL is for that image it doesn't know because that's not that that's not part of being this long form view being part of this long form view is simply just knowing that there needs to be an image here but what that image is is a concern for a resource so if we pass a view a resource then the view can ask the resource for that information it asks the resource for the information that it needs in order to construct this particular view alright hope that makes sense this pattern actually kind of blows my mind it's like I struggled to figure out an example but then when I figured out this example I thought wow this actually makes a lot a lot of sense so actually I would eventually guess I mean I'm really just guessing now that this pattern actually is applicable in lots of scenarios where we potentially wouldn't think that it is applicable if we just sort of look a bit under the surface and then think really hard on it probably there are a lot of places where we can actually make use of this pattern I mean if nothing else this is really just a very interesting pattern in my humble opinion so I hope you now feel that you know the bridge pattern if you don't or if you have any questions or if you want to dig down further into something please do absolutely shoot something in the comments always massively appreciate it if you like this video or any of the other design pattern videos I usually don't say this but remember to share with your friends if you think it's good that's massively appreciated beyond that remember to subscribe so that you won't miss the upcoming pattern since the strategy is to go through all of the patterns in this book we have tons of patterns left to go through I appreciate you sticking around to watch the video thank you very much for watching and I'll see you in the next one well

Channel: Christopher Okhravi

Views: 96,137

Rating: 4.9368091 out of 5

Keywords: design patterns, head first, head first: design patterns, bridge, bridge design pattern, bridge pattern

Id: F1YQ7YRjttI

Length: 52min 3sec (3123 seconds)

Published: Mon Sep 11 2017