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.
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.
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.
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!
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.
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!
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.
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.
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 :)
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.
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...
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).
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)
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.
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
These are amazing videos Chris. Love how you teach the design patterns. One quick thing about Facade pattern: I think it is very similar to Factory pattern instead of Adapter/Decorator patterns.
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 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.
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 !!!
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.
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.
One new comer on my company totally does not understand decoupling and cohesion. It is important as much as data structure and algorithm. But the school doest teach that.
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?
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 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?"
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 :-)
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.
The CLIENT explanation at 1:15 would have saved me years of confusion had I heard it ten years ago....so important
thank you so much i have a final exam tomorrow in software designand architcture and this is really helpfull
You are a great teacher Christoper, and I love how you share your inner thoughts on the topic aswell!
The discussion over a not talking to c directly.. and increasing responsibility on b.. would be great! 🙌
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.
I don't understand why there is stll only 21k views for the videos. It is awesome, Easy and clear.
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 ! The way you move and change the camera view makes the video interesting!
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
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.
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
14:26 Forthlly....finally
Dude you are awesome. Understanding design patterns has never been easier for me. Goodwork and 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!
Im not that good at english but the way you explain it its just fantastic, thanks for making this videos, you are really great
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.
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!
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
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!
Well done Ishant Sharma!
Loved it!! This man energy is unmatchable !!
Dude! you make tutorials like a ninja!
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 :)
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.
SLF4J, used for logging purposes in Java, is a very good example depicting usage of this pattern.
So good they all make sense now. I have taken the red pill!
+Alexander Nava Hehe :) Thank you for the comment :D
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 !!
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 :)
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.
Keep them coming mate!!
Thanks for sticking around! :) Will do. Next one should drop during the upcoming weekend.
Nice video, thanks for inspiring me to get more knowledge about as such important thing, which Design Patterns are.
Your videos are the best about design patterns! Thank you for your work.
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.
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...
Wonderful! Facade design pattern, simplified. Keep up the good work.
Thanks I’m glad to hear it’s appreciated :) Thanks for watching :)
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).
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.
Thank you so much for all your help! Please keep making tutorials!
Your lessons about design patters help me a lot, thank you , but i couldn't find flyweight problem
It would be very useful if we could have been introduced to a code example. Would love this video even more with it.
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.
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.
These are amazing videos Chris. Love how you teach the design patterns. One quick thing about Facade pattern: I think it is very similar to Factory pattern instead of Adapter/Decorator patterns.
One word: Brillant!
Nice explanation.
An example would have been great.
Would an API be a facade pattern?
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 :)
you are amazing in explaining
Superb videos man. Can you make a video on UML diagram with an example.
I will like any video with this cat doing a cameo
Love your passion!! 😀
Good Explanation ! Looking forward on java example ..
very much simply explained, thank you ; would like to hear the explanation with an example and code..
Cute cat at 2:48
Love your videos Cristopher, never lose that motivation and passion! :-)
You r a gem to society
I have feeling that cat in video listen it several time. 😊 If you need expert in design patters, try to get this cat in your company. 😊
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!
It is a class which acts as a delegate or forward to actual work of other classes.
awesome video .. thanks! u helped me in my assignment......
+john mayor Nice! I'm glad to hear :) Thanks :)
I want to learn more about Law of Demeter. Please record a video talking about that.
This video is very clear and very usefull, thank you !
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.
Love your videos bro
great as always
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
I love your cat!
Awesome videos Christopher sir..
but did we missed the code example of this facade pattern ? :)
very nice explanation .. thanks buddy.
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 !!!
Hello Christopher can you give an example of a CRUD process using Facade pattern? Thank you for this info. Good job buddy
Great video! it gets pretty quick to the point I wanted to reach, I love it when that happens. Thanks for the vid ;)
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.
Please talk about differences between abstract factory and facade
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 :)
Thanks for good explanations and good mood! :)
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.
Nice Explanation!
One new comer on my company totally does not understand decoupling and cohesion. It is important as much as data structure and algorithm. But the school doest teach that.
Facade -> easiest till now.
I'm not watching your movie but for your cat...
So remember people for objects the saying goes like this: "the friend of my friend is my enemy" :))
So basically a facade is an interface, but we refrain from using that term as to not get it confused with interfaces.
great explanation, thanks lot
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?
Underrated 🔥
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 decoupling good or bad? offcourse its good. You are so funny.
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?"
A Facade is like a Macro!
great content ...thank u so much...
Very nice explanation :)
Thank you. I appreciate you taking the time to comment. And thanks for watching :)
Waiting for the differences video ...
I thought there was a ghost @14.20 ....😜
Heheheheh :)
I realy love your videos :)
You are hilarious! 😂 Thanks man :)