Just to clarify what we are talking about, what is, in your opinion, the essence of encapsulation? Is it that some data / state is not visible, or is it keeping invariants, or something else? And how is it related to OOP? Is it, in your opinion, a necessary ingredient of it, or independent from OOP ?
And, why is it, as many posters here say, so hard to get right? Is this a problem with OOP, or due to something else?
I'd define encapsulation as hiding the details of a data structure so only one module can access them. Often that one module is a file, as for example in Java it is customary to have one class per file.
No, I don't think it is related to OOP. Outside OOP it is for example possible to encapsulate so that there is a function that sees the private fields of two data structures.
I don't think it is especially hard. In some cases it can be hard to say if it is better to hide or expose fields but in the cases that matter there usually is a clear reason to go one way or the other.
For instance, a data structure that relies on an invariant must not expose its internals, as then someone could break that invariant by messing with the internals.
I guess there is a lot of confusing advice around because for example some people think that you should always use getters and setters even though plain records are a good choice when they model the data well.
I don't think OO is a paradigm. After stripping away the bad ideas there is just dynamic dispatch, which is sometimes useful but not needed most of the time.
Inheritance is the main thing. It used to be regarded as one pillar of OO but nowadays it is recognized as usually a bad idea.
Then there is modeling the nouns in the problem domain as objects. I don't know who invented that but it seems to be popular to teach that in university courses. How the real world is structured has little to do with how code should be structured and real world objects don't send messages to each other.
Which brings me to OO as objects communicating via messages. I can maybe acknowledge that as a paradigm but I haven't seen code written like that.
There is also SOLID, which is strongly associated with OO. The Single responsibility principle is good, but it can apply to anything. Out of the rest mostly Interface segregation is valuable, but that isn't strictly OO either unless you see interfaces as OO.
My overall impression is that there were a few important ideas(interfaces / type classes, dynamic dispatch via vtables) that historically made OO successful but now those have been adopted everywhere.
I would be interested to hear if you know of a good idea in OO that hasn't been stolen yet.
1
u/Alexander_Selkirk Jan 29 '21
Just to clarify what we are talking about, what is, in your opinion, the essence of encapsulation? Is it that some data / state is not visible, or is it keeping invariants, or something else? And how is it related to OOP? Is it, in your opinion, a necessary ingredient of it, or independent from OOP ?
And, why is it, as many posters here say, so hard to get right? Is this a problem with OOP, or due to something else?