2 ms·
That's the point I'm trying to explain in the article. The idea of an "object" in OOP is to be a self-sufficient entity, capable of doing ALL operations interna
by yegor256a 11y ago
That's the point I'm trying to explain in the article. The idea of an "object" in OOP is to be a self-sufficient entity, capable of doing ALL operations internally. When I'm doing dao.insert(bean) - I let some DAO to extract my data and use them somehow. It's a violation of the basic principle of OOP - encapsulation.
- unclebucknasty 11y agoUnderstood. I agree that some popular ORM tools are a mess and generally fail in delivering on what they "promise". I also agree that having some objects speak SQL is a cleaner alternative (whether using a bridge as in your article, or otherwise). However, I don't agree that OOP requires that every object encapsulate ALL operations. Specifically, I don't think embedding SQL operations directly in these objects is optimal, as it too tightly couples the object with the underlying persistence mechanism. And, it puts too much responsibility on the class. Following your approach of doing ALL operations internally for the sake of encapsulation, it seems that you'd also have the object be responsible for, say, rendering itself in the view and a whole host of other responsibilities which could result in huge, monolithic objects that are difficult to maintain.