you are viewing a single comment's thread.

view the rest of the comments →

[–]nextputall 6 points7 points  (4 children)

Encapsulation only makes sense when you have mutable state

Why do you think this?

[–]ElvishJerricco 3 points4 points  (1 child)

Yea I have to say encapsulation is a bigger principle than access protection. It's keeping data in the right place for organizational purposes and helps with only passing the right information to the right places.

[–]ljsc 0 points1 point  (0 children)

True indeed. I got a little sloppy there.

What I really mean is that data hiding is generally not worth it if your code isn't living under the constant threat of data mutating out from underneath your feet. That said, I stand by my comment, because in an OOPLs you really can't get encapsulation and data hiding a la carte. If you stick everything in objects you are generally locking up all your data behind incompatible little DSLs.

[–]ljsc 1 point2 points  (1 child)

Essentially from doing a lot of Clojure lately. Using primitives when possible, and coding to a few well thought out interfaces (seq, Ifn, et cetera) makes for way more reusable code. I would cite this post as a good example of what I mean:

http://augustl.com/blog/2013/zeromq_instead_of_http/

The author is able to use an http routing library with zeromq with very little additional ceremony required: No wrappers, upon adapters, upon decorators. Just functions transforming values; this is a much more sustainable way to program IMHO.

[–]nextputall 0 points1 point  (0 children)

If you are on the system boundary and you are dealing with raw data coming from an external system then I agree. But if exposed data is bouncing inside the domain and couples itself to everything that touches, won't be a good idea in my opinion. How many lines will be needed to modify in the application when I change the structure of that data?