4 ms·

I personally think "encapsulation" as us used in OOP, is a misnomer. State is usually not encapsulated, it is just hidden. Proper state encapsulation would be t

I personally think "encapsulation" as us used in OOP, is a misnomer. State is usually not encapsulated, it is just hidden. Proper state encapsulation would be to use mutable state internally for efficiency, but for that state to be unobservable externally. OOP does unfortunately encourage introducing mutable state into the domain model. The canonical example being the back account, with a mutable back balance! The good parts of OOP are interfaces and first-class modules. Obviously we should try and keep those.

dvt 5y ago
> Proper state encapsulation would be to use mutable state internally for efficiency, but for that state to be unobservable externally. This is literally how private/public keywords work, so I think your criticism is unfounded. However, I do agree with the overall sentiment that OOP implementations tend to "leak" way too much state than they need to.
- grumpyprole 5y ago
  I think you misunderstood my point. Private may protect direct access to mutable state, but the object may still have mutable state that is observable externally and must be reasoned about. In which case, the mutable state is not truly encapsulated.
  - kaba0 5y ago
    That is not hidden by immutable data either - the state is just global in the latter case, in a way. There is no getting away from essential state, from a theoretical point of view. In my opinion the often leaky partial encapsulation of state is still one of the better ways to deal with it. And immutability is another axis so of course the frequent case where it makes sense should be adhered to, but not religiously.
    - grumpyprole 5y ago
      It is much easier to reason about immutable state than mutable state, both for humans and compilers, especially in a distributed setting (any modern piece of hardware). The problem with "leaky" encapsulation as you put it, is the combinational explosion of the state space as many stateful objects are composed. Most mainatream programming languages are still unfortunately not well geared up for working with immutable data, they lack even persistent collections. Functional languages are of course ideal for this.
      - kaba0 5y ago
        > The problem with "leaky" encapsulation as you put it, is the combinational explosion of the state space as many stateful objects are composed. I don’t think it has to be necessarily more than with an immutable approach. Like, there is an essential amount of state you will have to have either case and it is not clear to me that immutability is always the better choice. But don’t get me wrong, I also default to immutable data structures, I’m just saying that 1) OOP is not incompatible with FP 2) not every problem is solved better with FP-idioms. It’s not accidental that haskell has state monads as well.
  - dvt 5y ago
    Ah, I see what you mean, though I do think that immutability purists like yourself have their own monsters to contend with (even apart from the obvious performance hit).
    - grumpyprole 5y ago
      Absolutely we do! For example, garbage collectors are complex beasts that are hard to tune and tough to scale. But of course some OOP languages have started using GC anyway, in which case, I honestly believe they might as well be functional programmers :)

dvt 5y ago

> Proper state encapsulation would be to use mutable state internally for efficiency, but for that state to be unobservable externally. This is literally how private/public keywords work, so I think your criticism is unfounded. However, I do agree with the overall sentiment that OOP implementations tend to "leak" way too much state than they need to.

grumpyprole 5y ago
I think you misunderstood my point. Private may protect direct access to mutable state, but the object may still have mutable state that is observable externally and must be reasoned about. In which case, the mutable state is not truly encapsulated.
- kaba0 5y ago
  That is not hidden by immutable data either - the state is just global in the latter case, in a way. There is no getting away from essential state, from a theoretical point of view. In my opinion the often leaky partial encapsulation of state is still one of the better ways to deal with it. And immutability is another axis so of course the frequent case where it makes sense should be adhered to, but not religiously.
  - grumpyprole 5y ago
    It is much easier to reason about immutable state than mutable state, both for humans and compilers, especially in a distributed setting (any modern piece of hardware). The problem with "leaky" encapsulation as you put it, is the combinational explosion of the state space as many stateful objects are composed. Most mainatream programming languages are still unfortunately not well geared up for working with immutable data, they lack even persistent collections. Functional languages are of course ideal for this.
    - kaba0 5y ago
      > The problem with "leaky" encapsulation as you put it, is the combinational explosion of the state space as many stateful objects are composed. I don’t think it has to be necessarily more than with an immutable approach. Like, there is an essential amount of state you will have to have either case and it is not clear to me that immutability is always the better choice. But don’t get me wrong, I also default to immutable data structures, I’m just saying that 1) OOP is not incompatible with FP 2) not every problem is solved better with FP-idioms. It’s not accidental that haskell has state monads as well.
- dvt 5y ago
  Ah, I see what you mean, though I do think that immutability purists like yourself have their own monsters to contend with (even apart from the obvious performance hit).
  - grumpyprole 5y ago
    Absolutely we do! For example, garbage collectors are complex beasts that are hard to tune and tough to scale. But of course some OOP languages have started using GC anyway, in which case, I honestly believe they might as well be functional programmers :)