Timeline for Unit testing protected methods which have no reason to be public
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 9, 2018 at 16:27 | comment | added | candied_orange | I can solve any computing problem with only one class. I also refuse to maintain systems that use only one class. :P | |
| Dec 9, 2018 at 16:03 | vote | accept | Steve Chamaillard | ||
| Dec 9, 2018 at 15:57 | comment | added | Erik Eidt | So, I disagree that sheer class count represents increased complexity over inheritance (which has its own class count). The complexity introduced by conflating domain entities and their lifetimes, by inheritance and overrides, is higher in my book than having numerous simple(r) classes connected by composition & delegation. A simpler design, even with more classes, is less complex. | |
| Dec 9, 2018 at 15:54 | comment | added | Erik Eidt | We need as many classes as we have independent concepts in the domain -- that is not artificial complexity, it is real world complexity -- the domain is rich. | |
| Dec 9, 2018 at 15:48 | comment | added | Steve Chamaillard | So I tried using a composition design, which leads to a significant increase in number of classes. Instead of having 3 different implementations extending the base abstract class, I now have 2 validating classes, 3 offered cash calculating classes, 2 classes to offer credits, 3 email sending classes, and 1 sponsorship repository to update the model. Doesn't it seem like a lot ? Although I understand it's a lot more flexible, is the complexity worth it ? Could it be that I'm having trouble finding the correct abstractions to use composition with less classes created ? | |
| Dec 9, 2018 at 15:25 | history | answered | Erik Eidt | CC BY-SA 4.0 |