Proxy Pattern – Design Patterns (ep 10)

welcome back I'm Christopher and it's now time to talk about the proxy design pattern if you're not already familiar with this playlist or channel what we're doing is that we're walking through all of the patterns in this book head first design patterns and as you know if you've watched the previous videos I highly recommend that you get this book if you're new to design patterns the link is in the description it's a super pedagogical book if you're not new to design patterns I'd recommend that you get this book instead by gang of four so this is like the classic de-facto design patterns book the original and if you decide to get both I wouldn't say that it's a waste of money good spend put them on your shelf keep them as a reference whenever you're wondering about design patterns go back to the source we have all these resources on the internet right but when I find conflicting information I tend to go back to this book and say okay what was the original intent of that pattern so super good book to keep now let's move on so what is the proxy pattern let's simply start off with the definition from this book so in the head first book we get this information the proxy pattern provides a surrogate or placeholder for another object to control access to it again so the proxy pattern provides a surrogate or placeholder for another object in order to control access to it so this is just a way of saying that you have an object that you want to get access to that you want to invoke methods on that you want to somehow interact with but instead of being allowed to interact with that thing you interact with a proxy who interacts with that thing so it's another way of introducing another level of indirection instead of calling the thing you want to call you call a thing that calls the thing you want and if you watch the previous videos you know that will do a specific video after this one on the differences between decorator adapter facade and proxy because there are sort of kind of a like so I won't dig in too much into specific differences between this and the other patterns right now but just think about it this way it's not only about how you string the objects together it's also about the intent like some patterns are mostly different in intent rather than in the technicalities so they might be doing on the surface or technically like like concretely they might be do exactly the same thing but what's different is that you you are doing it for a different reason so you might use the word proxy to communicate to other developers what kind of problem you're trying to solve and then you might use another word to communicate other developers that you're trying to solve a different kind of problem and proxy with proxies we're trying to solve a specific set of problems that are all access related so you put a proxy in front of something that you want to allow people to access but you have the proxy so that you can control access to that thing and in this book headfirst and in this book design patterns they talk about three versions of proxy pattern or I shouldn't say versions I should say styles or maybe intense or ways that the proxy pattern is used to control access these three ways are called three different things so they say that a proxy can either be a remote proxy of virtual proxy or a protection proxy let's write these down so you've got a remote proxy virtual proxy and a protection proxy now a remote proxy is suggested to be used when you want to access a resource that's remote what do we mean with remote here we mean something that could exist on for example a different server or in a completely different name space in a different called project so somehow you have to leave like the safe boundary of your application out into the outside world in order to retrieve some information back and so this interaction this this sort of transaction could be wrapped in a proxy so your proxy is responsible for this interaction or is responsible for for interacting with the remote resource and giving you back the things that you need if you're familiar with the concept of promises that are now commonly used in no js' I like to think of it as in Knight that the proxy is something that would interact with a remote resource but immediately return you a promise so it returns you a promise that promises to evaluate to the concrete resource that you were looking for after a while but instead of scattering this HTTP request or socket connection or whatever it is across your application you have this proxy that that simply interacts with this remote resource on your behalf so I should mention that one of the key things of the proxy pattern is that the proxy pattern looks like the remote resource the proxy pattern looks like the thing it's proxying so if you think about adapter pattern for example adapter pattern adapts to a different interface adapter pattern let's just say that you want to access a thing that has some particular interface but you have a different interface and you want to access it via your different interface proxy pattern however is simply a way of controlling the access so it doesn't change the interface so you have something that you want to interact with that has some particular interface and you don't want to change the interface you simply want to intercept the accessing of that thing that you want to access for some reasons such as security or caching or the kind of stuff that we're getting into here it's it's a little bit hairy and I if I'm completely honest I'm slightly confused by this myself so if you want us to dig further into this do ping and then I'll dig more and then we'll talk about it some more but this book has some super concrete examples that are from Java I haven't actually used the specific technologies that they talked about so this is why I'm not diving into that but if you're interested in that I highly suggest that you get this book and again if you want us to dig deeper into this do shoot something in the comments and then we'll talk about it moving on next one virtual proxy a virtual proxy controls access to a resource that is expensive to create a virtual proxy controls access to a resource that is expensive to create so this is like caching right we'll talk about this one more specifically so we got these three right and the example I want to take is from virtual proxy so we'll dig more into that in just a moment but just think about it it controls access to a resource that is expensive to create so you got some object which you want to interact with but you know that creating that object is expensive so you put something in front that you can interact with instead and then that thing that proxy makes sure that only when you really really need it do you interact with the actual underlying thing so it's kind of like lazy evaluation third one a protection proxy a protection proxy you can think about as access management so you've got a user and you're not sure whether a particular user has the rights to access a particular resource so you stick this protection proxy in between and that protection see make sure that only users that are allowed to access the underlying resource do get access to the underlying resource but this is of course just one example on the general plain the point is that it controls access to a resource based on access rights so you make a call to some underlying thing and the question is are you allowed to at that point make that particular call the proxy makes sure that if you aren't allowed to make that call you can't make that call and if you are allowed to make that call you can't make that call so those are the three I want to spend a bit more time talking about the virtual proxy so we won't dig into the other ones but hopefully you can see how what the proxy pattern does is that it that it adds some additional behavior not in the sense of decorator pattern but in the sense that it adds additional behavior with the intent of controlling access to the underlying object so both proxy and decorator adds additional behavior but a decorator is much more general and is designed so that you can sort of stack decorators where you decorate the thing that's decorated by a decorator that's decorated by a decorator and so forth and so forth whereas proxy pattern simply says that for some reason you need to control access to some underlying object and because of that you need to add additional behavior but you don't want to change the interface you want to interact with the thing in the same way you've always interacted with it as if it was the real thing but you want to add some additional behavior just before you make calls to it so let's get into a virtual proxy example so let's get rid of this stuff and here's the example imagine that you've got a string called book that contains a whole book represented as a string I'll just put dot dot here but imagine that this string is massive like it's huge right so this is a string representation of a book in like XML format or HTML format or markdown or restructure text or whatever I mean some arbitrary format it doesn't matter for the sake of this example the point is that the string is huge then let's say that we've already written a class let's call it the book parser so let's say that we have a class called book parser that we can we can instantiate so we can say book parser I'll just say BP to save space equals a new book parser and into the constructor we simply passed this book string right so this is the string containing the whole massive book right just just think about it I mean this book or this book I mean they're they're quite thick right so there's sort of a lot of contents in that string you can even to make the example of words I mean just imagine like the thickest book you can possibly think of so we've got the string representation of book we pass it to the book parser why do we do this because in this application we can then take this BP instance and say BP dot something like number of pages or BP dot number of chapters or BP dot number of adverbs I'm just introducing some random stuff right I'm just trying to say that the the book parser for some reason we have some application write for some reason we want to this is the book parser when you construct it we immediately parse the book and then give you a few methods that expose the result of this parsing so what this parsing does is that it calculates it's pre calculates a bunch of different things such as the number of pages the number of chapters the number of words the number of verbs the number of adverbs the number of nouns the complexity level of the text punch a bunch of different things right so like you mentioned that there are so many things that this computation is actually pretty intense because like the book is thinking and even if it's just a string that the string is like so long that if you need to do all of this calculation there's actually a lot of calculation that you have to do now as an interesting side point you might interject and say but if you say that this book parser pre computes the value of these different things why don't you make these accessors why don't you make them public fields with private setters and public getters so that the book parser does the parsing and then sets these these values because then it would really indicate to other developers that this field is not it does not entail computation it would instantly give you the value because it's not a method right like you would invoke it it would not invoke it you would simply access the member I'm struggling to remember what the quote is and where the quote comes from but if you do remember please shoot that in the comments so we can sort of dig down this source but I'm fairly sure that somebody said that properties and methods should be accessed in the same way or not necessarily like that but that from the outside it should not be obvious whether you are accessing a field or a method like if you invoke a method on an object without passing it arguments you shouldn't know whether that's invoking a method or accessing a field because if you first make it a field and I want to change your mind later to make it a method then that shouldn't cause you compilation problems like it shouldn't cause you some tactical problems you shouldn't have to if you decide to change from a field to a method that shouldn't mean that you have to change the things that access the method or the field that should only mean that you have to change the one exposing the field I may be completely wrong here but I think this is one of the reasons that people argue that it's a good thing that in the language Ruby for example you can't tell whether you're accessing a property or you're accessing a method it has the same syntax so this is the reason why I did this like I tend to in all ways essentially make use of methods because you never know when you want to change your mind in the future and it's not like there's a huge overhead to making it a method but that's enough from that sidetrack let's move on by the way if you disagree please - absolutely shoot that in the comments so we can have a discussion moving on so we know that invoking these methods is cheap because the cost has already been incurred because this statement is in this particular application not cheap remember that it's just a purely hypothetical example and this would completely depend on what you're building right but we're just imagining a scenario where this is not cheap but this is cheap now the point is this for some other absurd reason we happen to in our application instantiate book parsers even though sometimes we never actually call these methods and for some even other absurd reason we don't want to change that behavior so I'm putting up this sort of very arbitrary scenario where like we don't want to change the contents of the book parser we don't want to change the way this behaves and we don't want to change the fact that we have to instantiate a lot of book parsers because for some reason we need to pass pass them around like let's save it for some other reason we've made some other architectural decisions that means that we need to instantiate book parsers and pass them around even though sometimes we won't actually call any of these methods now of course this is a purely hypothetical example so please try to forgive me for the contrived mess probably the rational solution in this scenario probably would actually be to refactor the book parser and make it lazy make it so that the cost is incurred here instead of here like I would probably say that that's the better way to do it but you could think of it this way maybe the book parser is an external library maybe we didn't actually write the book parser again like there could be a multitude of different reasons for why we don't want to change the book parser but let's move on I hope you'll buy into that scenario so another way of solving this problem would be using proxy pattern so I haven't really said why it's a problem yet let's say that the problem appears now in that perhaps you've heard the phrase premature optimization so premature optimization suggests that you should not start to increase the performance of your application or attempt to increase the performance of your application before you know that you actually have a performance problem in other words don't spend time trying to make your app perform better in terms of how fast it executes don't try to do that before you actually know that you have a problem with it right because I guess this statement stems a lot from how some people tend to like let's say you're doing code review and you get to review a piece of code and then you add a comment to that code and you say well couldn't we perhaps refactor this so that it's a bit more understandable and then the author of the code says but hey you can't respect it that way because that way would be significantly slower this is the super performant way and then there were just shoveling bits around there are so many ways to do things so much faster but there's always that tension right like the more readable a program is the less formant it tends to be and the more performance you make it the less readable it tends to get purely informally but like it kind of makes sense right because like we're using higher abstraction building blocks when we write programs that are easy to understand or let's say why I guess abstract in their nature like they are discussable on a higher plane which we tend to call readable code but if you want something that's performant you have to write code that's understandable for the computer but not necessarily understandable for human so back to the point what we were saying is that let's say that we wrote this code when we didn't know that we had a performance problem but now suddenly we realized we have a performance problem we need to for some reason increase the performance of the application and this we see has one opportunity so how do we do this what we can do is that we can stick a proxy in between whoever calls the book parser or whoever calls these methods on the book parser so let's say that and usually we have like a client as usual we mean client as in some particular piece of code that uses some other particular piece of code not like a customer and this client let's say used to use the book parser I'll just put B Peter to represent the book parser let's say that it first instantiated it so let's say that first it instantiates it I'll just write new here and then it will call one of these methods I'll just write call here to emphasize that it calls one of these methods and we know that this first method call it is the expensive one and the second one is the cheap one and we also know that we won't always call this cheap method we won't always call the second method so the hypothesis of how we can improve performance or like the idea of how we can improve the performance in this scenario is that we want to say that constructing doing this expensive operation should only happen if you actually want to call a method so we want to defer they want to make it lazy and that's why we want to stick a proxy in between so what we do instead of doing that is that we simply say you've got the client but instead of the client directly interacting with with the book parser we interact with the proxy the client interacts with the proxy who interacts with the book parser so the client instantiates proxy the proxy doesn't instantiate a book parser because the proxy says forget him I don't know whether you actually will call any of the methods that requires me to parse this book so I'll wait until you tell me that I need to parse because you want some of this information so the proxy will simply stop here right the client will have a proxy and that proxy will follow the same interface as the book parser that's back to the idea that the proxy has the same interface as the one it's proxy in so the client can keep behaving can keep passing around this proxy as if it was a book parser in the same way that it's always done but now we are deferring the instantiation of the underlying book parser so let's let's talk about the call here so let's say now that now the client wants to make this call and so it could be it wants to ask for the number of pages so instead then of making the call directly to the book parser it makes the call to the thing that it thinks is a book parser which is this proxy so it makes this call I should have written new here to say that the top line is top line is new it's instantiation and then the second one is called then we're calling one of these methods and then when it does that call of course this call is super cheap because it's just the proxy but then the proxy says ah you now actually want some of this information which requires me to actually do the parsing so then the proxy will simply do this call it was something in Spanish ate the book parser and thus incur the cost of that computation but actually have to do that computation the expensive computation and that's when we'll get the performance hit and then immediately after that make the call call which is of course then cheap and then pass the object backwards to the client where it was making that call then of course you have to realize that we have to construct the proxy that's smart enough to not rebuild the book parsers every time we make a new call because then obviously performance will probably be worse than in the first scenario the proxy has to cache the book parser so the proxy builds the book bar serve the first time and maintain is a reference to that book parsers so that the second time we make a call to the same or another one of these then we simply already have a book parser and can then simply just make that quick call into the book parser super important to remember that and this is a purely hypothetical example so there are a multitude of other ways of doing caching and a multitude of other ways in which we could find ourselves in the need to do caching and a multitude of other situations which we could find ourselves in that would require or suggest that we need captions so the proxy pattern as in the virtual proxy the type of proxy that creates expensive objects on demand rather than immediately or that rather than pre computing them rather than creating them eagerly that kind of proxy pattern could be applied in a number of different situations this is just one hypothetical example but okay let's now look at the UML and let's discuss how it relates to what we just talked about alright so what do we got we've got an interface called subject and I'll just put an eye in front so that it's named eye subject just to denote that it's an interface just convention this subject has some kind of method which we'll just name request obviously this could be anything and in our previous example this method that this represents the different methods that we had that were named something along the lines of get number of pages get number of nouns get number of adverbs get a number of whatever those methods that's what we're trying to denote when we're saying requests here an interface that we will call subject but because it is an interface will precede it with an eye so we'll say I subject just to denote that it's an interface just by convention this interface has some method or some set of methods but we'll represent that here with just one method which we call request this method request of course depends on what your scenario is in our previous example this request method this request would be one of the methods called get number of pages or a get number of adverbs or a get number of words or whatever methods we have this simply represents that kind of call we want to make some kind of call to this subject and in order to have a method here let's just call it requests now the subject needs to be implemented this interface called I subject needs to be implemented by something so a concrete subject in the head first book they call it the real subject rather than a concrete subject if you've been watching the other videos you know that most of the times when we have a realization of an interface we've been calling it concrete something some things like we had a decorator and then a concrete decorator which would suggest that if we have a nice subject we should have a concrete subject I think the reason that they're saying real subject is to emphasize that this is the thing we had before we introduced the proxy or this is the thing that contains the underlying actual thing we want to do but then we stick a proxy in between and the proxy will also be concrete so we have two things that are concrete and then that's probably the reason why they're saying real just to make it easier for us to differentiate between the two even though both our concrete will name this concrete stupid me now I named it concrete anyway let's just remove this so we'll name it real subject and that's a concrete and of course because it's a realization of this interface we need to implement the method request so in our previous example this was the book parser it's the book parser that follows a particular interface that could be an iBook parser for example as you might have guessed the next step is that will introduce a proxy that would implement the interface I subject so let's now look at the final piece the proxy so we have another class which is also a concretion that we call a proxy and of course now we're just saying in the general world I mean this would be again like depending on your scenario you would name these sensibly so maybe this is an iBook parser this is a book parser and is it like a lazy book parser proxy or something like that I would probably put the word lazy and just to emphasize that that's the problem that we're trying to solve but or that's the thing that we're adding on and that's the reason why we're using this proxy and of course then this proxy implements this interface ice object as we were saying before the proxy behaves as the subject and that's how you get the substitutability that's how you can exchange proxies for subjects and vice versa and finally of course the proxy also needs to implement the request method and again this request method could be multiple methods and you would name them something which is sensible for your scenario so in our scenario this could have been for example get number of words so this is get number of words get number of words and get number of words now the final arrow that we're missing is badda-boom this the real subject implements the interface I subject the proxy implements the interface I subject but the proxy has a real subject so the proxy is not as an inheritance but as an implements the interface is behaves as a subject but it has a real subject which means that it can delegate to the real subject which means that we can do the whole delaying the instantiation that we talked about before so if you contrast this to the decorator pattern when we were passing the thing decorated through the constructor of the decorator that's not what we're doing here you could do that if you wanted to you could pass an instantiated real subject to a proxy but that wouldn't help in our particular scenario in our particular scenario we want to say that the proxy is responsible for initiating the real subject because that instantiation is actually the expensive operation that's actually the operation that we want to control access to we're creating a proxy and here is where we have the capability of controlling access a proxy has a real subject and because it has that it is responsible for controlling the access it is responsible for delegating whenever appropriate so in completely other scenarios it could do things such as whenever you go request the first time you delegate the request to the real subject but whenever you call it a second time or any time after the first time you'll just get the value that the proxy saved for that request in itself and thus it won't make an actual call to the real subject so like caching the proxy asks the real subject for the value the first time but then assumes that the value will stay the same in the future I mean if you want to do something even more complex you could have like you serialize the arguments that you pass to the request method and look if this request looks just like the other request and then you check the cache or whatever I mean like caching is a difficult problem right I mean there's a lot of different ways you could solve this and depending on your scenario you might need different solutions but the general point is the proxy controls the access to the real subject point number one and a point number two the proxy follows the same interface as the thing it is proxying this proxy proxies the real subject and the real subject implements the interface I subject which the proxy also does so the proxy will be interchangeable for this real subject it will be interchangeable for the thing it's proxying Third Point the proxy doesn't necessarily have to be passed the real subject upon the instantiation it doesn't necessarily have to be passed the thing it's going to proxy at instantiation the proxy may if you want to if you need to be responsible for instantiating the real subject and in many scenarios that is the sort for behavior and that's it you hopefully now feel that we've nailed the proxy pattern if not please do shoot something in the comments and we'll discuss further before we wrap up let's super quickly go get some cold let's get rid of this stuff and let's build up some cold for the example that we talked about before with the book parser so hypothetically let's think about this so we have a class called the book parser the book parser and it has a constructor public book parser that takes a string representing a book and does some super heavy computation upon a string that's the tough part we wanted to avoid this is like so I'll just put like a comment here that says expensive parsing right so obviously I won't write that implementation because it doesn't really matter but you mean just imagine that woman whenever we run this constructor we have to perform lots of expensive computation now then it has a bunch of methods let's just put one of them here so let's say that we have a public method that returns that say an int and it's called get num pages sorry I'm just using the short name getting on pages instead of get number of pages just to save space and that method has some implementation that depends on this computation so you can output dot dot dot because it doesn't really matter what this actually does now that's the book parser let's close up the book parser we're missing one piece and that is that the book parser needs to implement an interface this is the concrete book parser but actually the book parser needs to implement so we'll say : denote implements I book parser and the iBook parsers an interface so let's write that interface so interface I book parser and that and that interface requires that whoever implements that interface implements this method get' nan pages so we'll here specify get numb pages avoid method that takes no arguments and that's the interface let me just put a line so that we can see that these are not the same thing let me put another line here for the next thing so we have two pieces and there's one piece missing this is what in the UML was known at the I subject this is what was in the UML known as the real subject and what we're missing is now the proxy so let's write the plot the proxy the proxy is a class I have no idea I'm going to fit this let's try proxies a class that's right class so I'll name it lazy book parser and let's just put proxy R as well to denote that were proxying we're proxying on behalf of a book parser just open that up and his class doesn't actually need a constructor of course it needs a constructor but we don't need their constructor to take any arguments so we almost any language we can ignore specifying the constructor because then we'll just default to having an empty constructor the reason I'm saying that is that unlike in the case of the decorator pattern for example we're not required to support the sort of chaining of multiple decorators so in this case we don't necessarily have to support the sort of chaining of multiple proxies like a proxy of a proxy of a proxy you could have a proxy that's a proxy the proxy of a proxy right it's it's completely allowed but it's not inherent to the pattern it's not required to be able to be considered a proxy pattern so we don't need a constructor here however we need an instance variable because we want to keep track of whether we have instantiated the book parser or not again it's lazy so we only want to instantiate the book parser whenever we actually need to instantiate the book parser the real subject and not beforehand so in order to keep track of that we need an instance variable and instead of setting that in the constructor I'll just assume that this hypothetical language that we're using supports the following syntax let's just create an instance variable that defaults to null so we'll have a private instance variable here let's say private and is of type book parser concrete book parser concrete book parser equals no why because we don't have a book parser yet so if I would say new book parser here that would mean that whenever we instantiate a lazy book parser proxy we also instantiate a book parser which means that we will necessarily have to incur this expensive computation will necessarily have to perform this this expensive computation that's not what we want so instead we just set it to null as default then what because this book lazy book parser proxy all sorry I actually forgot this lazy book parser proxy of course needs to implement the interface I book parser and because it implements the interface I book parser it needs to implement all the methods so we need to have a public method cold so sloppy sorry I forgot to in the interface I should have said in peer to denote that this get numpages method should return an int as it does here in the book parser so that should be part of me in their face sorry so we need here in the lazy book parser proxy a public method that returns in hint and is called get numb pages and it takes no arguments now what's the implementation of this method the implementation of this method is actually super simple we want to delegate to a book parser but we don't have a book parser yet because our book parser is dull so what do we do we check if we have a book for sir we say if book parser some more sloping and start hearing the instance variable I just wrote the pipe and not the actual variable names let's just actually add that so we have a private variable of type book parser called let's say parser with the lowercase P equals No so the instance variable is named parser so we say if this dalt parser is no I if we don't have one then we need to instantiate it so I'll just continue on the same line here in order to save space then we'll just say this dog parser equals new a new book parser and what do we pass that well actually the book parser requires a string so hopefully you notice this when I made the mistake but I completely messed up here because of course the lazy book bars a proxy needs to have a constructive the constructor that it needs needs to take a string it needs to take string that represents this book because whenever we then instantiate the book parser we need to have access to that string so now this is going to get super cramped but let's just assume I'll sort this out later let's I'll just say this dot book I'll pass that to the parser we'll solve this in a moment but just assume that we have that book in scope so many mess-ups today I now also notice that the Sun is totally blocking this out let me just pull down the curtain much better Tories are about that so in this method get numpages we've now first on this first long line we first checked if we have a parser available and if we don't if it's equal to null then we'll instantiate it and when we instantiate it will pass the book the string representing the book and then we'll simply delegate this method call get none pages to our instance of a book parser so we'll say return the value of invoking the method getting on pages on the parser so return this thought parser don't get num pages that's it now that's actually also solve this constructor problem I think you can probably see what the constructor would look like but just to be exhaustive let's actually just write that so let me do this let's say don't dot dot here and I'll continue this portion terribly sorry about this mess I'll continue it up here don't write so this portion should be here right that's where this part here should be so what would the constructor look like the constructor would look like this we would say public lazy Bois parser proxy and this constructor takes an argument which is of type string and we'll call it book and then we'll open that constructor and then what if they can start to do while the constructor simply takes this book variable that's that's passed in as an argument to the constructor and assigns it to an instance variable which we didn't declare here but let's assume that we have it we'll say this dot book equals the book and I'll close the constructor and then of course we also need to have that variables so let's say that in this in this class we also have a private variable of type string and it's called book and will default to null so actually to be kind let's just say that it's null here as well equals no so again sorry about this back and forth but let's just review this super quickly here's the thing we've got an interface called iBook parser it says that whatever it claims to be a book parser needs to have a method that returns an int and it's called get long pages it takes and that method takes no arguments now we have a concrete book parse your here and we have a concrete book parser here this thing is a real book parser and this thing is the proxy whenever you want to use this book parser we are providing you with this proxy so that you can use this proxy instead because it's more performant the proxy will delegate to this book parser but it does so in a smart manner it changes behavior slightly because it delays the instantiation of this concrete book parser of this reading book parser until it knows that you actually really need that book parser so how does it know well we have this method getting on pages and whenever you call that method getting on pages it checks do i have a book parser already instantiate and if i don't i need to instantiate it now because when they called get none pages i will definitely need this underlying book parser and if they never call that right if the subject if whoever is using this proxy never calls get nan pages then we won't ever hit this code and we won't ever then instantiate a book parser and thus as we were saying before this is the expensive parsing this is the expensive operation instantiating the book parser that's the expensive operation in this particular scenario in this particular example so by making sure that the instantiation of this book parser only happens in the context where we actually need it like when we have called one of the methods that depend on actually having a concrete book parser we defer to that point we've hopefully improved performance of course this would require testing you would check if it actually did improve performance but mmm hypothetically it's really good and that's it that's the whole gist of it you put the proxy before something else and then you call the proxy rather than calling the thing directly and the proxy interacts for that other thing and that's it I hope that make sense if not again shoot something in the comments and if you have a further examples or simply want to discuss something do also shoot that in the comments it's always massively appreciate it be on that check the description for links to these books they were super good if you're interested in design patterns and also even if you don't want to read them now they're super good to put on your shelf because you never know when that moment will strike you when you say wait a minute what was actually that design pattern and then you find the whole internet it's confusing anyways links are in the description thank you super much for watching I hope to see you in the next one so subscribe so that you won't miss it in the next video we'll talk about the differences between decorator adapter proxy and facade and then we're back to the regularly scheduled program I don't actually know which pattern is the next but we'll see subscribe to stay tuned again thank you very much for watching and I'll see you in the next one

Channel: Christopher Okhravi

Views: 113,748

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

Id: NwaabHqPHeM

Length: 37min 35sec (2255 seconds)

Published: Thu Aug 24 2017