Decorator Pattern - design patterns (ep 8)

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
so today we are going to talk about another of these object oriented design patterns called as decorator pattern so in our tennis complex booking application we have a class called as cold booking it's an abstract class so I'll make it in italic right it has one field info one method get info and one abstract method cost this cold looking glass is has concrete implementations such as hard cold booking clay cold booking grass cold looking product these concrete classes will implement the cost method right so cost for hard cold booking will be a bit different than cost for clay code booking then cost for grass for booking perhaps this will be the costliest so this is the initial arrangement right now the tennis complex owner wants to add new functionality for example they decided that along with the cold booking what if the users or the members want to have brackets on the rent or what if they want to have tennis ball on for rent when they are playing or what if they want to have a coaching session as they are booking the code right so this requirement came afterwards right initially we had this much functionality and then our tennis complex owner or board decided to introduce that new functionality of providing our tennis balls rackets and the coaches now how do we accommodate this change or new requirement new functional requirement so one approach could be we can keep extending from the cold booking and say racquet ball back right we can say coaching right also extending and they will have their own cost coaching will have certain cost baalbek me a certain cost and racket a certain cost but this doesn't doesn't feel like a good design solution imagine tomorrow the tennis my complex management decides to add a few more features few more services available to members then we got to keep on adding children classes to the to the cold booking abstract class doesn't feel like a good design it's not it doesn't look like manageable solution and further there's no direct relationship between booking and rackets or ball back and coaching right like this is probably going to need a concrete instance right coaching will have certain booking I mean you cannot have coaching without cool looking all right or you cannot provide rackets for rent without actually doing some kind of grasp or looking or click on looking so this is not a good approach although it can work I mean programmatically speaking yes this can work but I don't think it's a good design solution moving on another solution could be now that we know the number of services that we are going to provide what we can do is we can add those services in our base class okay now rackets ball back and let us say coaching variable here right I can implement the cost method here on you know right so this cost method will be something like if rackets equal equal to true then add let's say 50 bucks if ball back included right then add 100 bucks if coaching required right then maybe add 200 bucks so this is my cost method in my base class right and now the concrete implementations will have will all the parent class cost method this will be like hard code booking really for 200 bucks plus parent dot cost or you can say I guess in c-sharp it is based not cost or something like that right so they will have these networks will call the parent class cost measurement because be it kicks for all these right so this is one solution we can have looks like a good solution it is inheritance based solution there is a code reuse right but it also suffers from certain problem for example what is tomorrow the management decides to add another new service for example floodlights you want to have a floodlights that means you want to play at night hours or let's say umpiring services they'll also provide you umpire for keeping the score and making the calls let's say they want to give you Hawkeye services you can challenge certain points okay we are going too far now but yeah what what happens when we want to introduce new services and that is the first problem probably what we will have to do is let me make Chi add that code here for example umpire all right and then you'll have to modify this cost method here say if umpire then add another 200 right but is it a good idea you remember our solid principle open for extension closed for modification so is it a good idea really to keep on changing the existing code in order to accommodate the new requirements I don't think so right so that is one issue second what if tomorrow we decide that racket cost will be increased from 50 to let's say 200 right so we want to change existing services in that case again we'll have to go and modify this code this cost method implementation in the base class we'll have to change this from 5200 right again it is violating our principles we are changing the existing code in order to accommodate the new requirements one more example could be you want to remove any existing service you want to remove compiling service now umpire make some bad calls the members had a quarrel with the umpire and racket they hit the umpire with the racket and it was a police complaint and all that yeah it became it got messy alright they want to know it all to provide this impaired service anymore again you got to go back to your code go back to your base class change this code remove this method at the move improvise this cost method again remove that if condition of umpire from there again test it and hopefully it will all run fine without introducing new errors to more issues I can see is that let's suppose somebody's doing a click you looking right and that fellow has a partner for playing with him that fellow has rackets they have lots of foot and his balls and then the plate is for many years so they don't need racket they don't need ball pack they don't need coaching they're only a bad they don't want doesn't need any service at all so yeah I mean that kind of scenarios are pretty common so in that case this is all code is for nothing this is like a redundant code in those cases where people don't want these services so then another scenario I can't think office some user is doing glass cold booking they want more than one ball back there's only one ball back here right what if they want to ball backs or let's say three ball backs yeah they are playing doubles so they want more balls or what if somebody requires two pairs of rackets right so what how will you complete that so I mean you will go and change you maybe you can add another variable called X quantity for each each of this each of this rackets ball back and coaching but again you are going and changing the existing curve for accommodating new requirements yeah you are violating the solid principle so again I think this is a really bad bad design so the problem here is that we are using inheritance to solve this issue but the problem with in here is that the code is the behavior or the functionality is syntactically at the compile time that means once you write this cool it is not this functionality is not the room for maneuvering or room for changing it is very less because it is compile time binding everything right but that comes all these problems that we just discussed what if this what if that what if this what it that composition could be really handy here the benefit with composition is that it uses scope to change or to add new behavior dynamically at runtime by providing new classes by providing new instances so for example simply let's say this is your cold looking I'm just taking example right and it has one composition it is composed of some service object let's see right now this service could be anything this service could be ball back or rackets or coaching right so dynamically at runtime you can substitute with this service with any of these right something like that so that is the advantage of using composition dynamically you get much more freedom you can change the behavior by changing the behavior of subclasses you can add new subclasses and something like that alright so that is the basic advantage that we can get by using composition instead of inheritance I am going to solve this problem using the patterns design pattern called as decorator design pattern so how do we do that let us see so in my decorator pattern my code booking parent abstract class will remain as it is it will have info element little number and do now get info method which will be overridden by the child classes and it will lower cost abstract method right it will have one method cost abstract whose implementation will be provided by hard code book e-liquid looking in cross cooking now talking of services that is ball back or rackets or coaching right they will be called as decorators in this pattern there will be decorator and there will be another abstract class Tellis decorator Timmy's decorator will also inherit from cooking and now we'll have our concrete services over concrete decorators as Sola baalbek we'll have racket let us say Kuching right they will all implement the cost method see this is extra cold booking class it has an abstract cost method this tennis decorator class is not providing implementation for the cost method that means the implementation for cost because this is invigorating and this is eliminating that this implementation of cost abstract method has to be provided here so these guys will provide the implementation for cost yeah so Baalbek will now some hundred rupees or racquets will have 200 and coaching will have 300 something like that cool now this is basically our class diagram right so this our decorators these are called as decorators and these will be called as decor rated objects so these decoders will be correct decorated objects how the decorators should have the same super type as that of the objects they are going to decorate so here these are going to decorate these objects right so they should have the same super light so instead in this case it is cold cooking eventually they are same super Thomas cool-looking Oh chips can be decorated at runtime with as many as decoratives as you want so any of these objects can be decorated at runtime right using as many as these decorators that is clay cold booking can be decoded reducing ball back rackets and coaching and let's say grass code booking one object can be decorated using two world bags three records and one coaching so there's no limit it is happening dynamically at runtime how I'm going to show you through code let's say one member comes to the tennis come and says he wants to he or she wants to do grass coal booking I'll draw it diagrammatically first right so we'll create an object of grass code buki cross-court booking and it will have some cost let's say it is 100 now at the counter when he or she is doing the booking we ask him do you want ball back yes he wants world but he or she wants the ball back so we will decorate this grasp or booking object using the ball back object so it's a ball back right it will have certain cost that cost let us say will be 100 they want racquets so will they code it this with a racquets object it will have its own cost let's say 200 so eventually when you calculate the total cost you will start from the outermost decorator that is rackets the eventual cost will be 200 plus 100 plus 500 that is 800 right so this is how it looks diagrammatically now let's see how it is implemented programmatically so the one thing that I missed showing here in my class diagram is that in my decorators right this is ball back right so in my decorators I will compose instance of super high so I'll say cold booking so they will compose of an instance of super type I'll tell you why we require this so it here also will have cold booking and here also one instance of code to keep it is composition they will have code book again data member right all this decorative classes now let's write that code that we saw diagrammatically public static void main right method the member comes to the counter and says he or she wants to do grass cold booking so we'll say cold booking cool booking booking one equal to new grass cold booking crater grass pool looking glass now we ask them do they want the ball back with the bookie yes we want to bulb it so you'll say now CP 1 equal to new ball back and you will pass this CP 1 as a argument and this will be assigned to discomposed cold booking code booking instance this would be a sign there right you'll see the magic now just give me one more minute then we say do we want the rackets to play they say yes so we say now CB 1 again equal to new rackets again we pause the CD 1 this will be 1 here cool and then we ask would you like to have watch with you to guide you they say yes so hooligans is CB 1 equal to new coaching again will pass this decorated Sydney 1 here alright see how we are decorating it first we had a grass court booking object it has cost of 500 rupees all right then we the member required pole pair so we decorated that grass code booking CB one with both that we decorated with both that we got the output in the form of decorated cb1 then be a decorated dad CD one with racquets right and then that's will be one with coaching now a print total cost the latest decorator the last decorator the object is CB 1 CB 1 . cost so now ok so I'll write this again here right coaching coaching decorator will have a cold booking instance right and a cost method implementation so the cost will be coaching cost we're 500 right 300 plus the composed objects CDOT cost right similarly it will have a composed cold booking it will say cost the ball pack was 100 rupees plus Z dot cost right and your rackets will also be similar it will have one composed object of code booking and the cost method will say 200 plus Z dot cost right now when we call this CB 1 cost right there will be coaching so it will come here 300 plus Z dot cost explained here the first call is the latest college new coaching so we'll say CB underdog coaching the cost method for coaching that is 300 plus C dot cost the composed object what is the compost object for new coach e CB 1 that is this one which was this racket right so rackets cost method so we'll take this call here racket right 200 200 plus C not cost the compost objects cost what is it the most object for rackets cb1 this CB 1 which is nothing but ball back so it will call ball paths cost 1 West Coast is hundred plus composed code booking.com so for ball pad it was original cb1 that is grass cold booking so grass called booking cost method was simply returned 500 right so it will return 500 so this is 600 now this call is complete it will return 600 this code is complete it will return 800 and this call final is complete which will return 1100 as the final outcome are you getting it it's amazing right it's just it's like a recursion in your C program right so this is pretty much the decorator pattern again the advantage tomorrow you can have new decorators so you can have umpires Hawkeye lights right you can add here we only added one different to each of type callback sorry Wolfpack rockets and coaching we could have done like we could have used new ball back again we could have decorated cb1 with both back we could have used this two times these two times these three times this is run time right it depends upon the choices made by the member at the counter all right it's pretty dynamic it's pretty loosely coupled and it's fantastic decorator pattern I hope you got it and I'll see you in the next video with a new design pattern
Info
Channel: BBarters
Views: 30,325
Rating: undefined out of 5
Keywords: decorator pattern, decorator design pattern, design patterns, object oriented design patterns, decorator pattern example, what is decorator pattern
Id: XihyLU6MhzY
Channel Id: undefined
Length: 20min 59sec (1259 seconds)
Published: Tue Aug 08 2017
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.