4 ms·
No, the biggest benefit is first-class modules. This is a feature that for example FP languages have struggled to incorporate. "Encapsulation" with OOP is a bit
by willtim 6y ago
No, the biggest benefit is first-class modules. This is a feature that for example FP languages have struggled to incorporate. "Encapsulation" with OOP is a bit of a misnomer, as state is not encapsulated, it is just hidden. Such hidden state then interferes with composition. With true state encapsulation, a function can use mutation on the inside, but appear pure on the outside.
- nomel 6y agoI'm interested in this, since I thought the concept of encapsulation is maintaining, and hiding, state inside of an object. What's the difference between mutating state on the inside and hiding state on the inside? Aren't they practically the same?
- willtim 6y ago> What's the difference between mutating state on the inside and hiding state on the inside? Aren't they practically the same? You can mutate state on the inside, but still provide a "pure" mathematical function on the outside. For example, a root finding solver. The general problem/feature with objects, is that when a method returns, the object may be in a different state (and often is). Such state changes are hidden but not "encapsulated" as they still contribute to the global state of your application. In other words, the global variables are still there, you've just organised them into modules.
- sedatk 6y agoI don't understand your reasoning. What does prevent you from having hidden state within a first-class module? It's simply encapsulation at module level.
- willtim 6y agoObjects don't have to have mutable state. And even if they do, it can be unobservable. This is true "state encapsulation" but the OOP definition of encapsulation does not require this. Such objects are still very useful as "first-class modules", i.e. modules that can be passed around and switched at runtime.