4 ms·
That's just polymorphism. You don't need to encapsulate the connection data, you don't need to cache implicitly (what's wrong with an explicit memoize?), and in
by weavejester 13y ago
That's just polymorphism. You don't need to encapsulate the connection data, you don't need to cache implicitly (what's wrong with an explicit memoize?), and inheritance isn't necessary for sharing implementation details.
To be more specific in my criticisms, it's not that polymorphism or event inheritance aren't useful tools. It's more that OOP inextricably ties these concepts together, making it hard to reason about them separately.
Your comment demonstrates this, I think. All the functionality you describe would be implemented in a functional language with polymorphism and higher-order functions, but because an OOP language binds these concepts so tightly together, it's hard to distinguish between them when thinking about a OO design.
- michaelt 13y agoIf not for encapsulation, how do you denote those parts of the interface which you commit to keeping stable and those parts of the interface that are for internal use only?
- weavejester 13y agoMarking some functions as suitable for internal use is fine. That's not something that's generally considered as falling under the definition of encapsulation. Encapsulation is a mechanism to hide information, to conceal internal state or values. I'd argue that this an anti-pattern. Hiding data is almost always the wrong thing to do.
- sklivvz1971 13y agoEncapsulation is advisable because it allows controlling the scope of variables. It's not the wrong thing to do when you keep state. It's the right thing to do.
- weavejester 13y agoHow does encapsulation have anything to do with scope? And why is hiding state the right thing to do? What benefit does it have?
- JoeAltmaier 13y agoencapsulation allows changing the internal representation without having to revisit every use case external to the class. Typically that means adding new states, or changing between a collection of Booleans to/from a state machine.
- weavejester 13y agoRight, but consider it in terms of what you gain, and what you lose. In terms of what you gain, encapsulation might save time, as in some circumstances you can keep the same API without changing the underlying representation of data. But the price you pay is that you need to reimplement some subset of the functionality a data structure already has, every time you write a new class. You might need to write accessors, iteration, transversal, searches, serialisation, merging, and a whole bunch of other things you get for free with a data structure. Encapsulation means continually re-implementing the wheel, which takes time. Another huge problem with encapsulation is that you lose transparency and constraints. If I have a system represented fully or in part by a data structure, it gives me visibility and certain guarantees. For example, if I set a key in a map to a value, I know that when I read that key I'll get the same value out. You have no such guarantees with objects. Encapsulation trades possible gains for certain losses. This might be acceptable, if you had some reason to believe you stood to gain a lot more than you'd lose. But there's no empirical evidence to suggest that there are any significant gains in practice from encapsulation. However you look at it, it seems a really bad trade. Purely anecdotally, my own experience is that idiomatic OOP design requires an order of magnitude more refactoring than data-driven design.
- JoeAltmaier 13y agoRefactoring is a fact of life. Encapsulation makes it trivial to identify all places that need to be addressed. That is a certain gain. Talking about 'certain this' and 'possible that' is subjective. I'd have labeled those the opposite way, for instance. If you value transparency (your 'data structure' is actually an object itself e.g. a hash map) then inheirit. Its not rocket science. One solution doesn't have to fit everything.