From 9b7ea6aed9b1ed75f7c10e840c1151d3881e676f Mon Sep 17 00:00:00 2001 From: Zeger Hendrikse Date: Tue, 9 Jan 2024 14:16:24 +0100 Subject: [PATCH] Update README.md --- tdd-katas/tell-dont-ask/README.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/tdd-katas/tell-dont-ask/README.md b/tdd-katas/tell-dont-ask/README.md index 38afa90a..4c60b34a 100644 --- a/tdd-katas/tell-dont-ask/README.md +++ b/tdd-katas/tell-dont-ask/README.md @@ -1,11 +1,11 @@ This is a fork of the original Tell Don't Ask Kata of [@rachelcarmena](https://github.com/rachelcarmena/tell-dont-ask-kata) in Java. -Here you'll find a Python version. A Typescript version is planned as well. +In this directory, you'll find ports to other languages as well. # Tell Don't Ask Kata A legacy refactor kata, focused on the violation of the [tell don't ask](https://pragprog.com/articles/tell-dont-ask) principle and the [anemic domain model](https://martinfowler.com/bliki/AnemicDomainModel.html). ## Instructions -Here you find a simple order flow application. It's able to create orders, do some calculations (totals and taxes), and manage them (approval/reject and shipment). +Here you find a simple order flow application. It's able to create orders, do some calculations (totals and taxes), and manage them (approval/rejection and shipment). The old development team did not find the time to build a proper domain model but instead preferred to use a procedural style, building this anemic domain model. Fortunately, they did at least take the time to write unit tests for the code. @@ -13,9 +13,10 @@ Fortunately, they did at least take the time to write unit tests for the code. Your new CTO, after many bugs caused by this application, asked you to refactor this code to make it more maintainable and reliable. ## What to focus on -As the title of the kata says, of course, the tell don't ask principle. -You should be able to remove all the setters moving the behavior into the domain objects. + +As the title of the kata says, of course, the purpose is to get acquainted with the tell-don't-ask principle. +Eventually, you should be able to remove all the setters from the domain objects by moving the behavior into those very domain objects. But don't stop there. -If you can remove some test cases because they don't make sense anymore (eg: you cannot compile the code to do the wrong thing) feel free to do it! +If you can remove some test cases because they don't make sense anymore, feel free to do so!