Hacker News Reader

Comment by weavejester | Hacker News Reader

I think we're starting to see a shift away from the areas that OOP is traditionally comfortable with.

Increasingly, modern system design tends to place an emphasis on bare, immutable data, whereas OO tends to work with encapsulated, mutable state. If the only thing you're using objects for is namespacing and polymorphism, then there's not much point to designing software within the OO paradigm.

View on HN

I have noticed this too; all the "functional" languages I've seen (i.e. those with immutable data) encourage working with bare data. Is encapsulation only necessary for mutable data?

I think immutability removes one of the reasons for encapsulation: controlling state change. With that gone, the disadvantages of encapsulation might outweigh its advantages in a lot of cases.

Also note that many languages that encourage immutable data also have first-class functions with closures, which are also a very powerful tool for encapsulation and abstraction.

I think lambdas more than immutability help one write clean abstractions without traditional OO-objects. See the "Lambda the Ultimate" series of papers for details.

Encapsulation also helps enforce interfaces. Anything outside of an object should only interact with it via an external interface. This allows you to reason about the interaction of objects independently of the implementation of those objects. In theory, this allows you to change the implementation of an object without the interacting objects knowing, thus reducing the overall complexity of the program as well as potential bugs.

I had to google Polymorphism and Immutable objects.

Thanks for contributing to my knowledge!

Reply on news.ycombinator.com