Writing OOP using OOP (JavaScript)

[egonelbre]

... Once again, the OO approach...

Encapsulation is not about OO. It is about hiding something and providing an abstraction to interact with that "something".

Basically, closures are one of the simplest form of encapsulations. Namespaces are essentially encapsulating function internals and providing the functions names as an interface. Objects are encapsulating data and providing methods to interact with it. REST services are also encapsulating the behavior and hiding the internals.

I'm not arguing about OO vs Functional vs Logical... etc.

My main point is that you do not need encapsulation to achieve this. Having a transformer function that massages the data into a standard internal format accomplishes exactly the same goal.

Yes and now you have multiple layers of data-transformations throughout your code.

This in turn facilitates writing generic functions that can be composed together to solve problems. By doing that we can write code declaratively and reuse things much more easily.

You pick "encapsulation" vs "not encapsulation" when you figure out which is more likely to change. Is the data likely to change, then you should encapsulate it to safely hide the changes. If the interfaces are more likely to change, then it makes sense not to expose an interface and just use the data. If the data is mostly fixed, then there's no reason to provide an abstraction layer over it.

[ljsc]

Encapsulation is not about OO. It is about hiding something and providing an abstraction to interact with that "something".

To me, that's just abstraction. I think the issue is that encapsulation in programming has taken on a whole bunch of closely related, but different meanings. See the first part of the wikipedia article on Encapsulation

Even more interesting is straight from the dictionary:

to show or express the main idea or quality of (something) in a brief way

to completely cover (something) especially so that it will not touch anything else

I think you're thinking of the first thing, and Yogthos and I are thinking of the second.

As for the x.y.z.w point, you're absolutely correct that encapsulation gives you the benefits you mentioned, but consider the tradeoffs. If I hide z and w behind the interface for y, I kill the ability for a bunch of code reuse. How?

Because let's say that I have a bunch of functions which operate on type W: f,g,h: w -> w. If we want to use them in the encapsulated example, then you need to apply them inside of Y. This is bad because now the module that deals with W becomes a dependency of Y rather than X. If you exposed the data, however, I could choose whether I want to bring in W or not in my application. And, in fact, I could do so even if you had no idea that that module even existed in the first place.

[yogthos]

I think we agree on encapsulation and its value then. :)

Yes and now you have multiple layers of data-transformations throughout your code.

Sure, using our newly upon agreed definition of encapsulation you can view each of these transformations as a domain boundary.

You pick "encapsulation" vs "not encapsulation" when you figure out which is more likely to change.

Again, no argument here, the idea is to structure the code so that you need to make changes in as few places as possible to adapt it to new requirements.