An Object Oriented system, language, or environment should include at least Encapsulation, Polymorphism, and Inheritance.
PolymorphismAndInheritance are certainly patterns that facilitate OO programming, but are these essential to the idea of objects? It's possible to do without them (e.g., perforce in VisualBasicForApplications and VisualBasic) and yet program with constructs that model real-world entities. Encapsulation seems to be the key distinction between OO and procedural programming: asking data to do things instead of doing things to data -- DavidWright [Agreed. See ObjectOrientedDiscussion?.]
My CeePlusPlus professor explained this concept thus: "objects are data with methods attached." This made sense to procedural programmers, whose sole programming experience was with functions floating around in the ether. -- NickBensema
[In my opinion this is the core of OO thinking. Everything else follows from this concept. In OO thinking, you model your programs around "objects", which are bundles of data and related functions. In fairness, I arrived at OO design by my own somewhat roundabout route and was not taught it from above, so to speak, so my viewpoint is rather less academic than most. -- ChrisMellon?]
Identical (identically-named) operations can behave differently in different contexts. The operations that can be performed on an object make up its interface. They enable you to address operations with the same name in different objects.
You can use an existing type to derive a new type. Derived types inherit the data and operations of the super-type. However, they can overwrite existing operations or add new ones.
(Delegation is part of any language because any language can call other functions to implement a function. What is key is a first class construct in the language? Inheritance isn't really necessary.)
Agreed - encapsulation is the key. We can see that OO programming is simply the next generations of programming languages - so called 4GL languages are a side branch, not part of the main sequence. At each stage - assembler, macro assemblers, procedural, object oriented - stuff gets wrapped in containers. You can make a thing, test that it works, and then wrap it in a container and use it by name. -- PaulMurray
Encapsulation is a property of abstract data types (ADT). In most modern object-oriented languages, a class is an ADT with support for polymorphism and inheritance. -- AG.
Hmm, according to the smalltalk inventor, AFAIK OOP (ObjectOriented) is actually about messages.. and the definition of ObjectOriented got vaguer and vaguer with time.. being twisted for marketing hype. Some OOP languages don't even use messages (or some languages don't offer the ability by default and fake it through other means like parameters).. which just goes to show you that whatever OOP is, we don't know it. Maybe the real OOP revolves around messages and this other OOP is some other similar form (extended imperative programming). Below links and quotes provide some references.
"Modularity[Synonym]: No component in a complex system should depend on the internal details of any other component." (DanIngalls)
That's a nice pipe dream.. how about the Unix API and Windows API? Every system relies on the internals of other systems.. maybe in more abstract ways.. but it is all connected. For example all modular Exe/Elf/a.out programs rely on the internals of the OS api. Not so directly as in accessing global variables in the DLL's.. but it is still making use of the core internals in the end. Even simple subprograms or procedures could be considered modules that hide inner details of the procedure (and lexical closures also).
I think they meant that all communication goes through interfaces instead of "hacks" directly into the internals. (Confusion can arise because interface behavior can be tied to internal implementation also.) But functions provide this also. Further, it may be the case that tying stuff to the internals can simplify the design in some cases. Excess indirection (lots of interface layers) can make code verbose. It's all about weighing trade-offs, not magic always/never rules. -- top
"OO Isn't Everything," Says Unix Veteran Rob Pike"EditHint: consider moving this to ArgumentsAgainstOop]