Timeline for Are init() methods a code smell?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 1, 2016 at 6:15 | vote | accept | Dioxin | ||
| Nov 1, 2016 at 0:02 | comment | added | Dioxin |
The real world is a different enviornment. Programs attempting to replicate it seem domain specific, as in you wouldn't/shouldn't account for it in most projects. Lots of things that are frowned upon are accepted when it comes to domain specific projects, so I'm trying to keep this as general as possible (such as how calling this in the constructor is a code smell and could result in error-prone code, and avoiding it is recommended regardless of what domain your project falls under).
|
|
| Oct 31, 2016 at 23:58 | comment | added | Dioxin | This is the best answer so far. One thing bugs me though: "Those states have different responsibilities, different methods that are allowed to be called, and different behavior" - Not separating these responsibilities violates SRP. If the purpose of the software was to replicate a real world scenario in every aspect, this would make sense. But in production, devs mostly write code that encourages easy manageability, revising the model if needed to better fit a software-based enviornment (continued on next comment) | |
| Oct 31, 2016 at 13:16 | comment | added | Ivan | Your suggestion to try the two-class model is good. Proposing a concrete step to address a code-smell is useful. | |
| Oct 31, 2016 at 13:05 | history | answered | Karl Bielefeldt | CC BY-SA 3.0 |