Timeline for Why DDD models should have private setters?
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 2, 2021 at 17:26 | answer | added | Abbas Amiri | timeline score: 6 | |
| Jul 2, 2021 at 5:34 | comment | added | Bart van Ingen Schenau | @FilipMilovanović, those two comments should have been an answer. Can you convert them to one? | |
| Jul 1, 2021 at 16:23 | answer | added | user362602 | timeline score: 2 | |
| Jul 1, 2021 at 13:31 | comment | added | underthevoid | @FilipMilovanović very fruitful information, thanks. If I may, could you name and briefly explain another use cases which would be correct to use the plain old data scheme on models and let them with the classic public get/set accessors? | |
| Jul 1, 2021 at 13:27 | vote | accept | underthevoid | ||
| Jul 1, 2021 at 12:19 | review | Close votes | |||
| Jul 6, 2021 at 3:01 | |||||
| Jul 1, 2021 at 3:54 | answer | added | VoiceOfUnreason | timeline score: 14 | |
| Jul 1, 2021 at 3:16 | comment | added | Filip Milovanović | E.g., when you use the Random class, it just exposes the Next method and its variants, it doesn't allow you to set (or get) internal state of the underlying RNG. It conceptually embodies a source of random numbers that allows you to ask for one. If MS wanted to ship a better implementation, they could do it because of this hiding. In some sense, it's the same reasoning as for the aggregate root idea; there are well-defined entry points that control the internals and keep everything consistent, as opposed to relying on client code all over the codebase to leave everything in a consistent state. | |
| Jul 1, 2021 at 3:16 | comment | added | Filip Milovanović | The recommendation does not come from DDD but from OO programming principles; it is not saying to replace property setters with setField() methods - that's still a setter (conceptually, in the language-independent sense). It's saying not to treat all objects as behaviorless data structures; getters and setters are a symptom of that. Instead, provide methods that represent some higher level operation, some domain concept; they would potentially take parameters, including other objects and/or functions, and change any state they own internally, never exposing it to callers directly. | |
| Jul 1, 2021 at 2:05 | review | First posts | |||
| Jul 1, 2021 at 12:01 | |||||
| Jul 1, 2021 at 1:58 | history | asked | underthevoid | CC BY-SA 4.0 |