3 ms·

> Use objects to encapsulate functionality Sadly objects are also used in an attempt to hide data (because direct access to data is considered dirty in OOP).

> Use objects to encapsulate functionality Sadly objects are also used in an attempt to hide data (because direct access to data is considered dirty in OOP). Now, consider a non-trivial OOP class hierarchy. You have an object that needs to mutate another object's data (an object that is completely unrelated to your initial object). In order to solve this you have options: - completely rearchitect your code so that you take this use case into account - find the shortest path between these two classes and add setters to each class - hack the code and call it "technical debt" First one is not feasible, second one is unmanageable (complexity increases dramatically), third one is usually chosen. Speaking from experience, OOP is most of the time the worst tool for the job.

JoeAltmaier 6y ago
OR, don't use a 'setter', use a carefully named API that describes the purpose instead. Or design the two classes to share the data with locks. Or whatever your solution requires. Yes breaking encapsulation willy-nilly is a bad thing. So don't. I don't doubt there are bad programmers out there. Blaming the hammer for a bad carpenter is foolishness. Btw objects are used for like 5 different things. Choose what works for your problem space.
- Tomis02 6y ago
  > don't use a 'setter', use a carefully named API that describes the purpose instead. Call it whatever you want, the requirement is for one class to produce a side effect in a completely unrelated part of the code (happens all the time). This doesn't fit with the current architecture, and there was no way of predicting it beforehand. Now what? Rewrite everything? What happens if you're in a department of 30 developers? Tell them "hold on while I go back to the drawing board to create a clean design"? OOP isn't a hammer, it's duct tape, and carpenters are taught from school that duct tape is the main way of doing carpentry. It's duct tape because it ties data to functions in a way that makes it very difficult to extract or reuse that data somewhere else. When OOP is your religion you don't blame the bad carpenters, you blame the master priest.

JoeAltmaier 6y ago

OR, don't use a 'setter', use a carefully named API that describes the purpose instead. Or design the two classes to share the data with locks. Or whatever your solution requires. Yes breaking encapsulation willy-nilly is a bad thing. So don't. I don't doubt there are bad programmers out there. Blaming the hammer for a bad carpenter is foolishness. Btw objects are used for like 5 different things. Choose what works for your problem space.

Tomis02 6y ago
> don't use a 'setter', use a carefully named API that describes the purpose instead. Call it whatever you want, the requirement is for one class to produce a side effect in a completely unrelated part of the code (happens all the time). This doesn't fit with the current architecture, and there was no way of predicting it beforehand. Now what? Rewrite everything? What happens if you're in a department of 30 developers? Tell them "hold on while I go back to the drawing board to create a clean design"? OOP isn't a hammer, it's duct tape, and carpenters are taught from school that duct tape is the main way of doing carpentry. It's duct tape because it ties data to functions in a way that makes it very difficult to extract or reuse that data somewhere else. When OOP is your religion you don't blame the bad carpenters, you blame the master priest.