Well done sir. I almost didn't watch since it had so few views, but your description is great and the Ocean/Fish/Hungry example illustrated the principle perfectly. I hope more people will watch this video.
The purpose of the Law of Demeter is good. The problem is in the solution to apply, which requires adding methods in A (Ocean.HungryFishes) that hide the information from C (Fish.IsHungry). The fact that the program has a need and that involves adding a method to a class should be carefully considered. I think that in general a class should not be modified because another class needs it. In this example, it would end up being that (Ocean) would have all possible combinations of filters that the program needs (HungryFishes, NotHungryFishes, SmallFishes, BigFishes, OldFishes, YoungFishes, whatever...). I think you have to find a balance between hiding information and making objects concise. If exposing a couple of methods used for (Ocean), we manage to cover most of the program's need, then it is a good solution to apply the Law of Demeter directly on (Ocean). The moment we detect that a class becomes a bag of methods with the potential to grow, it is time to consider a different approach, perhaps creating a specific query class (OceanQuerier), which receives an instance of (Ocean) in the constructor and offer a collection of query methods on the fish, hiding the fish detail information (Fish.IsHungry).
Thanks Chirs!! Your style of explaining things always prompts more thoughts and curiosity. QUESTION: If we avoid dependency of A to B to C, and rather keep adding more methods in A that directly provide the required (eventual) results. Won't it pollute A and introduce more reasons for it to change (S of SOLID)? My thoughts: Isn't it a good candidate for the Visitor Design Pattern? Some visitors may visit A and help it with the required operations. Please suggest your thoughts.
It is amazing to discover all your videos during my learning journey! I did a lot of mistakes in the past that you talked about in this video and that why I start exploring knowledge about OOP. It's super fascinating and useful.
Wait, so should the ocean return the list of hungry fishes to the main program and then we call eat() on those fishes from the main program? I dont see much of a difference to the original situation, since the main program is still coupled to both the ocean and the fish. So wr didnt really reduce coupling in the end, did we? How about calling feedHungryFishes() on the ocean, which then does everything, so the main program doenst have to know about the fish class anymore?
Thanks, Christopher, for the explanation. I wonder if you could provide a code example of this? I understand the concept but am unsure how to implement it in an application.
very well explained, it is ok to chain if you are accessing data structures, order.getCustomer().getBillingAddress().getCity(); it is not okay if you access behavioural objects such as order.getInvoice().generate(); where getInvoice method will initialise a new invoice instance and set its customer and order details to generate an invoice which is too much knowledge exposed to the order object/data structure.
I think I get the idea but I'm not sure, so lets say that you have some kind of game, which has a collection of levels and the levels have some block in them. And can ask the blocks if they've been hit. So it's okay for the game to ask the level if any blocks have been it. ( game.level.hasABlockBeenHit(); ) But it's not okay for the game to ask a block in the level if it has been hit ( game.level.block.beenHit(); ) Or is the best way even to ask the level for it's blocks and then ask the blocks if they've been hit (assuming that is not the responsibility of the level for some reason) which would look like this: blocks = game.level.getBlocks(); game.blocks.beenHit(); Am I getting it right?
I'm not sure your example actually illustrates Demeter. Fish is presumably a separate and independent class from Ocean. Ocean's method only returns Fish (or a collection thereof). The Fish class is free to expose whatever method it needs to expose. Ocean shouldn't have to be concerned with the internals, behavior and use cases of Fish. A client of Ocean may choose to create a facade on Ocean that returns all hungry fish, but that would be because of that client's particular use case. If your example does in fact reflect Demeter as it is intended, then the "law of Demeter" is a horrible idea. If followed, it'll lead to ludicrous API explosions. Entire design patterns wouldn't even exist. The Builder pattern would be one example: gone! If applied at a higher scale, the entire ReST architectural style would vanish.
Well done sir. I almost didn't watch since it had so few views, but your description is great and the Ocean/Fish/Hungry example illustrated the principle perfectly. I hope more people will watch this video.
I'm glad! :) Thanks for the comment, and thanks for letting me know about the views. Got some work to do there :) :)
The purpose of the Law of Demeter is good. The problem is in the solution to apply, which requires adding methods in A (Ocean.HungryFishes) that hide the information from C (Fish.IsHungry).
The fact that the program has a need and that involves adding a method to a class should be carefully considered. I think that in general a class should not be modified because another class needs it. In this example, it would end up being that (Ocean) would have all possible combinations of filters that the program needs (HungryFishes, NotHungryFishes, SmallFishes, BigFishes, OldFishes, YoungFishes, whatever...).
I think you have to find a balance between hiding information and making objects concise. If exposing a couple of methods used for (Ocean), we manage to cover most of the program's need, then it is a good solution to apply the Law of Demeter directly on (Ocean). The moment we detect that a class becomes a bag of methods with the potential to grow, it is time to consider a different approach, perhaps creating a specific query class (OceanQuerier), which receives an instance of (Ocean) in the constructor and offer a collection of query methods on the fish, hiding the fish detail information (Fish.IsHungry).
Wow! Great video! This is the clearest explanation I've heard for this concept.
You deserve waaaay more subscribers! This video is great! I will watch all of your videos now.
Best comment :) :)
I finally understood the Law of Demeter. Thank you, Mr. Okhravi.
At first I did not understand, but with the ocean example and the remark about data hiding it all came together. Tack så mycket
Now it makes sense! Thanks for explaining it Christopher. The hungry fish was a great example and will stick in my mind.
The examples for explanations is just fantastic. :)
Thank you! I'm glad they make sense :)
Thanks Chirs!! Your style of explaining things always prompts more thoughts and curiosity.
QUESTION: If we avoid dependency of A to B to C, and rather keep adding more methods in A that directly provide the required (eventual) results.
Won't it pollute A and introduce more reasons for it to change (S of SOLID)?
My thoughts: Isn't it a good candidate for the Visitor Design Pattern? Some visitors may visit A and help it with the required operations.
Please suggest your thoughts.
I'm glad I saw your video on Strategy Pattern before watching this, as I can see the benefits of structuring stuff this way.
It is amazing to discover all your videos during my learning journey! I did a lot of mistakes in the past that you talked about in this video and that why I start exploring knowledge about OOP.
It's super fascinating and useful.
Hi! Perfect topic! Where are you getting all of them for code-walks? Could you please add a source of it into the description?
I hope you continue to more videos it's been a while since you last uploaded.
Wait, so should the ocean return the list of hungry fishes to the main program and then we call eat() on those fishes from the main program? I dont see much of a difference to the original situation, since the main program is still coupled to both the ocean and the fish. So wr didnt really reduce coupling in the end, did we? How about calling feedHungryFishes() on the ocean, which then does everything, so the main program doenst have to know about the fish class anymore?
Thanks, Christopher, for the explanation. I wonder if you could provide a code example of this? I understand the concept but am unsure how to implement it in an application.
I think this "law" is about information hiding not coupling.
Love the explanation
fantastic!!
Well done!
+Ali Mir Thank you! I'm glad the video is useful! :) Thanks for watching :)
A very good explanation. The best I found :) Keep up the good work!
very clear explaination, thanks a lot
very well explained, it is ok to chain if you are accessing data structures, order.getCustomer().getBillingAddress().getCity(); it is not okay if you access behavioural objects such as order.getInvoice().generate(); where getInvoice method will initialise a new invoice instance and set its customer and order details to generate an invoice which is too much knowledge exposed to the order object/data structure.
Great video! Thank you!
Is fluent apis/builder pattern/Java streams considered to be breaking this law?
Builder returns a single object, no matter how many builder methods called, so it does not violate the law
Good one ... well explained
Demeter would not like JavaScript.
+Scott D hahah :)
Awesome video! Please let me add subtitles so I can easily share this! (The same would be awesome for all your videos)
I think I get the idea but I'm not sure, so lets say that you have some kind of game, which has a collection of levels and the levels have some block in them. And can ask the blocks if they've been hit.
So it's okay for the game to ask the level if any blocks have been it. ( game.level.hasABlockBeenHit(); )
But it's not okay for the game to ask a block in the level if it has been hit ( game.level.block.beenHit(); )
Or is the best way even to ask the level for it's blocks and then ask the blocks if they've been hit (assuming that is not the responsibility of the level for some reason) which would look like this:
blocks = game.level.getBlocks();
game.blocks.beenHit();
Am I getting it right?
I'm not sure your example actually illustrates Demeter. Fish is presumably a separate and independent class from Ocean. Ocean's method only returns Fish (or a collection thereof). The Fish class is free to expose whatever method it needs to expose. Ocean shouldn't have to be concerned with the internals, behavior and use cases of Fish. A client of Ocean may choose to create a facade on Ocean that returns all hungry fish, but that would be because of that client's particular use case.
If your example does in fact reflect Demeter as it is intended, then the "law of Demeter" is a horrible idea. If followed, it'll lead to ludicrous API explosions. Entire design patterns wouldn't even exist. The Builder pattern would be one example: gone! If applied at a higher scale, the entire ReST architectural style would vanish.
great
Clear explanation, the law is highly questionable though.
I liked this bro :)
You are Magic :D