The idea behind OO is to move away from data-centric programming. If I have a system dealing with geometry, I can have a Point object that has an x and y coordinate. However, once I have a Point, I should be trying to make my system so that I no longer access x and y directly. X and y are "encapsulated" in the Point. Collaborators should use the functionality on Point to do what they need to do, rather than trying to pry Point apart and get at the data.
Of course, barely anybody writes "OO" code like that, even if they espouse to follow "encapsulation".
I would argue as well that generic functions do not, in themselves offer an OOP environment. You need one more thing: partially applied functions. If you can create a partially applied function, you can bake in some program state and pass it around, offering functionality on that program state. However, nobody on the outside can access that state. This is the encapsulation necessary for OO.
In general, I don't see the need for encapsulation in order to qualify for object status. The classic counterexample is CLOS, which doesn't have it -- and the debate over that has been raging for decades [1].
[1]: http://wiki.c2.com/?HowObjectOrientedIsClos
The best basis for the essence of object-orientedness that I ever read was suggested in an article that focused on identity. (I don't remember where I saw this -- possibly from Kent Pitman?) If you could guarantee that some value is exactly the same as a value that you had earlier, and not just a mostly-copy but identical in every respect, then you had an object. Everything else falls out of that.
I do agree, though, nobody actually writes code like that. Does that mean that I think nobody actually does OO? I hadn't actually thought it through that far :-) I think this is why the concept is so vague (your excellent example being a great indicator of that). C++ is often referred to as "C with Objects" and I sometimes think we've gone so far as to say anything with a function that operates on a structure is "Object Oriented". If so, I think we've lost our path a little bit.
Arguably this is still within purview of "Point" abstraction, but:
> If you want to align a group of points on the X access, you can write a method on point to do it.
This calls for a static method really, otherwise the abstraction becomes subtly wrong. And with static methods you quickly realize that you're using the containing class as just a namespace.
CLOS actually resolves this nicely by having methods being their own things separate from classes. As a related side effect, the typical C++/Java case of "object methods" isn't a special thing in CLOS, it's just a method that happens to be polymorphic only on its first argument. The abstraction around methods seems cleaner, and the class in CLOS is just responsible for encapsulation and inheritance, not for namespacing methods.
Point {x, y} may not be the best example, but you can certainly see how this can be beneficial should X or Y become something even slightly more complex. And this is the purpose of encapsulation - to make a system easier to understand and therefore easier to change.
I kind of agree that encapsulation isn't needed for object status. The caveat only being that it would be a weird object system where you could be sure there was no encapsulation.
I mean, OK, in some languages you know that. But does it change anything important?
Information hiding is an important concept in low-level-ish systems programming languages in which p.x implies a piece of machine code that offsets 24 bytes from the base address of p, and fetches a four byte integer.
The intended purpose of encapsulation is to try and preserve integrity of a system by restricting the ways a programmer might put it into an inconsistent state. Knowing that certain constraints are in place simplifies the problem of understanding and debugging a system.
There's no point in putting a "private/public/protected" security model in a programming language. It isn't a security boundary.
This vastly simplified the design of OO in Python, and it makes testing far far easier. There's no need to go through the dependency injection acrobatics in order to change one method for testing or proxying.
(There technically is a way to munge a property name in Python but its use is discouraged).
It’s about intention. If I mark a property or method as private, it means that I can get rid of it, rename it or change the expected behavior without considering it a breaking chance.
With a statically typed language, you really have to go out of your way to do it like using reflection and if your code breaks on an update you get what you deserve.
Do you realize how many hacks is built into Windows just because developers were using undocumented features?
Do you have a reference for that (i.e. the discouraged part)?
- combination of methods and data
- information hiding
Information hiding is needed for OOP, but it can be hidden in the implementation. The fact that if I have a point object, I can access point.x is not an example of information hiding being violated. Firstly, it doesn't interfere with polymorphism: the same point.x code can access the x coordinate of points of different types. Secondly, the syntax point.x can actually be a method call which invokes an accessor under the hood, so the object doesn't actually have to have a slot x. There is no semantics or "moral" difference between having a pair of methods point.getx() and point.setx(<number>), and just a point.x. Lastly, sometimes it is perfectly acceptable in an object design to have trivial properties.
Information hiding is more important in languages like C++ because an access like "point.x" compiles to code which assumes that x is at a particular offset in that object, and is of a particular type and so forth. It's less important in a dynamic language in which we can cafely ask for the x slot of any object.
Encapsulation of methods and data isn't required in an OOP system; OOP systems like CLOS work without it just fine.
To me this is the most important part. I like to have private or public, protected is not needed.
I agree that code representation should be kept separate.
OO's encapsulation is about bundling data and operation, not about information hiding, and as kazinator noted generic functions (as in CLOS) prove you can have OO just fine without.
As to information hiding, there are many fine OO languages which don't have it either (Python probably being the prime example there, but I'd say it also applies to languages like Ruby where you can trivially override existing ACL) so it's clearly not necessary either, let alone "the most important part". Especially as conversely many non-OO languages do have access control, hinting that the two are quite likely orthogonal.
Information hiding is useful for engineering and resilience, not for object orientation.
As to private / protected / public, I'd argue it's private which is the least useful (since we've already ascertained none is actually needed): it's literally just hiding stuff from yourself. I think removing that level of ACLs is one of the few good idea Go had.
Congrats, you're back to 'encapsulation'! Encapsulation is actually the only important tool in that particular toolkit. We're mortals, we need coping tools to keep programs manageable.
Upvoted anyways :)
Polymorphism, no; I mean, how can we substitute different kinds of objects into the same situations dynamically without polymorphism. OOP is almost synonymous with polymorphism.
But we do not have to bundle code and data representation together; there are other approaches to OOP, like generic functions.