+ 5
What is Object oriented
[Update from David Carroll] Melekte Petros I removed the mfd from this thread since the discussion here has explored a much deeper review into encapsulation not found in the other posts.
19 Respostas
+ 8
Ore For clarification... are the two conditions for encapsulation you listed paraphrased in your own wording or are you pulling these from a source? If you're pulling these from a source, do you mind sharing something I can reference.
I only request this because the wording can be tricky here as these seem to conflate with other meanings and less with encapsulation in OOP as I understand it.
On one hand, both seem to describe modularity in general. On the other hand, #2 seems to describe abstraction.
Before moving forward, it might help if we tried to establish wording we can both agree to in terms of encapsulation.
If I was to try to rephrase the conditions you listed to align with what I think you are saying, it might go something like:
1. Bundling data with related behaviors.
2. Preserving the integrity of mutable data.
Information (or data) hiding is a mechanism used for satisfying condition #2.
Let me know if these are good to work with or if we need to refine further. š
+ 7
Jan Markus What you have described is encapsulation, an important concept of modularity. Encapsulation can be achieved without objects as in C or Go.
In my opinion, the distinctive features of OOP are inheritance and polymorphism. Without support for inheritance and polymorphism, it is not possible to design an object oriented system.
Yet while encapsulation may not be required for object oriented programming (e.g JavaScript) it definitely makes OOP better.
+ 7
[Response B: Part 1 of 3]
Cool... these definitions work for me.
With this in mind, I would like to clarify my earlier phrasing, which I believe will be helpful for this discussion.
In short, that phrasing aligns with an assertion by David West in his book, Object Thinking, that states "encapsulation is a discipline more than a real barrier... so it is up to the user of an object to respect that object's encapsulation."
He goes on to assert that there is _no_ real encapsulation in any absolute sense - which is something I completely agree with.
- See Page 22: http://davewest.us/wp-content/uploads/2016/10/otChap5.pdf
While this isn't explicitly stated in any concise definitions that I'm aware of, it does seem to be reflected in the undercurrent of most references I've reviewed as of late.
+ 7
[Response B: Part 2 of 3]
Otherwise, encapsulation wouldn't only be unachievable in some languages, but across all languages. In this context, it stands to reason that encapsulation is less about hiding data per se and more about hiding data to prevent uncontrolled data changes and corrupting data integrity.
Moreover, language features such as access modifiers, getters / setters, auto properties, name mangling, closures, etc are simply language implementation details. While some may provide tighter protection via runtime boundaries and others through implied boundaries, these do all qualify as encapsulation. That said, I'm quite vocal in my criticisms of using name mangling for implementing implied private properties in Python. But, that doesn't necessarily lesson the fact that it is encapsulation nonetheless.
+ 7
[Response B: Part 3 of 3]
[Closing Thoughts]
So now, let's return back to the main point of contention as to whether or not, "encapsulation is not always achievable or even required in OOP."
I wonder if your position about encapsulation was based on the absolute sense of information hiding.
If so, perhaps the context I've provided presents an opportunity to reconsider your position.
+ 6
Melekte Petros I removed the mfd from this thread since the discussion here has explored a much deeper review into encapsulation not found in the other posts.
+ 5
[Part 1 of 2 to Ore]
While the concept of encapsulation may not be exclusive to OOP, it is absolutely fundamental and required for OOP. To suggest otherwise is a bit nonsensical. That is to say, it's unclear what the purpose would be for any object that doesn't bundle related data with corresponding behaviors while ensuring the integrity of mutable data.
Although inheritance and polymorphism are certainly fundamental concepts in OOP, neither would serve any meaningful purpose without encapsulation (or its corresponding counterpart - abstraction). After all, it's the encapsulated behaviors and interface abstractions that are being inherited, overridden, overloaded, or extended. Also, while class inheritance might be unique to OOP (AFAIK), composition is a common alternative for achieving the same polymorphic behavior and code reuse.
+ 5
[Part 2 of 2 to Ore]
Similar to encapsulation and abstraction, the concept of polymorphism isn't exclusive or unique to OOP. However, these three + inheritance (or composition) are collectively essential for OOP.
NOTE: It's possible I misunderstood your earlier response and have responded out of context. If so... my bad. š Otherwise, I hope these clarifications are helpful.
Oh... and as a side note... it wasn't clear to me what you meant by the following:
"Yet while encapsulation may not be required for object oriented programming (e.g JavaScript) it definitely makes OOP better."
Are you saying that Javascript doesn't require encapsulation or that it doesn't support it or something else?
+ 4
Melekte Petros, Jan Markus have given you an answer.
Again, please use the search bar, this is a duplicate question that asked zillion times.
I provided a lot of threads for you.
(The search bar will prosper)
https://www.sololearn.com/discuss/1796955/?ref=app
https://www.sololearn.com/discuss/1681464/?ref=app
https://www.sololearn.com/discuss/452261/?ref=app
https://www.sololearn.com/discuss/263106/?ref=app
https://www.sololearn.com/discuss/1027016/?ref=app
https://www.sololearn.com/discuss/1819378/?ref=app
https://www.sololearn.com/discuss/2433775/?ref=app
https://www.sololearn.com/discuss/1335870/?ref=app
https://www.sololearn.com/discuss/1573685/?ref=app
https://www.sololearn.com/discuss/93004/?ref=app
https://www.sololearn.com/discuss/1459515/?ref=app
https://www.sololearn.com/discuss/2079184/?ref=app
https://www.sololearn.com/discuss/341206/?ref=app
https://www.sololearn.com/discuss/2083784/?ref=app
https://www.sololearn.com/discuss/2367422/?ref=app
+ 4
Melekte Petros If you haven't yet started reading about OOP, I recommend you spend some time reading various articles online about OOP until you have some base knowledge to work with. At that point, try to focus on specific concepts you might be struggling with until you reach a point where you are still unclear about something. Try to craft a clear and focused question and search Google, then SoloLearn for answers. If you can't find your answer, then post that clear and focused question here.
Trust me... you'll learn a lot through out this process along the way.
I recommend the following link as a starting point.
https://en.m.wikipedia.org/wiki/Object-oriented_programming
Try to review it a few times to get a sense of the related concepts. Follow the links like breadcrumbs for related information.
That said, since this question is a common duplicate, it has been marked for deletion and will be automatically removed in 24 hours.
In the meantime, best of luck with your coding journey. š
+ 4
David Carroll That makes a lot of sense. Now that I think of it, OOP would bring forth no benefit without encapsulation even if it is not perfect.
But I agree with Kode Krasher, I think perfect information hiding is achievable in languages that support lexical closures. I am stating this because you said:
āthere is _no_ real encapsulation in any absolute sense - which is something I completely agree with.ā
As far as I know, it is not possible to "insert wires" into the implementation of a closure.
+ 3
David Carroll Your rephrasing seems better. "Preserving the integrity of mutable data" is quite confusing. I prefer to use Wikipedia's definition.
encapsulationĀ refers to the bundling of data with the methods that operate on that data, or the restricting of direct access to some of an object's components.
https://en.m.wikipedia.org/wiki/Encapsulation_(computer_programming)
It is slightly the same as my initial points:
1. Bundling of data with the methods that operate on that data.
2. Restricting of direct access to some of an object's components.
+ 3
I still do not consider name mangling to be a form of information hiding. Name mangling is not a language implementation but simply a convention.
Assume that I live in a unsafe neighbourhood and I wish to protect my car from roadside bandits. If I simply place a sign post that says "Do not touch" while my car is parked on the roadside, will that be considered a form of protection? Perhaps it will, but it is a very weak protection. It will be sane for me to prevent easy access to what I wish to protect.
Encapsulation seeks to enforce discipline or control over a program. It should not be reduced to mere conventions. Information hiding is important for encapsulation, just as immutable data structures are important for functional programming.
Python supports OOP, no doubt. Python allows for grouping behaviours with their related data, polymorphism etc. However, Python does not support information hiding (access restrictions on the implementation of a module or class).
+ 2
David Carroll Encapsulation has 2 definitions. If a system uses encapsulation, two things should be true:
#1. The system is separated into smaller components based on the data they operate on.
#2. Each component's implementation is abstracted completely behind an API.
Any OO system likely obeys #1 but many OO languages (e.g Python) do not allow for #2 (information hiding)
Therefore encapsulation is not always achievable or even required in OOP.
+ 2
Ah great conversation. It digs deeper through the discussion and somehow, I believe, appears in Hot Today.
+ 2
Kode Krasher I doubt that. I have heard the saying "We are all consenting adults" used often in the Python community.
What that saying means is that Python is built on the idea that developers using the language are all competent not to abuse the lack of restrictions.
+ 1
Kode Krasher It is so sad considering the massive influx of wannabe coders to the language.
BTW, I think we are moving off-topic already. This thread is supposed to be about OOP.