Tell Don't Ask | Code Walks 011

Поділитися
Вставка
  • Опубліковано 18 гру 2024

КОМЕНТАРІ • 34

  • @mohamadmsepes3403
    @mohamadmsepes3403 7 років тому +7

    I hope that your knowledge gets bigger and bigger so that we can always get good videos :)

  • @NicoFye
    @NicoFye 13 днів тому

    Just learned about it, it's an amazing principle

  • @tomwimmenhove4652
    @tomwimmenhove4652 4 роки тому +2

    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.

  • @alejoscotti5033
    @alejoscotti5033 3 роки тому +2

    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.

  • @yanivavrahami842
    @yanivavrahami842 5 років тому +3

    Hey Christopher, where do you learn all of that stuff? if books, then what books did you study from?

    • @ChristopherOkhravi
      @ChristopherOkhravi  5 років тому +10

      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!

    • @yanivavrahami842
      @yanivavrahami842 5 років тому

      @@ChristopherOkhravi thank you 👌

  • @doblejj
    @doblejj 3 роки тому

    You couldn't be clearer. Thanks for the video.

  • @jean-francoiscollin8267
    @jean-francoiscollin8267 7 років тому +3

    Very good video I would recommended it to my coworkers

  • @autorotate1803
    @autorotate1803 4 роки тому

    You are great at explaining things . thank you !

  • @agustinlawtaro
    @agustinlawtaro 3 роки тому

    Great explanation. Thanks.

  • @tehawes0mesauce
    @tehawes0mesauce 5 років тому

    Illuminating, thanks 😀

  • @linux_lectures226
    @linux_lectures226 3 роки тому

    Bikes are running faster than your car 😂😂

  • @rudinandrey
    @rudinandrey 2 роки тому

    how about filling up the car with gasoline?

  • @mohamedhafezqo
    @mohamedhafezqo 5 років тому

    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?

  • @pinkponyofprey1965
    @pinkponyofprey1965 7 років тому +2

    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.

  • @computewitharjun
    @computewitharjun Рік тому

    Command Query Seperation??

  • @Himura1414
    @Himura1414 4 роки тому

    How do this not break SRP?

    • @julianmontesdeoca1420
      @julianmontesdeoca1420 4 роки тому

      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.

  • @AnaClaraCavalcante
    @AnaClaraCavalcante 7 років тому +1

    thanks for the explanation! It was very helpful :)

  • @susmitvengurlekar
    @susmitvengurlekar 2 роки тому

    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

  • @mickaj
    @mickaj 7 років тому

    Sorry for being off-topic but is that saab 9k?

    • @ChristopherOkhravi
      @ChristopherOkhravi  7 років тому

      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 :)

    • @mickaj
      @mickaj 7 років тому

      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.

  • @alifellahi
    @alifellahi 7 років тому

    Great video, Thank you very much.
    .
    You probably want to put this video in a 'Code Driving' series instead ;)

  • @VikramKaull
    @VikramKaull 7 років тому +1

    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?

    • @TheBendixSA
      @TheBendixSA 5 років тому +1

      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.

  • @NikeJustDoItBeaverton
    @NikeJustDoItBeaverton 7 років тому

    Good Example...

  • @justingiovanetti
    @justingiovanetti 3 роки тому

    Does the “tell don’t ask” principle contradict how real people interact? People ask other people things such as, “are you hungry?”

  • @desarrollojava
    @desarrollojava 4 роки тому

    I'm very sorry to say your example is not clear. Since you did't show the correct method invocation and exception handling

  • @satyendrakumarsharma3513
    @satyendrakumarsharma3513 4 місяці тому

    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);
    }

  • @mohamedhafezqo
    @mohamedhafezqo 5 років тому

    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?