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
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.
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.
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.
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!
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'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 :)
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!
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 UA-cam itself. I will be very grateful, but not only me, a lot of people. Thanks!
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!
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.
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.
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).
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 :) ua-cam.com/play/PLrhzvIcii6GNCgHSj44-gXZeTUVbSPC-3.html
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.
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?
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.
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.
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.
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?
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?
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 !!!
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...
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.
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 :/
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?
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?
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)
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!
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.
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
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?
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
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
This all you need from this video
7:21 to 8:52
15:00 to 15:45 :-)
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 CLIENT explanation at 1:15 would have saved me years of confusion had I heard it ten years ago....so important
You are a great teacher Christoper, and I love how you share your inner thoughts on the topic aswell!
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
Loved it!! This man energy is unmatchable !!
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.
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.
14:26 Forthlly....finally
Dude you are awesome. Understanding design patterns has never been easier for me. Goodwork and Thanks.
Keep them coming mate!!
Thanks for sticking around! :) Will do. Next one should drop during the upcoming weekend.
Your energy gave me 5 extra years of life, so thanks!
You are a real ninja in explaining complicated stuff very easily. Thumb up!
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 ! The way you move and change the camera view makes the video interesting!
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
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!
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
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 :)
Dude! you make tutorials like a ninja!
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!
Your videos are the best about design patterns! Thank you for your work.
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 UA-cam itself. I will be very grateful, but not only me, a lot of people.
Thanks!
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 :)
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 !!
Thank you so much for all your help! Please keep making tutorials!
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!
The discussion over a not talking to c directly.. and increasing responsibility on b.. would be great! 🙌
Love your passion!! 😀
So good they all make sense now. I have taken the red pill!
+Alexander Nava Hehe :) Thank you for the comment :D
I don't understand why there is stll only 21k views for the videos. It is awesome, Easy and clear.
Wonderful! Facade design pattern, simplified. Keep up the good work.
Thanks I’m glad to hear it’s appreciated :) Thanks for watching :)
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.
One word: Brillant!
thank you so much i have a final exam tomorrow in software designand architcture and this is really helpfull
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.
Well done Ishant Sharma!
Love your videos Cristopher, never lose that motivation and passion! :-)
Im not that good at english but the way you explain it its just fantastic, thanks for making this videos, you are really great
SLF4J, used for logging purposes in Java, is a very good example depicting usage of this pattern.
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!
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).
great as always
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 :)
ua-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.
Nice video, thanks for inspiring me to get more knowledge about as such important thing, which Design Patterns are.
Great video! it gets pretty quick to the point I wanted to reach, I love it when that happens. Thanks for the vid ;)
you are amazing in explaining
Love your videos bro
Nice explanation.
An example would have been great.
Would an API be a facade pattern?
This video is very clear and very usefull, thank you !
0:00 - Rowan Atkinson
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.
It would be very useful if we could have been introduced to a code example. Would love this video even more with it.
awesome video .. thanks! u helped me in my assignment......
+john mayor Nice! I'm glad to hear :) Thanks :)
Thanks for good explanations and good mood! :)
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?
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.
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.
I realy love your videos :)
very nice explanation .. thanks buddy.
I love your cat!
Awesome videos Christopher sir..
but did we missed the code example of this facade pattern ? :)
Nice Explanation!
great content ...thank u so much...
I'm a game developer, in our project there are a lot of "XXXContext" class, which is the facede pattern?
Please talk about differences between abstract factory and facade
Cute cat at 2:48
You are hilarious! 😂 Thanks man :)
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 :)
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?
I want to learn more about Law of Demeter. Please record a video talking about that.
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?
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 :)
Underrated 🔥
great explanation, thanks lot
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 !!!
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
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...
Your lessons about design patters help me a lot, thank you , but i couldn't find flyweight problem
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.
Perfect explanation! :)
I am just confused why you mentioned principle of least knowledge? It seems completely not related to the facade pattern?
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?
Does controller is a kind of facade pattern?
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?
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?
Good Explanation ! Looking forward on java example ..
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.
Superb videos man. Can you make a video on UML diagram with an example.
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.
Facade pattern conflics with single responsability principle?
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!
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.
I will like any video with this cat doing a cameo
That catty at 16:17 😁😂!
Very nice explanation :)
Thank you. I appreciate you taking the time to comment. And thanks for watching :)
Hi Christopher. Does this violate the interface segregation?
Isn't a facade similar to, if not the same as, a factory or build pattern?