Timeline for Does this class design violate the single responsibility principle?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 24, 2016 at 12:01 | comment | added | tobiak777 | I'm not saying it is. For writing a compiler it probably isn't, but for most of the line of business / SaaS applications, I think it is much less art/science than what you suggest. The need for domain model can be proven mathematically, your examples make me think of debatable designs rather than flaws of limitations in OOP | |
| Jan 14, 2016 at 10:07 | comment | added | Vince | I don't think I have a misconception of rich domain OOP, I've designed a lot of sotwares that way, and it is true it is really good for maintenance / evolution. But I'm sorry to tell you this is not a silver bullet. | |
| Jan 14, 2016 at 0:26 | comment | added | tobiak777 | Thanks for your input Vince. The point is, you don't need a service layer when you have a rich domain. There's only one class responsible for the behaviour, and it is your domain entity. The other layers (web layer, UI etc...) typically deal with DTOs, and ViewModels and this is fine. The domain model is to model the domain, not to do UI works, or send messages across the internet. Your message reflects this common misconception, which comes from the fact that people simply do not know how to fit OOP into their design. And I think this is very sad - for them. | |
| Jan 13, 2016 at 22:38 | review | First posts | |||
| Jan 14, 2016 at 19:48 | |||||
| Jan 13, 2016 at 22:35 | history | answered | Vince | CC BY-SA 3.0 |