Timeline for How do I make a domain model that doesn't violate OOP?
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 16, 2014 at 6:51 | comment | added | jmoreno | @davidkennedy85: which part? Private to avoid invalid state? If they want to create an invalid state, they probably can. Reducing system complexity is generally beneficial, but not a goal in and of itself. | |
| Feb 16, 2014 at 2:43 | history | edited | FastAl | CC BY-SA 3.0 | added 1718 characters in body |
| Feb 15, 2014 at 18:16 | comment | added | Big McLargeHuge | While the Wikipedia article mentions both uses for encapsulation, the rest of the article is entirely about the first. I've always found the primary benefit from encapsulation in this paragraph: Hiding the internals of the object protects its integrity by preventing users from setting the internal data of the component into an invalid or inconsistent state. A benefit of encapsulation is that it can reduce system complexity, and thus increases robustness, by allowing the developer to limit the inter-dependencies between software components. How do you reconcile this to your answer? | |
| Feb 15, 2014 at 17:51 | history | answered | FastAl | CC BY-SA 3.0 |