4 ms·

How 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 ago
encapsulation 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 ago
  Right, 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 ago
    Refactoring 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.
    - weavejester 13y ago
      > Refactoring is a fact of life. Refactoring is a symptom of screwing up the architecture of your application. Excessive refactoring is caused by excessively screwing up. I'd argue that if refactoring seems like a fact of life with OOP, that might indicate there's something very wrong with that paradigm. > Encapsulation makes it trivial to identify all places that need to be addressed. If encapsulation was all you needed, there wouldn't be so many refactoring tools for OOP languages that rename and move methods and classes around. > Talking about 'certain this' and 'possible that' is subjective. I'm not being subjective. In virtually every OOP application there will be an object that implements at least part of the functionality of a map. At the bare minimum, there will be at least one object that has a getter or a setter method. >If you value transparency then inheirit. Inheritance doesn't provide transparency in any meaningful way. The private members of the class are still private. The getters and setters are still opaque. >your 'data structure' is actually an object itself e.g. a hash map Data structures are only objects in object-orientated languages. In other systems, they're either primitives or constructed from primitives. At the lowest level, you can construct any data structure you like from an ordered array of bytes.
      - JoeAltmaier 13y ago
        Refactoring is a result of having time to optimize your product because its undergoing pressure you didn't (couldn't) predict. Its reimplementing something you did cheaply at first because performance wasn't as important as time-to-market. Its a fantasy that code can somehow be built to last forever.
        13y ago

JoeAltmaier 13y ago

encapsulation 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 ago
Right, 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 ago
  Refactoring 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.
  - weavejester 13y ago
    > Refactoring is a fact of life. Refactoring is a symptom of screwing up the architecture of your application. Excessive refactoring is caused by excessively screwing up. I'd argue that if refactoring seems like a fact of life with OOP, that might indicate there's something very wrong with that paradigm. > Encapsulation makes it trivial to identify all places that need to be addressed. If encapsulation was all you needed, there wouldn't be so many refactoring tools for OOP languages that rename and move methods and classes around. > Talking about 'certain this' and 'possible that' is subjective. I'm not being subjective. In virtually every OOP application there will be an object that implements at least part of the functionality of a map. At the bare minimum, there will be at least one object that has a getter or a setter method. >If you value transparency then inheirit. Inheritance doesn't provide transparency in any meaningful way. The private members of the class are still private. The getters and setters are still opaque. >your 'data structure' is actually an object itself e.g. a hash map Data structures are only objects in object-orientated languages. In other systems, they're either primitives or constructed from primitives. At the lowest level, you can construct any data structure you like from an ordered array of bytes.
    - JoeAltmaier 13y ago
      Refactoring is a result of having time to optimize your product because its undergoing pressure you didn't (couldn't) predict. Its reimplementing something you did cheaply at first because performance wasn't as important as time-to-market. Its a fantasy that code can somehow be built to last forever.
      - 13y ago