Object Oriented

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?.]

Encapsulation

: Encapsulation is a technique for minimizing interdependencies among separately-written modules by defining strict external interfaces. The external interface of a module serves as a contract between the module and its clients, and thus between the designer of the module and other designers. ... A module is encapsulated if clients are restricted by the definition of the programming language to access the module only via its defined external interface. ("Encapsulation and Inheritance in Object-Oriented Programming Languages" : OOPSLA 86 proceedings)
: Every object has a well-defined interface that specifies the behavior of the object in a manner that is independent of its implementation. This interface defines the collection of services that can be invoked by other objects. The implementation of an object describes how to carry out its services. This includes information private to the object, accessible to other objects only if services exist to provide such access. Similarly, the algorithms that implement services are private to the object. No other object can rely on how another object implements its services. This ability of objects to hide internal structure, thereby defining services independent of implementation, is called encapsulation. ("Succeeding With Objects": AW 1995)
: Modularity[Synonym]: No component in a complex system should depend on the internal details of any other component. (DanIngalls : August 1981 Byte)

Related to above: WhatIsModularity, FuzzyDistinctionBetweenInterfaceAndImplementation

Data structures can restrict the visibility of their attributes and associated operations. The implementation of these operations are hidden.

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?]

Polymorphism

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.

Inheritance

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.)

{Clarification of "type" may be needed. How languages define "types" varies widely. Contrast SmallTalk with JavaLanguage, for example.}

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.

Interesting Links:

Quotation:

"I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning -- it took a while to see how to do messaging in a programming language efficiently enough to be useful)." -- AlanKay
"Well Kay does complain about how his ideas for OOP have been implemented badly. One of his famous quotes is in this speech. It goes something like, "When I created object-oriented programming, C++ is not what I had in mind." He also complained that Java thinks its doing the programmer a favor by imitating an old form of programming, "when in fact it's hurting the programmer terribly", because it obscures what's powerful about the OOP architecture." -- Reddit Link Above
"I had a couple correspondences with Kay last year, one on what you talked about. I asked him about his conception of programming, particularly OOP. He responded, "Well, I don't think I have a real conception of programming, I'm still groping for something better than what we have," and, "I don't think of it as necessarily being in terms of objects (even though as 'computer entities' with properties and behaviors, they are usefully universal)." -- Reddit Link Above

(By the way, collides with ModularProgramming, MopMind? and some issues discussed in EventualSideEffects (re: cells, nodes, et al)).

"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"

http://linux.sys-con.com/read/46770.htm

[EditHint: consider moving this to ArgumentsAgainstOop]

See ObjectOrientation, ObjectOrientedProgramming, ModularProgramming, ArgumentsAgainstOop, BenefitsOfOo, DefinitionsForOo, ObjectOrientedDiscussion?

CategoryObjectOrientation