New Definition For Oo

We've now been doing OO for nearly 40 years (or longer, depending on when you start--I'm starting in 1967 with Simula). Many DefinitionsForOo have been proposed, go there to see 'em.

None of them are, in my mind, completely satisfactory; most of the reflect the biases of a particular speaker/writer or language community.

This page is intended for new suggestions on just what OO is. I'm looking for general philosophical and empirical observations, not a precise mathematical model for OO (no rehashing the OoLacksMathArgument here please).

Referencing an existing definition for OO is OK, but just don't repeat them.

Definitions go here

In my view, the key traits of OO are:

Abstraction. The ability to decouple the implementation of a thing from its external appearance (its interface), and even replace one implementation with another, is vital to OO.
- Subroutines and functions have been doing this for a long time.
Subtyping/Dynamic Polymorphism. Whether implemented through inheritance, delegation, DuckTyping, or other means--the ability to specializing via subtyping and perform DynamicDispatch of some sort is a common thread throughout all OO languages. It's the difference between ObjectiveCaml, which I consider OO, and other MlLanguage dialects, which I don't consider to be OO (though they're interesting and useful languages nonetheless).
Composition. I don't refer to the practice here of having one object/class contain a named instance of another, though that's certainly part of it. Instead, I refer to all means of composing systems out of other systems; including aggregation, inheritance, delegation, wrapping, specialization, extraction, etc.
Communication. Here I'll quote AlanKay; agreeing with him that the messaging between objects (I'm using a different term, as the term MessagePassing is overloaded) is just as important, if not more so, as the internal structure of objects. After all, it's much easier to abstract away an object's internal structure than it is to abstract away its interface.

All the rest is, to my mind, implementation details. Not that such details can be ignored--they cannot; and the implementation details are what frequently separate good languages from bad. Instead, what I mean is that abstract arguments over implementation details frequently miss the big picture.

-- ScottJohnson

All the above are nice features to be supported by a language design or more generally by a programming method. However they are not defining, they cannot be used to differentiate OO specific properties. For example ErlangLanguage and professional software written in Erlang has all the above features, their proponents however insist that they are not doing OO. So you have a problem. Even in ML you can specialize via SubTyping? using parameterized modules. Google for Tofte's very well written introduction "Four Lectures on standard ML". The problem is also that SubTyping? is a much larger concept than subtyping for specialization. --Costin

That was somewhat intentional. The above is intended to be a bit more concrete than Nygaard/Dahl, but a bit more abstract than AlanKay's definition, which seems to be arrived at by including numerous features of Smalltalk, and prohibiting several things present in C++ but not in Smalltalk--i.e. MultipleInheritance. The features have changed over the years, which is why I didn't want to mention any features specifically; however the techniques are what's important. As far as defining goes, any language feature that contributes to any of the above is an OO feature; any language which contains features allowing all 4 to be reasonably addressed is an OO language. Note "reasonably"--greenspunning up an OO implementation in CeeLanguage doesn't count, even though it can done and has been done several times.

I've deliberately left out numerous topics of contention--StaticVsDynamicTyping, the EverythingIsaObject debate, hard vs soft encapsulation, and issues of state management and concurrency.

ErlangLanguage is an interesting case. As you point out, it has features satisfying all of the above, so it can qualify (though it's perhaps weaker in some of the compositional aspects than more mainstream OO languages). However, many Erlang programmers eschew the OO label. I'm not sure why. Perhaps it's because OO gets tarred with the brush of SharedStateConcurrency--fairly or unfairly--something that Erlang was designed from the start to avoid. Or perhaps it's because SmugErlangWeenies :) tend to come down on the FP side of the OoVsFunctional ParadigmPissingMatch. (Which is ironic, because many FunctionalWeenies exclude Erlang from the FP community due to CommunicatingSequentialProcesses breaking ReferentialIntegrity, despite Erlang being a SingleAssignmentLanguage).

At any rate, I'm not sure surveying the programming community of language X is a good way of determining the OO-ness of X. Interesting, perhaps, but not pedagogically useful.

--ScottJohnson

Erlang is essentially non-OO. It may not be referentially transparent but also its components do not hold state. In Erlang the most you have close to objects are processes, but unlike objects, Erlang objects do not hold state. Other than processes, Erlang computation are biased to be about algorithms on data structure using recursion and structural induction, just like any other FP. Before defining a class, an Erlang user is likely to use an ad-hoc data structrue such as tuple, list, etc, that will just do the job. This makes it clearly a non-OO language and programs written in Erlang are not really object oriented.

I deliberately excluded state, or lack thereof, from the criteria... there are other ObjectFunctional languages which have runtime (subtype) polymorphism but which lack mutable state, I generally consider these to be OO. Use of canned data structures like tuples and lists doesn't count against being OO; as all production OO languages have their own implementations of these, and programmers are encouraged to use them. That said, Erlang does lack many of the composition facilities, such as inheritance, found in most OO languages. While Erlang is closer to OO than Haskell is, by virtue of DynamicTyping and CSP, it's probably less OO than OcamlLanguage. I'm kinda on the fence on this one.

Add to that the refusal of its users to subscribe to count themselves within the OO camp, and you have a pretty strong case, that maybe both Erlang and OO are better when not mixed together. It can create a certain confusion, and we wouldn't want to approach the UseNet level definition: "oo is just good programming" :)

Oh, I won't go there...I've seen plenty of bad programming marching under the OO banner.

Other than that, even ML and Haskell fit the above picture quite nicely (except the fuzzy term called "communication"). I will not hold my breath that something can convincingly replace NygaardClassification. --Costin

Neither ML nor Haskell have dynamic subtyping (I modified my definition above somewhat to make clearer the point I was trying to make); all types being resolved by the compiler and all type information being elided from the generated code. (Erlang and O'Caml do, OTOH). While I've tried to be feature-neutral, this is one feature that is a common thread for all languages commonly considered OO.

Actually, Haskell has dynamic dispatch for subtypes (aka the actual type conforming to a type class). I don't know for sure, but I would imagine that ML compilers must use a similar dispatch mechanism in order to avoid code bloat and in order to support separate compilation. Unlike C++ templated code, generic code in ML and Haskell can be compiled to object code and shipped with interface only declarations. This promotes abstraction and composition and it is implemented by dynamic dispatching. So your characteristics are not quite characteirstic of OO.

Re: Abstraction

Defining something based on "abstraction" has proven to be a can of worms. Most proponents of a given paradigm claim their pet paradigm, language, or tool allows "abstraction" also. For example, PrologLanguage has abstraction in that you allegedly define what you want instead of define how to get it. This is generally not considered part of OO philosophy, but is a highly abstract concept. OO's "brand" of abstraction tends to be a form of SoftwarePlatonism, for good or bad. -- top

Discussion goes here

CategoryObjectOrientation