Timeline for How do you avoid getters and setters?
Current License: CC BY-SA 3.0
23 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 28, 2021 at 23:05 | comment | added | Eugene | ^-- After thinking some more about it I tend to belive CQRS is the correct solution to the problem mentioned in my prev comment | |
| Nov 28, 2021 at 2:12 | comment | added | Eugene |
I somehow like the toDTO() - I'd probably call it transfer() - approach for use cases where you need to access a lot of fields of domain entities in order to make them cross boundaries e.g. in a HTTP API response. It's much better than accessing all the individual fields through getters and putting the data that way into the response, because a transfer() method is expressing the purpose very specifically and prevents careless misuse of the countless would-be-added getters on the domain entities. It's easy to spot if some yokel is abusing that method.
|
|
| Sep 6, 2021 at 4:02 | comment | added | aderchox |
1_ Where does that "IEquatable" (which you say you've abbreviated in your answer) belong to? May I know where you wanted to use this interface? 2_ Also about this line: "return _position.Equals(other._position);", would this be possible at all? It's accessing a private field of another object(although it's of the same class, it doesn't make a difference, private field cannot be read from an object).
|
|
| Jun 16, 2020 at 10:01 | history | edited | CommunityBot |
Commonmark migration
|
|
| S Jun 5, 2015 at 18:46 | history | suggested | CommunityBot | CC BY-SA 3.0 |
Fixed datatype.
|
| Jun 5, 2015 at 18:18 | review | Suggested edits | |||
| S Jun 5, 2015 at 18:46 | |||||
| Jun 3, 2015 at 15:38 | comment | added | radarbob | I really like the Design for Behavior concept. This informs the underlying "data structure" and helps avoid the all too common anemic, hard-to-use classes. plus one. | |
| Jun 3, 2015 at 13:21 | history | edited | Ben Aaronson | CC BY-SA 3.0 |
added 701 characters in body
|
| Jun 1, 2015 at 14:00 | history | bounty ended | IntelliData | ||
| Jun 1, 2015 at 14:00 | vote | accept | IntelliData | ||
| May 28, 2015 at 18:55 | comment | added | IntelliData | Let us continue this discussion in chat. | |
| May 28, 2015 at 18:40 | comment | added | IntelliData | In general, would u say that 'Tell Don't Ask' means never return data? How is that possible? | |
| May 28, 2015 at 18:37 | comment | added | IntelliData | 1. 'Tell, Don't Ask', good point; however, if I say provideDTO(), is it in effect 'Tell' even though it returns something? (Yeah, I know it's only a semantical difference.) 2. If a behaviour providing Customer also has data, whose responsibility is it to change the data if necessary? | |
| May 28, 2015 at 18:25 | comment | added | Ben Aaronson |
@IntelliData Yeah I understand. I agree toDTO it may mitigate that, but as I mentioned in the comment, there are other problems (violation of "Tell, Don't Ask"), which it does not.
|
|
| May 28, 2015 at 18:20 | comment | added | IntelliData | I mean change class definition; even exposing getters only can be a problem: say I have several functions calling getDTO() on the object, I can always change the fields being exposed via getDTO() w/o breaking the code; however, if I do getProperty(), then if I remove the property later on I will be breaking the code in many places. | |
| May 28, 2015 at 18:03 | comment | added | Ben Aaronson |
@IntelliData Keeping the Customer domain object's data relatively fresh (in sync with the db) is a matter of managing its lifecycle, which is also not its own responsibility, and would again probably end up living in a repository or a factory or an IOC container or whatever instantiates Customers.
|
|
| May 28, 2015 at 18:03 | comment | added | Ben Aaronson |
@IntelliData 2. This is difficult to answer without knowing the behaviour. But probably, the answer is: you wouldn't. What behaviour could a Customer class have that requires being able to mutate its telephone number? Perhaps the customer's telephone number changes and I need to persist that change in the database, but none of that is the responsibility of a behaviour-providing domain object. That's a data-access concern, and would probably be handled with a DTO and, say, a repository.
|
|
| May 28, 2015 at 17:58 | comment | added | Ben Aaronson | @IntelliData 1. When you say "change the fields", you mean change the class definition or mutate the data? The latter can just be avoided by removing public setters but leaving the getters, so the dto aspect is irrelevant. The former isn't really the (whole) reason that public getters are "evil". See programmers.stackexchange.com/questions/157526/… for example. | |
| May 28, 2015 at 17:02 | comment | added | IntelliData | Beautifully answered! I would like to accept, but first some comments:1. I do think the toDTO() is great, bcuz ur not accessing the get/set, which allows u to change the fields given to DTO w/o breaking existing code. 2. Say Customer has enough behaviour to justify making it an entity, how would u access props to modify them, e.g. address/tel change etc. | |
| May 28, 2015 at 17:01 | vote | accept | IntelliData | ||
| May 28, 2015 at 17:01 | |||||
| May 28, 2015 at 15:09 | history | edited | Ben Aaronson | CC BY-SA 3.0 |
added 487 characters in body
|
| May 28, 2015 at 13:45 | history | edited | Ben Aaronson | CC BY-SA 3.0 |
added 25 characters in body
|
| May 28, 2015 at 13:40 | history | answered | Ben Aaronson | CC BY-SA 3.0 |