Listen dude, I am from Ukraine and, you know, the thing what you are doing here is really great. I mean I have looked through all russian speaking youtube and your course is really the best ad it's not even close. I'm so grateful to you. You are a wonderful teacher and you really can explain difficult things in easy to understand fashion. Thanks a lot for this. Wish you all the best. Move on man
00:02 Facade pattern simplifies the interactions between different classes 01:59 Single Responsibility Principle leads to lots of classes, which may result in complex dependencies. 03:56 The facade pattern simplifies complex system wiring in highly decoupled systems. 06:05 The Facade Pattern provides a simplified interface for interacting with complex subsystems. 08:19 The facade pattern allows clients to interact with a simplified interface instead of multiple complex pieces. 10:08 Principle of Least Knowledge (Law of Demeter) 12:12 The Facade pattern is related to the Law of Demeter 14:18 The facade pattern provides a unified interface to a set of interfaces in a subsystem.
Facade seems to be even simpler in my view. All those classes having complex relations is pretty irrelevant to the Facade pattern. The only thing important is that those classes are multiple and the client has to deal with all of them. So the Facade class combines interfaces of all needed classes into one interface. I.e. Client calls Facade.StartEngine, Facade.StopEngine, Facade.TurnLeft, Facade.TurnRight, and Facade class calls Engine.Start, Engine.Stop, Wheel.Left, Wheel.Right. It's useful for example in WCF services, when you have to expose many controllers' methods to an external client.
I would like to add my example here. You are adding a new feature to your application and this involves C# developer, UI designer, Databade developer, Mobile App developer, QA and IT teams (all of them are classes). Top executives (client class) don't want to come and ask every team about what we are adding and who will do what, instead they will go to Project Manager (facade) and PM will be responsible to communicate to required teams.
Thanks Chris. Thought of an example on watching this video...."Travel Agent" as a Facade. When you make an overseas trip, following needs to be taken care - ticketing, visa, lodging, food, local site seeing, local transport etc. Clients can directly perform these tasks on their own and it'll be lot of work. Instead, if we use "Travel Agent" as a Facade and he'll get all this work done for client. Client just pay and have a happy vacation. Does this example sound like a Facade? Let me know your comments.
I bought a course in Udemy before I found these videos, huge mistake. I've had to watch Christopher's videos to be able to understand the dull powerpoint slides of the course and do the coding challenges. Christopher you're the best!
Thank you so much sir. No words to describe these videos how much it helped to understand the design pattern. Now i could feel that i will definitely learn all design patterns. May god bless you.
Hey man I love your design patterns series, but I am missing the builder pattern... I know it's not in Head First (don't know why) but could you do a video on it? Would be awesome!
A good example of an implementation of Facade Pattern is a certain library from NuGet. Think about it - take fluent validation for example. You call certain static classes and methods but behind these methods there is probably a very big and complex infrastructure.
Man, your videos are awesome, all of them I have watched them and I’m very happy with your content, the problem is that you just stop, there are hundreds of people like me trying to reach you to tell you, please do more, even if they are paid videos I will give you my money, you can sell them Udemy, patron or TH-cam itself. I will be very grateful, but not only me, a lot of people. Thanks!
As usual, clearly explained. Keep up the good work! In terms of the example used (facade for a house), would perhaps driving a car be a better analogy? For instance, pushing an accelerator is a facade method, which hides all the complexities of what happens underneath the hood - engine, fuel injection, etc.
I just read book Clean Architecture, and author Robert Martin said SRP is not "do one thing principle". SRP is of module level, and a module is responsible for only one group. do one thing is method level, and a method should do only one thing.
What about component based approach? In component approach, we get a component and for example call its method. It only depends on that component. With facade pattern, we probably have a facade class with a bunch of methods and in some of them, call components methods indirectly. I think we have a big dependency a complex facade class. Although we can implement interfaces for it.
Just watched your clip about adapter pattern, and in 15 minutes you explained it in the way I wished our professor should have, in the last 1.5 months... Thanks man, you can be the game changer for my upcoming test :P Gonna go Pokémon on all your videos now!
Is it correct to consider all/most client libraries a form of facade pattern since the implementation is hidden and client need only to call the method that is exposed?
what is the design pattern in "myModule" -> My3rdPaymentGatewayConnectorModule" -> "3rdPartyPaymentGatewayAPI"? in the run time, "myModule" decides the relevant "My3rdpartyGatewayConnector" module? in here my connector modules implementation plays adapter/strategy pattern?
Can I consider the web services we create folllow up the Facade pattern, since we provide a simple interface to outside world and carry out some complex task at service level and provide the result of the task performed as response. So complex webservices exposed is an ideal example for this pattern.
we know there is similiar pattern and that is client factory. In client factory pattern we have some different type of objects which we are returning back throw one factory class. how this is diferent from that?
Very good video, I am going to watch all of them. I can also recommend Clean Code by Robert C Martin and Growing Object-orientented software guided by tests by Freeman and Pryce. There are improved examples, for the second book, available on the web (using Mockito).
I'm interested on the Law of Demeter video :) Thank you so much for this amazing series!! I love your videos and i hope you will continue as long as you can, I'm learning so many things from you. Oh i forgot one more thing... Thank you again! :)
+Carlo Centofanti Thank you! All of you are so friendly :D I'm glad the material is appreciated. Thanks for plus one:ing the LoD. Will definitely do it but it will probably have to wait until I've finished the design patterns series :)
My position on static methods is a bit fanatic. So take my opinion with a grain of salt. The "issue" with static methods in OO languages is that you cannot (trivially?) store them in variables. I.e. they are not "first class citizens". In functional programming (FP) all (I'm oversimplifying) methods are static since they do not reside on objects. In other words they take data as arguments rather than mix data alongside their functions (like in OOP). Closures are a different story but let's discuss that some other time (if you're interested see [1] and [2]). What I want to get at is that in FP this is not become a problem since functions are "first class". I.e. you can store them in variables and pass them around at runtime. In OO you can not (trivially). When you choose static methods over instance methods on objects you loose dynamic dispatch [3]. And imho and humble understanding that is the whole point of OO. In some sense I don't even see why static methods, in the Java and C# sense, exist at all. If the reason is performance then yes ok I see, but then we should only only use them when performance is key. I said "in the Java and C# sense" because what's interesting is that in languages such as Ruby, Smalltalk, and Python classes are objects. I.e. the class class inherits from object. This means that even if methods are static you don't loose dynamic dispatch. I.e. they are replaceable at runtime because you can put a class in a variable and "pass it around" which I actually find quite ingenious :) Now we're getting of track and I can't find the reference for this (so I might be wrong) but I think someone jokingly suggested that UML encourages "class oriented programming" rather than "object oriented programming" which is actually a quite interesting statement if we think about the difference between a language where classes are objects vs where classes are this special thing that is different from objects. Anyways... sorry for the super long answer I hope it makes somewhat sense. What do you think? Agree/disagree? Thank you for staying in the game and watching the series :) And thank you for your super relevant question! :D [1]: wiki.c2.com/?ClosuresAndObjectsAreEquivalent [2]: stackoverflow.com/questions/2497801/closures-are-poor-mans-objects-and-vice-versa-what-does-this-mean [3]: en.wikipedia.org/wiki/Dynamic_dispatch
Thanks Chris for the great explanation. Looks like I missed it somehow and didn't receive any notification. Sorry for my late reply. I do agree with you that static methods don't make a lot of sense in OO but I have seen it being used by many programmers. For example if you look at the popular php framework Laravel, they use Facades pretty heavily with static methods.
6 ปีที่แล้ว
I loved Laravel's facades when I started out with the framework. Everything works out of the box. But to be honest, it's way too easy to violate SRP everywhere through your project. I only create static facades if having to refactor a bowl of spaghetti. Only as an intermediate step.
Hi, just started with design patterns, I'm wondering do I have to read book and watch videos by order to understand better or is it ok to watch arbitrary to encounter my project necessities? Thanks!
Let me see if I understood this.... Imagine that I have a command interface and for a specific command implementation, I need to save some information on the database. In this case, should I use a Facade pattern to have those subsystems and work with it? Is that correct?
Can you please do Composite pattern and Flyweight pattern of structural patterns? They are mentioned in the reference book you suggested and is part of my course so I need your help to learn them. Your tutorials are way better and understandable then what university teacher teaches us. and luckily I just found your videos today on the design patterns.
An electrical switchboard in your room is like a Facade to all the complex wiring (classes) underneath it . You (Client Code) just have to plug in the wire and turn on the switch, while being completely unaware about how those wires interact with each other and with you (client code)
Not a problem. I'm glad you appreciate it! I'm running a screencast series on patterns in parallell where I'm giving code examples (link below). I haven't gotten to facade yet but eventually it'll be there as well :) th-cam.com/play/PLrhzvIcii6GNCgHSj44-gXZeTUVbSPC-3.html
Is the following a valid sentence to describe the problem to a "facade" solution? "how to allow the Client (the stable part of an application) to use another part of the application which is unstable and/or made of multiple or complex interfaces?"
Thanks for the Video Chris... u r awesome...!!! one thing is in my mind , can we somewhere correlate facade with command pattern. even in command pattern we just use a single window as a command(inside complexity can be anything) and in facade we use most accessible interface to call complex inner system. ur thoughts plz !!!
Nice explanation dude! But tell me one thing... isn’t the "facade class" acting merely as a proxy ? So the question is what’s the difference between proxy pattern and the facade pattern ? I mean then why do we need 2 separate patterns. Because in essence, both of them ultimately are a mechanism to invoke something by something else (a proxy or a facade). Ok so a googling gave the answer -> Proxy pattern is to control direct access to a particular object, whereas Facade object provides simplified higher level interface to a subsystem of objects/components.
Is the "Safe navigation operator" a kick in demeters face? When you'd use it for example like this: zip = company?.getCto()?.getAddress()?.getZip() This feels just wrong, but how would I do this right? en.wikipedia.org/wiki/Safe_navigation_operator
Facade makes me think of an elevator. When I want the elevator, I push the call button. When I get in, I push the button for my floor. But there is a lot going on behind the scenes, which I don't know about and which I should not know about. Imagine what it would be like if each user were trying to control the motors and the doors.
On the Law of Demeter, I have a question. If I have a relational database with a join table, let's say a user associated with multiple addresses and vice versa, accessing the address's postal code via C# LINQ query syntax would be something like this (ignore the magic strings and any other bad practices for the example's sake): (from userAddress in user.UserAddresses where userAddress.UserId == user.Id && userAddress.Type == "Primary" select userAddress.Address).FirstOrDefault().PostalCode Is this violating Demeter's Law? It seems inevitable that join tables will add one extra layer to the process: object type A queries for all of object type B that belong to it, and from there they access a a property of B which is of type C, and from there access its properties. I suspect that this is not actually a violation. The join table is a necessary element for B to be a property of A and vice vesa, and thus the join table can, for the sake of the Law of Demeter, be ignored.
I’m interested in that controversy regarding the Law of Demeter. (Why Demeter, by the way? Is it named after the Ancient Greek goddess or someone else?)
I had the same question that even took me to review the myth of Demeter and Persephone, I am always excited about modern ideas with a mythological meaning or connection. Unfortunately, this law was named after the Demeter Project "an adaptive programming and aspect-oriented programming effort"
In the system I'm currently working with we have a facade layer between the code behind (which in itself has way too much complex code that shouldn't be there) and a service layer. But in 99% of the cases, the facade isn't doing anything useful, it just passes the call on to the service, note that the facade rarely calls more than one service. In these cases, is there any reason not to call the service directly? Great video as usual!
In case you want to change the behaviours and attributes of the services you use in your client code , you dont have to change the client code that uses the services. It has a kind of decoupling role here. And i aggre that it seems useless until it comes to change or upgrade or fix your library
I would totally buy that if the services were doing more complex things, but mainly the services are just way too simple, like only returning data from mainframe as datasets, which are used directly in the code-behind. Also the facades are duplicated per code-behind, despite calling the same services and relaying the same input and output.
I'm inclined to agree with your comment @Fersah. Consider e.g. the quote "every problem can be solved with another level of indirection". But then again @Hoax, there's the second portion of that quote: "except the problem of too many levels of indirection". So I agree that this is tricky. I would ask myself: 1) Do I own the service I want to consume? Because I would be less vigilant with indirection levels if I do control it or if the third party is something extremely stable that is not shotgun spread across my own code base. 2) Does the service reside in a different codebase/subsystem/process etc? Because if it does I would probably be vigilant. 3) Can I envisage any possible scenario where the cost of not having kept the currently existing abstraction would be significantly more expensive then the cost of maintaining the currently existing abstraction? But really this is of course a super tricky one and imho one would have to dig into the details :) Just a few cents but I hope it's at least some food for thought. What do you think?
By seeing his funny style, body language and expression I thought he is somehow from Head first Team but then I checked with the Head first book contributers and then his youtube page then I find he is not among them but one of their type😁😁😁... but BTW you got the success to achieve the same simplicity as book bro...
Suppose there is an REST API and in service layer lot of complexities are going on. All the complexities (working) are behind that REST API. User of that API only knows what is required to call that API not aware about any complexities behind the API. is it facade pattern?? Any one can help me to understand this.
Realistically unfortunately not soon :) But as absolutely soon as possible :D Dropping design pattern whiteboard videos every Monday turns out to be trickier than I thought :) But I'm staying consistent :D :D Thank you super much for watching :) and apologies for not being able to accommodate quicker :/
Listen dude, I am from Ukraine and, you know, the thing what you are doing here is really great. I mean I have looked through all russian speaking youtube and your course is really the best ad it's not even close. I'm so grateful to you. You are a wonderful teacher and you really can explain difficult things in easy to understand fashion. Thanks a lot for this. Wish you all the best. Move on man
I agree!
Согласен, Слава Украине!
RIP
If you were to look through all english speaking youtube as well, you'd see that this channel beats them too.
@@RussCreeperMod Hey Russ, what's a political slogan doing here?
00:02 Facade pattern simplifies the interactions between different classes
01:59 Single Responsibility Principle leads to lots of classes, which may result in complex dependencies.
03:56 The facade pattern simplifies complex system wiring in highly decoupled systems.
06:05 The Facade Pattern provides a simplified interface for interacting with complex subsystems.
08:19 The facade pattern allows clients to interact with a simplified interface instead of multiple complex pieces.
10:08 Principle of Least Knowledge (Law of Demeter)
12:12 The Facade pattern is related to the Law of Demeter
14:18 The facade pattern provides a unified interface to a set of interfaces in a subsystem.
The facade lets the clients interact with the madness!
"there's not some order to this madness, it's just madness!" 🤪
Loved it
hahahahaha i love this, thought as much
This all you need from this video
7:21 to 8:52
15:00 to 15:45 :-)
Facade seems to be even simpler in my view. All those classes having complex relations is pretty irrelevant to the Facade pattern. The only thing important is that those classes are multiple and the client has to deal with all of them. So the Facade class combines interfaces of all needed classes into one interface. I.e. Client calls Facade.StartEngine, Facade.StopEngine, Facade.TurnLeft, Facade.TurnRight, and Facade class calls Engine.Start, Engine.Stop, Wheel.Left, Wheel.Right. It's useful for example in WCF services, when you have to expose many controllers' methods to an external client.
Nice example
thanks
I would like to add my example here. You are adding a new feature to your application and this involves C# developer, UI designer, Databade developer, Mobile App developer, QA and IT teams (all of them are classes). Top executives (client class) don't want to come and ask every team about what we are adding and who will do what, instead they will go to Project Manager (facade) and PM will be responsible to communicate to required teams.
Thanks Chris. Thought of an example on watching this video...."Travel Agent" as a Facade. When you make an overseas trip, following needs to be taken care - ticketing, visa, lodging, food, local site seeing, local transport etc. Clients can directly perform these tasks on their own and it'll be lot of work. Instead, if we use "Travel Agent" as a Facade and he'll get all this work done for client. Client just pay and have a happy vacation.
Does this example sound like a Facade? Let me know your comments.
I am going to use it in an interview then will let you know
You are a great teacher Christoper, and I love how you share your inner thoughts on the topic aswell!
The CLIENT explanation at 1:15 would have saved me years of confusion had I heard it ten years ago....so important
14:26 Forthlly....finally
Dude you are awesome. Understanding design patterns has never been easier for me. Goodwork and Thanks.
Great videos you have. Give pats to the cat.
+Tomasz Giba Hehehe will do :) Thank you for watching :)
@@ChristopherOkhravi he deserves some wet food for his appearance in this video
Your energy gave me 5 extra years of life, so thanks!
Loved it!! This man energy is unmatchable !!
I bought a course in Udemy before I found these videos, huge mistake. I've had to watch Christopher's videos to be able to understand the dull powerpoint slides of the course and do the coding challenges. Christopher you're the best!
Thank you ! The way you move and change the camera view makes the video interesting!
You are a real ninja in explaining complicated stuff very easily. Thumb up!
First of all, great videos Christopher !! It would have been great to see a code example of Facade Pattern which I think you missed in the video.
Thank you so much sir. No words to describe these videos how much it helped to understand the design pattern. Now i could feel that i will definitely learn all design patterns. May god bless you.
thank you so much i have a final exam tomorrow in software designand architcture and this is really helpfull
I don't understand why there is stll only 21k views for the videos. It is awesome, Easy and clear.
Hey man I love your design patterns series, but I am missing the builder pattern... I know it's not in Head First (don't know why) but could you do a video on it? Would be awesome!
A good example of an implementation of Facade Pattern is a certain library from NuGet. Think about it - take fluent validation for example. You call certain static classes and methods but behind these methods there is probably a very big and complex infrastructure.
You classes are awesome. The way I see and write programs has changed completely after your design patterns videos in good way. Thank you sir
The discussion over a not talking to c directly.. and increasing responsibility on b.. would be great! 🙌
Man, your videos are awesome, all of them I have watched them and I’m very happy with your content, the problem is that you just stop, there are hundreds of people like me trying to reach you to tell you, please do more, even if they are paid videos I will give you my money, you can sell them Udemy, patron or TH-cam itself. I will be very grateful, but not only me, a lot of people.
Thanks!
Dude! you make tutorials like a ninja!
Keep them coming mate!!
Thanks for sticking around! :) Will do. Next one should drop during the upcoming weekend.
As usual, clearly explained. Keep up the good work! In terms of the example used (facade for a house), would perhaps driving a car be a better analogy? For instance, pushing an accelerator is a facade method, which hides all the complexities of what happens underneath the hood - engine, fuel injection, etc.
I just read book Clean Architecture, and author Robert Martin said SRP is not "do one thing principle".
SRP is of module level, and a module is responsible for only one group.
do one thing is method level, and a method should do only one thing.
What about component based approach? In component approach, we get a component and for example call its method. It only depends on that component.
With facade pattern, we probably have a facade class with a bunch of methods and in some of them, call components methods indirectly. I think we have a big dependency a complex facade class. Although we can implement interfaces for it.
Im not that good at english but the way you explain it its just fantastic, thanks for making this videos, you are really great
Just watched your clip about adapter pattern, and in 15 minutes you explained it in the way I wished our professor should have, in the last 1.5 months... Thanks man, you can be the game changer for my upcoming test :P Gonna go Pokémon on all your videos now!
Is it correct to consider all/most client libraries a form of facade pattern since the implementation is hidden and client need only to call the method that is exposed?
Well done Ishant Sharma!
So good they all make sense now. I have taken the red pill!
+Alexander Nava Hehe :) Thank you for the comment :D
what is the design pattern in "myModule" -> My3rdPaymentGatewayConnectorModule" -> "3rdPartyPaymentGatewayAPI"?
in the run time, "myModule" decides the relevant "My3rdpartyGatewayConnector" module?
in here my connector modules implementation plays adapter/strategy pattern?
Nice explanation.
An example would have been great.
Would an API be a facade pattern?
SLF4J, used for logging purposes in Java, is a very good example depicting usage of this pattern.
Sign me up on that "interested of demeter" list ;) Thanks for the vid!
+Andreas Smedjebacka Great! Thanks for pinging. Will dig into it as soon as possible. Thanks for sticking around :)
Can I consider the web services we create folllow up the Facade pattern, since we provide a simple interface to outside world and carry out some complex task at service level and provide the result of the task performed as response. So complex webservices exposed is an ideal example for this pattern.
I'm a game developer, in our project there are a lot of "XXXContext" class, which is the facede pattern?
wow man , the way u explain , very entertaining and understandable, one of the fewest videos of CS that im not got bored watching XD , subscribed !!
One word: Brillant!
we know there is similiar pattern and that is client factory. In client factory pattern we have some different type of objects which we are returning back throw one factory class. how this is diferent from that?
Thank you so much for all your help! Please keep making tutorials!
Your videos are the best about design patterns! Thank you for your work.
Very good video, I am going to watch all of them. I can also recommend Clean Code by Robert C Martin and Growing Object-orientented software guided by tests by Freeman and Pryce. There are improved examples, for the second book, available on the web (using Mockito).
I'm interested on the Law of Demeter video :) Thank you so much for this amazing series!! I love your videos and i hope you will continue as long as you can, I'm learning so many things from you. Oh i forgot one more thing... Thank you again! :)
+Carlo Centofanti Thank you! All of you are so friendly :D I'm glad the material is appreciated. Thanks for plus one:ing the LoD. Will definitely do it but it will probably have to wait until I've finished the design patterns series :)
Does controller is a kind of facade pattern?
0:00 - Rowan Atkinson
Facade pattern conflics with single responsability principle?
Thanks Chris. What are your views about facades having only static methods so that we wont need to create objects for those classes.
My position on static methods is a bit fanatic. So take my opinion with a grain of salt.
The "issue" with static methods in OO languages is that you cannot (trivially?) store them in variables. I.e. they are not "first class citizens". In functional programming (FP) all (I'm oversimplifying) methods are static since they do not reside on objects. In other words they take data as arguments rather than mix data alongside their functions (like in OOP). Closures are a different story but let's discuss that some other time (if you're interested see [1] and [2]).
What I want to get at is that in FP this is not become a problem since functions are "first class". I.e. you can store them in variables and pass them around at runtime. In OO you can not (trivially). When you choose static methods over instance methods on objects you loose dynamic dispatch [3].
And imho and humble understanding that is the whole point of OO. In some sense I don't even see why static methods, in the Java and C# sense, exist at all. If the reason is performance then yes ok I see, but then we should only only use them when performance is key. I said "in the Java and C# sense" because what's interesting is that in languages such as Ruby, Smalltalk, and Python classes are objects. I.e. the class class inherits from object. This means that even if methods are static you don't loose dynamic dispatch. I.e. they are replaceable at runtime because you can put a class in a variable and "pass it around" which I actually find quite ingenious :)
Now we're getting of track and I can't find the reference for this (so I might be wrong) but I think someone jokingly suggested that UML encourages "class oriented programming" rather than "object oriented programming" which is actually a quite interesting statement if we think about the difference between a language where classes are objects vs where classes are this special thing that is different from objects.
Anyways... sorry for the super long answer I hope it makes somewhat sense. What do you think? Agree/disagree? Thank you for staying in the game and watching the series :)
And thank you for your super relevant question! :D
[1]: wiki.c2.com/?ClosuresAndObjectsAreEquivalent
[2]: stackoverflow.com/questions/2497801/closures-are-poor-mans-objects-and-vice-versa-what-does-this-mean
[3]: en.wikipedia.org/wiki/Dynamic_dispatch
Thanks Chris for the great explanation. Looks like I missed it somehow and didn't receive any notification. Sorry for my late reply.
I do agree with you that static methods don't make a lot of sense in OO but I have seen it being used by many programmers. For example if you look at the popular php framework Laravel, they use Facades pretty heavily with static methods.
I loved Laravel's facades when I started out with the framework. Everything works out of the box. But to be honest, it's way too easy to violate SRP everywhere through your project. I only create static facades if having to refactor a bowl of spaghetti. Only as an intermediate step.
anyone cramming for an interview like me loll
Best of luck! Hope you nailed it! How did it go? 😊
@@ChristopherOkhravi i think it went ok but idk.. your videos definitely helped!
Love your passion!! 😀
Hi, just started with design patterns, I'm wondering do I have to read book and watch videos by order to understand better or is it ok to watch arbitrary to encounter my project necessities? Thanks!
It would be very useful if we could have been introduced to a code example. Would love this video even more with it.
Let me see if I understood this....
Imagine that I have a command interface and for a specific command implementation, I need to save some information on the database.
In this case, should I use a Facade pattern to have those subsystems and work with it?
Is that correct?
Can you please do Composite pattern and Flyweight pattern of structural patterns? They are mentioned in the reference book you suggested and is part of my course so I need your help to learn them.
Your tutorials are way better and understandable then what university teacher teaches us. and luckily I just found your videos today on the design patterns.
For the record... the video on Composite is now online :) Thanks for the kind words and for watching :)
An electrical switchboard in your room is like a Facade to all the complex wiring (classes) underneath it . You (Client Code) just have to plug in the wire and turn on the switch, while being completely unaware about how those wires interact with each other and with you (client code)
Excellent example! Thanks for sharing.
Is it the same as repository? Because I don't see a video in repository on this channel
I was trying to read your comment but got distracted with trying to wipe a hair off my screen.
Thank you. I wish there was some code example to this, but a massive thank you!
Not a problem. I'm glad you appreciate it! I'm running a screencast series on patterns in parallell where I'm giving code examples (link below). I haven't gotten to facade yet but eventually it'll be there as well :)
th-cam.com/play/PLrhzvIcii6GNCgHSj44-gXZeTUVbSPC-3.html
@@ChristopherOkhravi great! Thanks for sharing the link. I'll check them out. Your videos are very applicable in my day to day work. Massive thanks.
I am just confused why you mentioned principle of least knowledge? It seems completely not related to the facade pattern?
Please talk about differences between abstract factory and facade
Is the following a valid sentence to describe the problem to a "facade" solution?
"how to allow the Client (the stable part of an application) to use another part of the application which is unstable and/or made of multiple or complex interfaces?"
actually I am new to design patterns bt the second book you have suggested is there in our academics which one I have to follow
Wonderful! Facade design pattern, simplified. Keep up the good work.
Thanks I’m glad to hear it’s appreciated :) Thanks for watching :)
Isn't a facade similar to, if not the same as, a factory or build pattern?
Thanks for the Video Chris... u r awesome...!!! one thing is in my mind , can we somewhere correlate facade with command pattern. even in command pattern we just use a single window as a command(inside complexity can be anything) and in facade we use most accessible interface to call complex inner system. ur thoughts plz !!!
Awesome videos Christopher sir..
but did we missed the code example of this facade pattern ? :)
Nice explanation dude! But tell me one thing... isn’t the "facade class" acting merely as a proxy ?
So the question is what’s the difference between proxy pattern and the facade pattern ? I mean then why do we need 2 separate patterns. Because in essence, both of them ultimately are a mechanism to invoke something by something else (a proxy or a facade).
Ok so a googling gave the answer -> Proxy pattern is to control direct access to a particular object, whereas Facade object provides simplified higher level interface to a subsystem of objects/components.
Nice video, thanks for inspiring me to get more knowledge about as such important thing, which Design Patterns are.
Is the "Safe navigation operator" a kick in demeters face? When you'd use it for example like this:
zip = company?.getCto()?.getAddress()?.getZip()
This feels just wrong, but how would I do this right?
en.wikipedia.org/wiki/Safe_navigation_operator
It is a class which acts as a delegate or forward to actual work of other classes.
Facade makes me think of an elevator. When I want the elevator, I push the call button. When I get in, I push the button for my floor. But there is a lot going on behind the scenes, which I don't know about and which I should not know about. Imagine what it would be like if each user were trying to control the motors and the doors.
On the Law of Demeter, I have a question. If I have a relational database with a join table, let's say a user associated with multiple addresses and vice versa, accessing the address's postal code via C# LINQ query syntax would be something like this (ignore the magic strings and any other bad practices for the example's sake):
(from userAddress in user.UserAddresses where userAddress.UserId == user.Id && userAddress.Type == "Primary" select userAddress.Address).FirstOrDefault().PostalCode
Is this violating Demeter's Law? It seems inevitable that join tables will add one extra layer to the process: object type A queries for all of object type B that belong to it, and from there they access a a property of B which is of type C, and from there access its properties.
I suspect that this is not actually a violation. The join table is a necessary element for B to be a property of A and vice vesa, and thus the join table can, for the sake of the Law of Demeter, be ignored.
I’m interested in that controversy regarding the Law of Demeter.
(Why Demeter, by the way? Is it named after the Ancient Greek goddess or someone else?)
I had the same question that even took me to review the myth of Demeter and Persephone, I am always excited about modern ideas with a mythological meaning or connection. Unfortunately, this law was named after the Demeter Project "an adaptive programming and aspect-oriented programming effort"
In the system I'm currently working with we have a facade layer between the code behind (which in itself has way too much complex code that shouldn't be there) and a service layer. But in 99% of the cases, the facade isn't doing anything useful, it just passes the call on to the service, note that the facade rarely calls more than one service. In these cases, is there any reason not to call the service directly?
Great video as usual!
In case you want to change the behaviours and attributes of the services you use in your client code , you dont have to change the client code that uses the services. It has a kind of decoupling role here. And i aggre that it seems useless until it comes to change or upgrade or fix your library
I would totally buy that if the services were doing more complex things, but mainly the services are just way too simple, like only returning data from mainframe as datasets, which are used directly in the code-behind. Also the facades are duplicated per code-behind, despite calling the same services and relaying the same input and output.
I'm inclined to agree with your comment @Fersah. Consider e.g. the quote "every problem can be solved with another level of indirection". But then again @Hoax, there's the second portion of that quote: "except the problem of too many levels of indirection". So I agree that this is tricky. I would ask myself:
1) Do I own the service I want to consume? Because I would be less vigilant with indirection levels if I do control it or if the third party is something extremely stable that is not shotgun spread across my own code base.
2) Does the service reside in a different codebase/subsystem/process etc? Because if it does I would probably be vigilant.
3) Can I envisage any possible scenario where the cost of not having kept the currently existing abstraction would be significantly more expensive then the cost of maintaining the currently existing abstraction?
But really this is of course a super tricky one and imho one would have to dig into the details :)
Just a few cents but I hope it's at least some food for thought. What do you think?
you are amazing in explaining
Superb videos man. Can you make a video on UML diagram with an example.
By seeing his funny style, body language and expression I thought he is somehow from Head first Team but then I checked with the Head first book contributers and then his youtube page then I find he is not among them but one of their type😁😁😁... but BTW you got the success to achieve the same simplicity as book bro...
Hi Christopher. Does this violate the interface segregation?
I want to learn more about Law of Demeter. Please record a video talking about that.
But how would i apply it?
This video is very clear and very usefull, thank you !
Love your videos Cristopher, never lose that motivation and passion! :-)
Hello Christopher can you give an example of a CRUD process using Facade pattern? Thank you for this info. Good job buddy
Suppose there is an REST API and in service layer lot of complexities are going on. All the complexities (working) are behind that REST API.
User of that API only knows what is required to call that API not aware about any complexities behind the API. is it facade pattern??
Any one can help me to understand this.
very nice explanation .. thanks buddy.
awesome video .. thanks! u helped me in my assignment......
+john mayor Nice! I'm glad to hear :) Thanks :)
Good Explanation ! Looking forward on java example ..
I love your cat!
Thanks for good explanations and good mood! :)
Is there going to be LOD video anytime soon?
Realistically unfortunately not soon :) But as absolutely soon as possible :D Dropping design pattern whiteboard videos every Monday turns out to be trickier than I thought :) But I'm staying consistent :D :D Thank you super much for watching :) and apologies for not being able to accommodate quicker :/
No worries! I understand. If you don't mind me asking what do techs you develop in?
Your lessons about design patters help me a lot, thank you , but i couldn't find flyweight problem
Cute cat at 2:48
great as always
Underrated 🔥
You are awesome.Can you please go with other patterns too
Thanks! I'm glad to hear. Check out the latest video. I've decided to run through "all" OO patterns :)
Love your videos bro
Nice Explanation!