Design Patterns for Beginners - New Version

either welcome to this course on design patterns I am Ranga Rao carnem and I have more than 15 years of experience designing architecting and developing java applications in this course I would want to give you an introduction to the world of design patterns in my experience I have seen more instances of design patterns being abused compared to design patterns being properly used you might ask why this course the objective of this course is not to teach the implementation details of each design pattern not far away from it what we want to understand in this course is the context in which a particular design pattern might be applicable we would discuss this with real-world examples if you are familiar with what we do at in twenty eight minutes this course would be a deviation typically our courses would be 90% hands-on and 10% theory in this course we would really want to focus on the context of each design pattern we would be talking about three different types of design patterns creational structural and behavioral there are about 23 different design patterns which are present so we would be talking about each one of them a little bit of programming experience with Java might help you we don't really consider it mandatory a huge percentage of the course you don't really need any technical experience at all we are really excited to bring this course if you're as excited as we are go ahead and click that enroll button or you can take a test drive using the free preview feature see you in the course what are design patterns we have been building object-oriented software for almost 40 years now small talk was the first object-oriented language the programming world has encountered a load of problems and they have tried a varied range of solutions for them some successful but some not so successful and attempt was made by a group of four people famously called the Gang of Four to come up with a list of common problems and the solutions for them in a given context and this catalogue of common problems and their solutions are what are called design patterns the advantages of design patterns are quite clear you don't want to repeat the same mistakes again whatever has been learnt if you have a good understanding of design patterns we would not repeat those mistakes again there are three different kinds of design patterns the design patterns which we are talking about are from the perspective of an object-oriented world so we are really restricting ourselves to the Gang of Four design patterns and the types are creational patterns structural patterns and the behavioral patterns creational patterns deal with the complexity associated with creating objects object-oriented programming is full of objects there are varied kind of objects that we create with varied range of problems and these creational design patterns deals with how you can create them what are the options you have the structural design patterns on the other hand deal with the composition of the classes what does a class contain what relationship does it have with other classes does it have an inheritance relationship does it contain the object of an another class all these kind of design patterns are grouped under structural design patterns the last category of design patterns the behavioral design patterns is more focused towards the behavior of the objects that's basically the interaction between the objects how does an communicate with another object and all these kind of patterns fit in this category called behavioral design patterns in the next series of videos we would be looking at each of the design patterns in these categories in detail we would start with the creational design patterns we will start with the first of the creational patterns which is the prototype design pattern if you look at the prototype design pattern it says a fully initialized instance to be copied or cloned a lot of the definitions of the design patterns might seem very complex at the start but when we really understand them with an example you would really see that they are very very simplified definitions let's consider a game of chess in the game of chess there is an initial setup of how the pieces have to be arranged the king is in a specific place the pawns are in specific places Queen rook Bishop everything has a place that is assigned to them so let's say I am building a software to model the chess game every time a new chess game is played I need to create this structure again and again the initial layout of the bolt I'll need to keep building it again and again instead of doing it again and again can we have an object of that built and have Gradle e available so that whenever we need to create a new chess game we copy from it or we clone form it that's the prototype pattern in a prototype pattern you have a fully initialized instance the fully initialized instance in this particular context is the initial setup of the board so the initial setup of the chess board you would have it fully initialized and available whenever a new chess game is started let's say take the online website chess comm there are thousands of games being played every day I mean actually millions of games every day and every time what they do would be to copy the initial structure that they have they would not keep creating the structure of the board again and again whenever new game is initialized you have an already initialized instance and you copy it in the technical terms that's called cloning so you clone the already initialized object and that the prototype pattern builder pattern is the second of the creational patterns that we would be discussing in here the Builder pattern separates object construction from its representation what does that mean I go out for a multi-course dinner there would be a lot of options which are pleasant drinks starters main course dessert a huge number of options and probably I would choose two or three of them a similar kind of situations arise in software as well you would need to build objects using two or three I mean a subset of the ingredients which are present somebody might need a multi-course dinner with the drinks starters and main course probably they would want to avoid the dessert somebody else might want a drink they want to skip the starters they would directly want to go through the main course and the dessert so the multiple ways people would want to organize or to have the multi-course dinners if I am representing this in software then I would need to be able to create the object in multiple ways sometimes I would need to have only three ingredients sometimes only two ingredients and sometimes only one and that's where the Builder pattern comes in to understand revealed a pattern further we would look at a small piece of code if you are not familiar with the technical details probably you can skip this you can kind of try and understand and try and make sense of what's happening in here the example which we are looking at right now is from a git repository in 28 minutes design patterns for beginners so you can find this example in there you can just search for patter and you'd be able to come in here the example which we took was trying to build a coffee if you are from India then you would always have coffee with milk and if let's say you are in the United States for example most of the people prefer having coffee without milk you would want to be able to have multiple options of how you build your coffee up and that's where the Builder pattern comes in if you look at this particular piece of code what we have is a builder - the Builder we pass in the mandatory things so the type of the coffee that I want is mandatory I mean that's the basic and after that we add in whatever we want so I am building a moocher with milk that I mean I am saying milk true that with milk with no sugar and size large and I am building the object and now I have my coffee ready if somebody else wants a different flavor they can easily build it so now somebody else who wants coffee with milk and sugar can come and say coffee dot builder mucha not mail true not sugar true and size large dot build thereby you have a huge amount of flexibility in building the objects other approaches to doing this other than using a builder pattern but using things like setters have a lot of problems associated with them they result in very difficult code to read as well as they have a few problems in threading will not go into depth with those the Builder pattern solves all those problems the important things about build a pattern are that it simplifies the creation this is very simple code to read and also this is very easy for a developer to write code with if you are interested in understanding how the Builder is built you can look at the public static class builder you go for a builder pattern when you would want to have multiple options in creating a particular object a builder pattern separates object construction from how its represented and it makes it very very easy to build up third in the creational patterns which is the singleton pattern is the most famous of all the design patterns I guess what the singleton pattern does is very clear from its name it's a singleton there can only be a one instance so for a singleton at any point in time they can only be one instance I mean a real good real world comparison would be probably a president of country they can only be one president for a country at a particular point in time just like that they can only be one instance of a single turn object however there is a disclaimer actually when we say something is a singleton it's actually one instance Perl JVM so let's say if I have an application which is running as part of a cluster in multiple application servers then you would have one instance in each of the application servers in that cluster so to be really specific single terms are actually one instance per JVM but for the rest of the discussion we'll kind of talk as if it's only one instance can exist so a class of which only a single instance can exist that your single term there are a few things that you need to remember when you would create a singleton object the first one is your constructor should be private because you don't want others to create the object I mean if you leave a public constructor then what would happen if anybody can construct the object and then you don't really have a singleton so you have a private constructor the best way to build a singleton in Java is using an enum is recommended in the book effective Java as well you can find a sample singleton using enum on the github repository it's very very simple to use a enum to build a single term all that you need to do is create an instance make your constructor private as usual and then you can create the methods which can be called so this would be my singleton using enum dot instance dot retrieve something so it as simple as that and if you are using je7 there is a built-in at singleton annotation so you can probably check that out okay now we have talked so much about singleton but are there any disadvantages yes yes yes singleton makes it very difficult to unit tests so if you have a lot of single turns in your application this application would be a really really difficult to unit test make a clear decision as to where you want to use this singleton and where you don't the last thing we want to talk about is the fact that in frameworks like spring we managed beans and these beans are singleton by default but what spring does very well is the fact that these beans don't need to be declared as single turns I mean if you look at the code for these particular beans you will not realize that they're single turns this is kind of taken care by spring in the background if this technical discussion sounds little complex to you don't worry about it all that you need to know is a singleton is something of which they can only be one instant let's quickly move on to the next design pattern we are going to discuss about which is the factory method design pattern if you look at the definition of factory method it says create a family of object types so let's quickly look at an example I mean factory method is not complex so just look at an example we should be able to understand it very quickly so here we have a person factory method what we are doing I mean not a method actually person factory class so this person factory has a static method gate person and this accepts gender as an one of the inputs so if you pass in M it returns a class of type male and if you pass in F it returns a class of type female but as far as the classes which use this person factory are concerned the only thing they know about is person so if somebody wants to create a male person what they do is they say person male is equal to person factory dot gate person and they pass in M and to create female they would pass in F so basically they would spaz some identifier of the type of the object that you would want to create but they would still be referring to the generic type so we have a person and male extending person and female extending person the fact that there are male and female objects existing are hidden behind the implementation of the factory method pattern so whoever is using this particular Factory only knows about person but they don't really know about the existence of a male or a female class the benefit the factory method pattern of first now is the fact that you can add additional types of gender or additional types in here without affecting whoever is using it so who is using it is only using person so they don't really care about whether male female or whatever you can have different implementations for the same methods in those objects as well so if you look at the gate salutation you have written mister here here it is Miss or mrs. so based on whether it's a male or female if you call the gate salutation you would get a different thing so that's basically the benefit of the factory method pattern what it hides is the complexity in creating an object so instead of somebody else deciding whether you have to create a male or female we have a factory making the decision for us and at a later point in time whenever we want to modify this it becomes really really easy so that's the factory method path let's move on to the structural design patterns the first of the structural design patterns that we are going to talk about is the proxy the definition of proxy says an object representing another object I have a debit card whenever I make a transaction in using a debit card where does the money go from the money goes either into my bank account or out of my bank account so whenever I'm spy swiping my debit card somewhere what I am doing is I am using the debit card as a proxy for my bank account so the actual object is the bank account and the debit card is kind of a proxy for it so whenever I make a purchase I swap it what is actually happening is the money is deducted from my bank account debit card is a proxy for it similar to that in programming you have a lot of interactions with remote objects let's say I am talking to an object which is in a distributed system somewhere outside my system what we would do in such cases is create a proxy object so what the proxy would do is proxy would take care of all the external communication as far as I am concerned I would be talking to the proxy as if it's something which is very near to me the good example for that are the EJB home and remote interfaces a proxy is basically an object representing another object proxy hides the complexity in communicating to the real object the second structural design pattern that we would be talking about is the decorative pattern in the decorator pattern we would add responsibilities to objects dynamically what does that really mean typically in the object-oriented programming we use a lot of inheritance let's say I have ten types of pieces so Pisa type 1 Pisa type 2 to Pisa type 10 and now there is a new requirement I need to make these 10 types available with three different types of toppings I would want pisa type one with topping one pisa type two with topping two pisa type three with topping three I already have ten types so if I add three of each for these ten types then I would have 30 different classes to manage this is I mean inheritance is kind of a static relationship so instead of doing this can we make it dynamic can we add the topping on top of an existing teaser so you have a Pisa and kind of use the topping as a decorator on top of it so that's the concept behind the decorator design pattern so instead of creating multiple types of the same object again and again can we add the additional responsibilities dynamically as kind of a topping a good example would be also adding a discount and an order I already have an order and I would want to add different kinds of discounts on top of the order for example in India we have this thing called Paytm and they have a lot of discount offers I mean if I keep adding different types for each of the discount I would have hundreds of classes to maintain so what they really do would they would would be to add the discount as a decorator on top of the existing order a very good example of decorator pattern in Java is Java i/o so the way we create the input frames so I have a file input stream if I want to make it buffered I would need to create it as buffered input stream and pass the file input stream as a constructor argument if I want to read it in lines I mean if I want to add a line number on top of it the way I would need to do it is line number input stream and pass the buffered input stream as input to it so this is how things are in Java IO this is the implementation of the decorator pattern you can actually look up the code for line number input stream to see how decorator pattern is implemented in there the thing about the decorator pattern is it helps in adding runtime behavior so you are adding behavior at runtime so the user of the interface can decide how he wants to create the objects but that's also the complexity so somebody who needs to use the decorator pattern needs to understand the different structures which are present so it will not be a simple create Pisa type one topping tree it would not be as simple as that so it there would be a little bit more complexity to it so they would be a little bit of complexity in creating the objects that's the disadvantage of the decorator pattern so basically the decorator pattern is all about adding responsibilities dynamically the next pattern we would be looking at is the facade pattern the definition of the facade pattern says a single class that represents an entire subsystem let's take the example of a Event Manager I want to organize an event what I would do is out talk to an event manager and tell him I need this kind of decoration I need this kind of food I would need to send the invitations to all these people this is the kind of music I would want to under a range and even managers would take care of everything for me so these good even managers are very good examples of facades so anytime I want to talk do something I'll talk to the event manager and the event manager would organize that for me similarly when we are talking about a distributed system you would have the need for multiple calls across layers for example let's take the example of an online book order so if I'm making an order there are a lot of things that we need to do first thing is we have to check whether there is stock and then reserve the book the next thing is we have to make the payment update this talk and generate the invoice so if the client interface has to handle all of these individually there will be a multiple set of calls which would be going on and in and out so rather than that what we would do is we would create a single facade I mean single interface which would handle everything so the client would give the give all the inputs to this facade and the facade would take care of making all the calls for us the advantages of the facade are that you would reduce the amount of network calls and also you'd reduce coupling so how the facade works is separated out so the facade as long as long as the interface remains the same the internal details of the facade can keep changing and also one more important thing is the facade kinds of represents the transactional boundary so if you are technical and if you understand transaction management some of the times facades or services are good places to implement transaction management around so that your facade pattern the adapter pattern is used to match interfaces of different classes what does that mean let's take the case of power adapters let's say I buy a iPhone in India it comes with an Indian charger I mean Indian charger I mean something which fits with the Indian electrical system and when I go to us it won't work because the power adapters in u.s. have different kinds of a pin configuration so what I do is out take an adapter so when i am going to US or Europe out by a power adapter to which I would plug in and I would use the power adapter to connect to the line similar to that when I am talking to a different system and the language used by that system is little different I would need to have an adapter to modify what I am sending to the format which is understandable with this second system a good example is probably the conversations between a Java and let's say I am calling a web service before I call a web service from my system I need to convert the object into an XML or a JSON this is nothing but an adapter pattern because where Java systems work is based on objects but the web service expects a JSON so what I would do is I would convert the object into a JSON and send it to the web service and that's kind of an adapter the last structural pattern that we would be talking about is the flyweight pattern there are instances where creating objects might be very difficult and also there will be instances where actually having multiple instances of objects also might make it really difficult because each of these objects might have a lot of memory what we would be creating in the flyweight pattern is a fine-grained instance for efficient sharing a really good example would be a public switched telephone network in a public switched telephone network they would be limited number of lines so let's say there are in lines but there would be thousands of customers who would be using them because not all the thousand customers would be calling at the same time you would be able to try and switch between these ten lines and efficiently manage the network a real good examples of flyweight patterns are JDBC connections in the je world we have a lot of connection pools on the application servers a connection pools is nothing but a set of connections to the database from the application we fire in a lot of queries but we don't create a connection every time a new query comes in what we do is we have a pool of connections already available let's say we have a pool of 20 connections already available so as soon as a query comes in we match it to a connection and then the query get fired and once it query completes execution the connection gets released so we have a pool of connections and these pool of connections will be used to execute the queries this would help us in avoiding the cost in creating the connection and closing the connection to the database every time so we would kind of have a shared pool of connections that's a very good example of the flyweight pattern so basically flyweight pattern is all about creating instances for efficient sharing let's now move on to the behavioral patterns the first behavioral pattern that we would be talking about is the chain of responsibility patterns the best example for chain of responsibility patterns is an exception handling mechanism in most of the programming languages let's say I have a method one calling method two calling method 3 and the method 3 throws an exception if there is no exception handling in method 3 then the programming language looks at method 2 to see if there's some exception handling some try catch block nope nothing is there then it would go further up and further up and further up that's a very good example of the chain of responsibility pattern the wave chain of responsibility pattern is defined is a way of passing a request between a chain of objects let's take a loan approval process the clerk at the bank has permissions to approve loans up to a certain amount if the amount goes above that then his supervisor comes in and there is a limit for him and then the supervisor supervisor comes in and so on so this is a kind of a good example of a chain of responsibility as well in a chain of responsibility design pattern what happens is we have a set of objects or a chain of objects which are already ready I mean this chain of objects handle the approval process for example and whenever a new request comes I would go to the first object in the chain and check will you be able to approve nope then I would go to the second object in the chain and then the third object in the chain fourth object and so on so that's basically the chain of responsibility pattern where a and request is sent to request a chain of objects until it's had the ID rater pattern is kind of the most simple of the design patterns you have a set of items and you want loop around them so the I trait of pattern defines a way where you can loop around the objects in a collection it's defined as sequentially access the elements of a collection a good real-world example of an eye traitor pattern is the next previous buttons on a TV remote as as as and when I keep pressing the next button I would be switching to the next channel and so on a good example of I treat a pattern in Java is the iterator class itself and also we have not the enhanced for-loop and things like that which help us to loop through the collection the definition of a state pattern says alter a objects behavior when its state changes what does that mean let's discuss with an example let us take the example of a fan wall control for example in India we have this fan wall controls with different levels so if the fan wall control is at level 1 the fan rotates at a certain speed and let's say if it's at level 5 it rotates at the maximum speed possible when I rotate the knob when I rotate the fan wall control knob from level 1 to level 2 there is a change in the behavior of that particular object which is the fan so the fan rotates faster state of the fan wall control right now is level 2 and I call a rotate method the state goes to state 3 and if I do again a rotate the state goes to state 4 so depending on the earlier state the next state is decided so in this kind of situations we represent the state of the object as a separate class let's see a quick Java example what we have is a static class which is a fan wall control with a speed level composed in it so this fan wall control has this speed level in the speed level is an interface which has 4 different implementations of speed level 1 2 and 3 and if the fan is off and I click a rotate what does have what it happens the new state changes to speed level 1 and if it speed level 1 I do the rotate it goes to speed level 2 speed level 3 I would go to speed level so from two I would go to three and from three if I do it again I will go to off so this is kind of an implementation where we are actually pulling off the state of the particular thing so the state is the current speed level so speed level one speed level two speed level three are different states in which the fan level fan wall control can be what we are doing is we are making this state a specific class on its own and thereby the fan wall controller does not need to know about what the current state is so it just says speed level current and whenever somebody calls rotate it delegates the rotate call to the speed control so thereby what happens is if I add in a new speed level all that I need to do is define US v speed level or a fourth speed level and implement the rotate method this is a very good example of having extensible classes in the example which we looked at based on the level at which that particular object is in the behavior changes so if it is at level one because we are now switching to a different implementation of that interface the behavior change let's move on to the next pattern the strategy pattern strategy pattern encapsulate Sande algorithm inside a class let's look at a Java example I have a very complex class I mean there is a lot of business logic in it and one of the important things which need need is it needs to be able to sort a set of items assort a set of numbers one of the ways we can implement is we can directly implement the entire logic for sorting in there tomorrow if I want to change this sorting then I will need to change the implementation of that particular complex class instead of that what we can do is we can use a strategy pattern in the strategy pattern we kind of separate the algorithm of how the sorting is done from the complex class what we do is we are creating here an interface called sortable and we have couple of implementations of the sortable interface bubble sort quicksort I mean we don't really have the implementations in here but you can assume that bubble sort is implemented in here it's quicksort in here so thereby this complex class all that we need to do is we need to pass in what sorting algorithm to use I mean this take this will not worry about how the sorting is done all that it expects is some kind of a sorting algorithm as an input and later it would use that sorting algorithm to sort and when we are creating the complex class to the constructor we would pass the exact algorithm to be used as an input so the users of the complex class can decide what sorting algorithm to use so there is a lot of flexibility that comes in because of using this strategy pattern basically you can dynamically keep changing this strategy and see the right one for your particular context the next pattern we would want to look at is the observer pattern observer pattern is a way of notifying a change to a number of classes so what does that mean let's say I would want to know whenever suchan's course essentially and there would be a lot of people like that they would want to know when such a course essentially what they say what they would do is they would say I would want to register so they would all register as observers and whenever such in scores essentially this centralized program will notify all the observers so I will know when as such when such in scores a century it's kind of how it happens in online bidding as well so you would say I would put a bid I mean I put a bid and whenever there is a bit higher than whatever I have done then all the bidders would be notified so there are really two important parts to any observer design pattern one is the registering part so I would want to register as an observer and the second one is the notification part of it where I would be notified whenever there is a change in the observer I mean in the object which is being observed I would need to be notified that there is a change that's basically the observer pattern a simple example of the observer pattern is on the github repos what we have is something called a search in century notifier and what we are saying is we would want to register 3 fans so we are registering 3 different fans and whenever there is a search in centuries called notified that such in scored a century would be called and all of us would be notified so you would see that the output of the program is that all of us are notified so you can take a quick look at this to understand the observer pattern observer pattern is quite a simple thing I mean it's a way of notifying the change to a number of class the next pattern we would want to look at is the visitor pattern a visitor pattern defines a new operation to a class without change there are a lot of situations when we are designing frameworks that we don't want other people to modify the code of the framework so basically we want others to be able to extend the functionality without touching the code inside the framework in those kind of situations we would want to allow them to add new operations but we don't want to allow them to change the code underneath and that's where the visitor pattern comes in the implementation of visitor pattern is a little tricky thing so we would really stay away from it a good example for a visitor pattern is the operation of a taxi company as soon as a person calls a taxi company and the company dispatches a cab to the customer we are accepting a visitor so the cab companies accepting a visitor that's the new customer once the visitor has entered the taxi so once the customer enters the taxi he is no longer in the control of where he is going the driver of the cab is not in the control so the visitor would be loved in the control of another class whose driver and the driver can add new operations on top of the visitor kind of a good example of the visitor pattern typically when you are in a situation where you have your a framework and you want somebody to be able to extend it or add new operations on top of it but you don't want them to be directly modifying the code of the framework in those kind of situations you can consider visitor pattern as an the next pattern we are going to look at is the template method template method the pattern definition says differ the exact steps of an algorithm to a subclass what does that mean a good example is again a house plan basically any house plan would consist of a foundation pillars a floor plan framing wiring and a lot of other stuff so you can kind of create a basic template class which has all this behavior defined and a subclass can extend this and give real implementations for some of the details a good example of the template method is inside the spring framework in the class abstract controller Java if you go further down there's a handle request which handles the request however you would see that it takes care of the basic things it checks the request it prepares the response that's basically this sequence of things it does and at the end it leaves the implementation of the actual handling of the request to the subclasses so the subclasses can now go ahead and implement the handle request implement handle request internal method and thereby they get all the functionality they would need so a template method is all about taking care of the high-level details and leaving the low-level steps to the subclasses the subclasses can override these steps or provide their own implementation for these particular steps the command pattern is defined as encapsulate a command request as an object let's take a real world example let's say I am going to a restaurant and I give an order to the waiter what does the waiter do he just writes the order I am giving on a piece of paper and he would pass it on to the chef the chef would execute the order and pass the piece of paper down to the waiter this piece of paper is the command object so this is the object which contains the all the details that are needed to execute that request so even in object-oriented programming whenever we have requests like this we can encapsulate all the things that are needed to exit a request as a single object and pass it across for example we have in the Java EE we have an object call request whenever user types in any details on the screen of a web application all these details are captured in a single object called a request and the request is sent down to the controller or the servlet a good example of command pattern is also the runnable interface in Java we create threads in Java by extending the runnable interface so when we create an thread all the functionality of the thread is is in this particular class and we would pass this class and call the start method to invoke all the logic which is present in there this is a very good example of the command the next pattern which we are going to discuss about is memento pattern this we are almost at the end of the behavioral patterns and the memento pattern is basically all about capturing and restoring an object's internal state a lot of games that we play offer this feature of intermediate sale at a certain state of this game you can save it and come back to it to implement such kind of a functionality we would need to store internal State eight of the objects at that particular point in time what we can do is we can store this internal state using something like serialization in Java and at a later point resto back from it and this pattern is called a memento pattern amount of pattern is very much useful in undo redo operations for example let's say I am working on a user interface and I've done a lot of changes I would want to undo them as soon as I keep on doing them I can actually restore back to a previous state if I captured the earlier state so that's a memento pattern the last patter which we are going to look at a mediator defines simplified communication between classes let us take the example of a air traffic controller at any point in time let us say in India we have about 500 flights flying let's say we want to decide the route each of these flights have to take we have to decide also when they have to land which route they have to take when they have to start flying and all that kind of decisions if all the 500 flights have to talk to each other and make these decisions then you know how complex it might be it gets very complex that is why we have somebody called an air traffic controller so the flights talk to the air traffic controller and based on all the information it gets from all the flights the air traffic controller can take a decision as to which route of flight can take when it can land what time it can start flying and all that kind of stuff so all the logic is now with the air traffic controller and it kinds of becomes the centralized thing which decides everything and it also simplifies the communication between flights because they don't really need to talk to each other they just need to talk to the air traffic controller and they can get details about all the other flights so that basically the air traffic controller a good example of a mediator pattern in typical enterprise applications is the ESB bus so we use something called an enterprise verse inter of instead of letting the applications talk to each other you would have an enterprise service bus where a application all that it does is it puts a message in the ESB and somebody handles it and gives it a response back it does not really need to care about who is handling it and how it's getting the response back it is a good example of the mediator pattern so that all the design patterns that we wanted to discuss during this course congratulations you have heard about more than 20 design patterns during this particular course as we said at the start of this particular course our objective was not to focus on the implementation details we did not worry want to worry about the implementation details of each of these design patterns what we wanted to give you is a flavor of the context in which these design patterns are applicable and we hope we are successful in doing that good luck

Channel: in28minutes Cloud, DevOps and Microservices

Views: 125,282

Rating: 4.7970791 out of 5

Keywords: software design pattern (field of study), design patterns, java, Design Patterns for Beginners, beginners, in28minutes, design pattern, java interview questions and answers, in28minutes tutorial, Design Patterns, patterns, design

Id: f5Rzr5mVNbY

Length: 45min 48sec (2748 seconds)

Published: Wed Sep 07 2016