Does it actually improve coffee clarity if your methods might not do what their name suggests? Even if it adheres to the specification, this sounds like asking for trouble in thur future.
Hi Christopher, nice video. What about cases where you execute a command for deleting an entity (changing a flag on a db). For example, in a clean architecture executing a use case for deleting a dog, and you only use dogToDelete.validateDeletion() in order to throw an Error if u cant delete it (For having a dependency with one lf its attributes for example). If It's ok, u use a dogRepository.delete(dogId). I think that it is a good case for breaking the TDA principle, having sense.
I watch way too many conference talks on UA-cam. A few suggested names of the top of my head: sandi Metz, uncle bob, misko hevry, rich hickey, Martin Fowler, Bryan Cantrill. But the recommendation algorithm of UA-cam will lead you further down the rabbit hole once you get going 😊😊😊 Bests of lucks!
What if I need to do the below Object->prepare(xObject, [data]): xObject Object->save(xObject); As I understand I need to refactor it to Object->save(xObject, [data]); To follow tell not ask, Is that correct or not?
So if I tell a mix of 10 000 animals like dogs, cats and llamas to eat(food) maybe 4592 of the animals do and the rest don't so all I have to do is loop through the animals and tell them to eat and they do the rest on their own saving me from handling all the chores involved in making them eat. Yeah, that's useful!!! Even more so in a particle system of some kind, than in a household with three pets.
I doesn't, you're sticking the responsibility (and reason to change) to the class that has the information, which is also called as "expert class" in the GRASP principles. Also, by now avoiding to inspect the internal structure of the class animal, you comply with Demeter's Law; we shouldn't need to know the internal structure of the objects we work with.
Passing information won't be a win because then Animal class will have to know about external factors. Going by clean code, animal should be the innermost entity
Not at all. I like the attention :D You're absolutely right. 9000 '98. Good eyes! :) You drive one or how did you know? It's old and wonky but it's got character and storage space is almost unbeatable :)
Christopher Okhravi i have naver had a 9000 but i had two classic 9-3s. All old saabs have simillar interiors that's why i recognised it's a saab. Great cars, especially the old ones.
Let me preface this by saying great videos! I'm still a little fuzzy on this. Let's talk about your example. class Animal { void eat(Food food) { if(!isHungry()) { return; } // fill stomach with food } } Now the user of Animal will call only animal.eat(food); Works fine. But then we are hardcoding the behavior of the animal. If tomorrow there is a different user, who wants to feed the animal even if it is not hungry, there is no way to do that unless you rewrite the eat() function. If your answer to this is dependency injection and pass in a parameter in the eat() function, then you ALREADY know about the internal state of the animal. Thoughts?
In this case for the law of demeter and the tell don't ask principle you would just add a second function called forceEat, or you would pass a bool into your eat function called bForce to override the hungry check.
Very thought stimulating concept. Thanks! However, in case of costly operations (that are not part of Animal's behaviour) need such checks to be performed, viz. if (animal.isHungry()) { Food favFood = chef.cookFavoriteFor(animal); // costly operation animal.eat(favFood); }
What if I need to do the below Object->prepare(xObject, [data]): xObject Object->save(xObject); As I understand I need to refactor it to Object->save(xObject, [data]); To follow tell not ask, Is that correct or not?
I hope that your knowledge gets bigger and bigger so that we can always get good videos :)
Just learned about it, it's an amazing principle
Does it actually improve coffee clarity if your methods might not do what their name suggests? Even if it adheres to the specification, this sounds like asking for trouble in thur future.
Hi Christopher, nice video. What about cases where you execute a command for deleting an entity (changing a flag on a db).
For example, in a clean architecture executing a use case for deleting a dog, and you only use dogToDelete.validateDeletion() in order to throw an Error if u cant delete it (For having a dependency with one lf its attributes for example). If It's ok, u use a dogRepository.delete(dogId).
I think that it is a good case for breaking the TDA principle, having sense.
Hey Christopher, where do you learn all of that stuff? if books, then what books did you study from?
I watch way too many conference talks on UA-cam. A few suggested names of the top of my head: sandi Metz, uncle bob, misko hevry, rich hickey, Martin Fowler, Bryan Cantrill. But the recommendation algorithm of UA-cam will lead you further down the rabbit hole once you get going 😊😊😊 Bests of lucks!
@@ChristopherOkhravi thank you 👌
You couldn't be clearer. Thanks for the video.
Very good video I would recommended it to my coworkers
Jean-François Collin thanks! I'm glad. Please do :)
You are great at explaining things . thank you !
Great explanation. Thanks.
Illuminating, thanks 😀
Bikes are running faster than your car 😂😂
how about filling up the car with gasoline?
What if I need to do the below
Object->prepare(xObject, [data]): xObject
Object->save(xObject);
As I understand I need to refactor it to
Object->save(xObject, [data]);
To follow tell not ask, Is that correct or not?
So if I tell a mix of 10 000 animals like dogs, cats and llamas to eat(food) maybe 4592 of the animals do and the rest don't so all I have to do is loop through the animals and tell them to eat and they do the rest on their own saving me from handling all the chores involved in making them eat. Yeah, that's useful!!! Even more so in a particle system of some kind, than in a household with three pets.
Command Query Seperation??
How do this not break SRP?
I doesn't, you're sticking the responsibility (and reason to change) to the class that has the information, which is also called as "expert class" in the GRASP principles. Also, by now avoiding to inspect the internal structure of the class animal, you comply with Demeter's Law; we shouldn't need to know the internal structure of the objects we work with.
thanks for the explanation! It was very helpful :)
Ana Clara Cavalcante thanks. I'm glad it's useful :)
Passing information won't be a win because then Animal class will have to know about external factors. Going by clean code, animal should be the innermost entity
Sorry for being off-topic but is that saab 9k?
Not at all. I like the attention :D You're absolutely right. 9000 '98. Good eyes! :) You drive one or how did you know? It's old and wonky but it's got character and storage space is almost unbeatable :)
Christopher Okhravi i have naver had a 9000 but i had two classic 9-3s. All old saabs have simillar interiors that's why i recognised it's a saab. Great cars, especially the old ones.
Great video, Thank you very much.
.
You probably want to put this video in a 'Code Driving' series instead ;)
Let me preface this by saying great videos!
I'm still a little fuzzy on this.
Let's talk about your example.
class Animal {
void eat(Food food) {
if(!isHungry()) { return; }
// fill stomach with food
}
}
Now the user of Animal will call only animal.eat(food);
Works fine.
But then we are hardcoding the behavior of the animal.
If tomorrow there is a different user, who wants to feed the animal even if it is not hungry, there is no way to do that unless you rewrite the eat() function.
If your answer to this is dependency injection and pass in a parameter in the eat() function, then you ALREADY know about the internal state of the animal.
Thoughts?
In this case for the law of demeter and the tell don't ask principle you would just add a second function called forceEat, or you would pass a bool into your eat function called bForce to override the hungry check.
Good Example...
Does the “tell don’t ask” principle contradict how real people interact? People ask other people things such as, “are you hungry?”
I'm very sorry to say your example is not clear. Since you did't show the correct method invocation and exception handling
Very thought stimulating concept. Thanks!
However, in case of costly operations (that are not part of Animal's behaviour) need such checks to be performed, viz.
if (animal.isHungry()) {
Food favFood = chef.cookFavoriteFor(animal); // costly operation
animal.eat(favFood);
}
What if I need to do the below
Object->prepare(xObject, [data]): xObject
Object->save(xObject);
As I understand I need to refactor it to
Object->save(xObject, [data]);
To follow tell not ask, Is that correct or not?