Timeline for Encapsulation dilemma: should age operations depend on external dates outside the object?
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 6, 2022 at 6:21 | comment | added | Doc Brown | ... that's the one-and-only place to change. The real question one has to ask here: who maintains User, and who maintains changes to the definition of a current date? When both happens in the same team, my suggestion is fine. When it might happen in different team, it is better not to provide hasCurrentlyMinimumLegalAge in the User class. | |
| Apr 6, 2022 at 6:16 | comment | added | Doc Brown | @DanielSchilling: such decisions depend on the context. If class User is part of a highly reusable framework provided by some vendor X, and used by a client Y, it is surely better to stick to the SRP "by the book". If it is exclusively used in a context where it can be changed by the team which uses it, pragmatic solutions are perfectly fine and can actually prevent overdesign. Moreover, your example is flawed: the member hasCurrentlyMinimumLegalAge() provides a single place where GetCurrentDate is called, so when the definition of a "current date" changes, ... | |
| Apr 5, 2022 at 20:35 | comment | added | Daniel Schilling | ... hard-coded GetCurrentDate one will be broken in those scenarios. So everything could be fine for a while, until the day when you need to change what "current date" means, and then you have to go through all the places in code that use hasCurrentlyMinimumLegalAge() and fix them. It would be better to leave it out from the start. | |
| Apr 5, 2022 at 20:32 | comment | added | Daniel Schilling | This violates the Single Responsibility Principle. The class now has multiple reasons why it may need to change: if the age validation requirements change, or if the definition of "current date" changes. It may seem like that is something that would never change, but as others have pointed out, you may need to change the date to validate future date requirements, or for the purposes of tests where you'd rather not have to wait a few years to see if the code works. :) Yes, providing the method overload that accepts a date parameter allows these scenarios to work, but any code that uses the... | |
| Apr 5, 2022 at 16:50 | comment | added | candied_orange | This follows the functional core pattern. You'll want to be sure dates type is stable. That's been somewhat iffy with the built in dates in some languages. | |
| Apr 5, 2022 at 16:38 | comment | added | Doc Brown | @DrakeP: that's surely possible in many languages. If it is better is debatable, since it will be less expressive. I think it is more a matter of taste. | |
| Apr 5, 2022 at 16:33 | comment | added | Kroltan | If your language supports those, then sure! | |
| Apr 5, 2022 at 15:20 | comment | added | Drake P | Would it not be better to have a default value for currentDate so both options can be covered by one function? | |
| Apr 5, 2022 at 12:24 | history | edited | Doc Brown | CC BY-SA 4.0 | deleted 14 characters in body |
| Apr 5, 2022 at 10:33 | history | edited | Doc Brown | CC BY-SA 4.0 | added 261 characters in body |
| Apr 5, 2022 at 9:41 | history | edited | Doc Brown | CC BY-SA 4.0 | added 1 character in body |
| Apr 5, 2022 at 8:01 | history | edited | Doc Brown | CC BY-SA 4.0 | added 122 characters in body |
| Apr 5, 2022 at 7:35 | history | answered | Doc Brown | CC BY-SA 4.0 |