Definitions For Oo

Many different definitions for ObjectOriented exist; this page catalogs those which carry some weight in the programming (both industry and academic) community. Unfortunately, NobodyAgreesOnWhatOoIs, a fact used by some to try and discredit OO.

Simple logic says that the definitions below that do not even refer to "objects" probably are not truly definitions of OO, no matter what their authors say; instead, some authors may have eroded/hijacked the phrase "object oriented" to instead mean "good post-plain-procedural programming". RobertCecilMartin's definition below seems especially clearly to be guilty of this.

Therefore perhaps this page's definitions could be split into two categories for clarity (those that actually refer to objects, and those which do not). However, some claim over-reliance on "object" risks a self-referencing (recursive) definitions though.

The following definitions of OO are widely cited, and accepted by significant subsets of the community:

Claim:

TheoryOfObjects defines object-oriented in terms of LambdaCalculus and CategoryTheory. An object is an unordered record of functions, each with a specific type. See also ClassesPrototypesComparison.

Rebuttal: TheoryOfObjects starts off from the very first page by describing object oriented systems pretty much in the exact words as Nigaard (simulating physical model), therefore it is in correct to say that they came up with another definition. Next, they didn't use LambdaCalculus at all, their thesis and their point in writing the book was that lambda calculus was an inadequate tool to describe properties of object oriented languages so they come up with their own calculi (several) that can be used to reason about object oriented features more effectively. The calculi however do not make a definition, they're just a formalism, a tool if you will.

Comments:

Re: Unfortunately, NobodyAgreesOnWhatOoIs, a fact used by some to try and discredit OO.

Are you suggesting that is not a mark against it? Or perhaps a small enough mark to not negate its alleged benefits?

[I would certainly claim it is not necessarily a mark against it. As I said elsewhere, there's no universal agreement on what "mathematics" is, but that doesn't prevent it from being critically useful nor for useful mathematical work to proceed.]

[Definitional issues are always secondary, and quite often more difficult, than work itself. And note that definitions within math are formally considered to be completely irrelevant. They're like comments.]

One could argue that excess fuzziness brings about problems because it creates inconsistency and confusion. See OoLacksConsistencyDiscussion.

It shows an interesting thing about OO - that the concept(s) of OO came ahead of the formal frameworks and methods which describe OO - the OoLacksMath? argument. There have been several mathematical models for OO proposed; TheoryOfObjects has one, the PiCalculus is another. None has been accepted as the canonical model to this point. Relational theory, OTOH, is all based on the work of DrCodd, and FunctionalProgramming is based on the LambdaCalculus (actually the lambda calculi, as you have typed- vs untyped- variations). Now - is the absence of an agreed-upon formal framework harmful? Perhaps; if nothing else a formal framework might help to unify the many different terms, conventions, and technologies in use. Is it fatal to OO? I think not; OO has shown itself to be a valuable paradigm despite the lack of formalism.

As far as implementations, so have Goto's.

Are there other principles of object-oriented design than those listed by RobertCecilMartin, http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign?

Yes! In particular see the list of (often conflicting) DefinitionsForOo, including the links (in particular the stuff on paulgraham.com that is linked to was a bit too long to paraphrase on c2.com). I think RobertCecilMartin is interesting, and says worthwhile things about software, but truthfully he really annoys me by redefining words. He has an idiosyncratic definition for "OO" in particular that no one in the world except his followers share, as mentioned on the cited page. His list on PrinciplesOfObjectOrientedDesign, on the other hand, is an excellent list, but again, is about software in general, absolutely not about OO in particular; most of it applies perfectly well to old style structured programming in procedural languages. Which reminds me, see the much-neglected yet not obsolete CouplingAndCohesion. -- dm

A good definition of OO should probably:

'''I'm not sure if these goals are possible. As someone noted before, definitions of OO can conflict with each other--indeed, downright contradict each other--and so it may literally be impossible to reconcile definitions.

As for "discrete or continuous", I think the question is almost meaningless--computer science is discrete, after all--but what I think you mean is whether or not it's possible to put an "order" on languages. The answer to that, I think, is a "qualified yes": language A can be more object-oriented than language B, but to complicate matters (taking tinto consideration conflicting definitions, for example) language C might not be comparable to A or B

Finally, OO is clearly a mental process. There's at least one book about programming OO in Assembly Language; the Linux kernel proudly uses objects in its file system modules, despite being written strictly in C. Indeed, Lispers like to use closures for OO, and Haskell's type system implements polymorphism in a nice way.

This is anagolous to structured programming: you can write Assembler or BASIC or FORTRAN with beautiful if blocks, while loops, and for loops--but these languages don't have the native keywords, nor the block structure, that makes programming structurally in C so nice! (And then there are languages like Lisp and Forth, that might not start with trappings for OO, or even structured programming, but you can add those things as you need them. Smalltalk is almost like this--it starts out with *only* the trappings of OO, and grows from there.) --Alpheus'''

From DataCentricThinking:

Under the OneResponsibilityRule and OnceAndOnlyOnce, OO programs migrate towards a DivideAndConquer strategy with configurable delegation: an object will take a big problem, break it into a few smaller problems, delegate the smaller problems, then somehow combine or coordinate the solutions. For example, if part of the problem requires computing a grocery list, you might delegate that problem to an object that happens to be an expert system - though, all you need is a proxy interface that will return your list. The need for delegation creates a need for DependencyInjection. The fine granularity of objects results naturally from decomposing the problem with a DivideAndConquer strategy. I suggest: decomposing a difficult solution into smaller objects with dependencies indicates whether you're doing object oriented programming - as opposed to merely programming in the presence of objects.

Related:

I wonder if the reason for all these definitions is, that most of them fail at definining WhatIsAnObject. At least I was unable to find a definition on ObjectOriented, ObjectOrientedProgramming, NygaardClassification and others (which led me here). Even the prime example SmallTalk fails at this. Everything is an object, but only in the sense, that it is the core of SmallTalk, which is self-referential (the Java "Object" is a different object). There seems to be an implied understanding of what an object (in reality or programming is. And this understanding is much too fuzzy, because really ThereIsNoObject. -- GunnarZarncke

I'm reminded of the famous Justice Potter Stewart quote regarding a definition of obscenity:

I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description; and perhaps I could never succeed in intelligibly doing so. But I know it when I see it, and the motion picture involved in this case is not that. (http://caselaw.lp.findlaw.com/scripts/getcase.pl?court=US&vol=378&invol=184)

I suppose I'm offering a restatement of AlanKaysDefinitionOfObjectOriented. I've been doing ObjectOriented development since 1982. I've done it in PDP11 assembler, Lisp, Pascal, C, C++, ObjectiveC, Smalltalk, Java, Javascript, Perl, Python and a gazillion private dialects of one or more of the above. I feel that ObjectOriented programming is therefore something that I can do in virtually any language and system. I therefore find it more interesting to discuss the extent to which a given combination of hardware, software, OS, language, and toolset enhances or impedes my ability to do ObjectOriented development. My own first-hand experience is that C++ absolutely gets in my way, Java is marginally less successful at accomplishing the same goal (of impeding my progress), and Smalltalk, Python and current versions of Javascript (v1.5) help me out -- Smalltalk much more so than either Python or Javascript.

I strongly suspect that this debate about DefinitionsForOo will continue at least as long as DefinitionsForObscenity? -- which is approximately forever. In the meantime, Python and Javascript are each widely used, are free of charge, and still lack a variety of tools offered by mainstream Smalltalk environments of a decade ago. I wonder if we might all benefit from spending rather less time perpetuating this endless argument and rather more time figuring out how we might, for example, provide a reasonable, reliable, self-contained debugger/inspector in Javascript that provides the same functionality offered by the Smalltalk debugger twenty five years ago in Smalltalk-80. -- TomStambaugh

Well said.

On the other hand, until I participated in constructing material on this page, and seeing the joint results, I was unaware of just how much diversity of opinion was out there. I find this interesting quite independently of the argument about who is right.

To put it another way, I've been mentally interpreting the material on this page as a taxonomy of language types and features, and despite limitations of taxonomies, I find them very useful for multiple purposes. -- DougMerritt

I feel somehow misunderstood. My point was not to try DefinitionsForOo (that may indeed not be possible), but that ask a somewhat more basic question: WhatIsAnObject. I know, that probably everyone here has a an understand of what it is (otherwise we couldn't programm OO at all). And I myself have programmed OO in assembly in the 68K micro kernel that was part of my dissertation (creating virtual method dispatch tables with macros). I have an idea of what an object is: MemoryWithMeaning?. But is it really that? Or how would you define an object? -- .gz

That's an easy one -- an "object" is "what I do object-oriented programming on". -- ts

Thats self-referential, isn't it? Or if it isn't it implies too much. Its like saying "Wood, thats what a carpenter uses." Each ProgrammingParadigm may have its own understanding of an object, but there surely are common properties. -- .gz

Claims that OO is the "original three" ideas, and attempts to make it more are rubbish:

http://www.tonymarston.net/php-mysql/what-is-oop.html

The funniest sentence:

"Having created 1000's of programs using non-OO languages, and another 500+ using the OO features of PHP I feel more than qualified to add my own contribution to the melting pot."

Here are my own observations on the definition of OO as drawn from common usage, intent, and usefulness.

Definition A- Abstraction, Encapsulation, Data Hiding. Otherwise known as object based. People might commonly refer to this as OO, but most of the time such claims will be retracted when pressed. For example, under these requirements, CeeLanguage is OO, and that's not what most people mean when they say OO.

Dynamic Dispatch. This includes the ObjectsAreDictionaries definition. There are collections of data called objects. These objects also have methods which you may call on them. These methods are not resolved statically, but instead depend on the runtime type of the object. This is the message passing description of Smalltalk. In C++ terms, when you call a virtual method, you're not calling a specific function. Instead, you're passing a message to the object, telling it to invoke a method with a certain name. This is the most useful definition of OO IMHO, and generally coincides with what most people consider OO.

I reject the "single inheritance tree" requirement as not an important quality to what most people call OO. I also reject the modeling definition of OO; you should be able to say a language natively supports OO without looking at common usage of the language. Dynamic dispatch is an objective quality of the language, and it is this quality which most people mean when they say a language natively supports OO.

Also, it is possible to do OO in languages other than those which natively support OO. You can write the equivalent code of SmalltalkLanguage or LispLanguage in CeeLanguage. It would be ugly and mostly impossible to maintain, but it would still be "OO".

Responding to above question where the virtual C++ oriented definition of OO came from, this might be a start.

Quoting: http://www.parashift.com/c++-faq-lite/big-picture.html#faq-6.9 http://www.parashift.com/c++-faq-lite/big-picture.html#faq-6.10

Dynamic binding can improve reuse by letting old code call new code. Before OO came along, reuse was accomplished by having new code call old code. For example, a programmer might write some code that called some reusable code such as printf(). With OO, reuse can also be accomplished by having old code call new code. For example, a programmer might write some code that is called by a framework that was written by their great, great grandfather. There's no need to change great-great-grandpa's code. In fact, it doesn't even need to be recompiled. Even if all you have left is the object file and the source code that great-great-grandpa wrote was lost 25 years ago, that ancient object file will call the new extension without anything falling apart. That is extensibility, and that is OO.

[Jumping to different area in above link for emphasis]

Bottom line: C++ without virtual is not OO.

End quote.

This a disingenuous definition of "OO". To claim that old code could not call new code is absurd! Besides the obvious example of Lisp, which did these sorts of things pretty much from day one with first-class functions, it's even done in languages like C! The classical example is that of C's implementation of quicksort, which takes a pointer to an array, and a function that defines an order on the contents of the array, and sorts the array (in place, if I recall correctly). Even though this implementation was written decades ago, it can sort C++ objects. -- Alpheus

While I agree with this assessment in general, please be careful about using words such as "disingenuous" without having more background on the person. The author may simply be naive or inadvertently leaving out an assumption that would better qualify their statement. Possilby related: CeeIsNotThePinnacleOfProcedural.

{I think "Alpheus" must be quite young. I'll revise the bottom line: C++ with neither virtual, nor deliberately constructed and inevitably awkward mechanisms to explicitly support old code calling new code, is not OO.}

CategoryObjectOrientation, CategoryDefinition

EditText of this page (last edited November 24, 2014) or FindPage with title or text search