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:

* The NygaardClassification. OO programming is where "A program execution is regarded as a physical model, simulating the behavior of either a real or imaginary part of the world.". Many consider this to be the definitive definition; coming from one of the inventors of SimulaLanguage, the first OO language. This definition is the most inclusive - focusing on how a program is ''modelled'', and eschewing any requirements for specific language features (such as found in the other two versions). In the NygaardClassification, OO-ness can be considered the property of a ''program'' rather than a ''language'' - it is possible to write Nygaard-OO programs in C or assembler if one chooses. (This doesn't make these languages OO; many choose to disregard the NygaardClassification when classifying a ''language'' as OO as Nygaard is almost orthogonal to language definition).

* PolymorphismEncapsulationInheritance. Or delegation, if you prefer. This definition seems to have arisen from the C++ community (anyone know the source of this? AnswerMe) - and indeed lists three traits found in many OO languages.  However, counter-examples abound. In many languages (such as PythonLanguage) encapsulation is by convention rather than enforced by the language; and "inheritance" is often replaced with delegation or other means of interface/code reuse between classes/objects. Furthermore, the use of the word "polymorphism" in this context isn't quite correct - what is meant is SubtypePolymorphism; other forms of polymorphism (while welcome) are not what is intended by the definition. (See OnUnderstandingTypes). Use of classes and/or interfaces as explicit object types is often implied in this approach, but it isn't required. 

* AlanKaysDefinitionOfObjectOriented. Many in the OO community (particularly users of SmalltalkLanguage and its derivatives) consider AlanKay to be "the founder of OO" and the rightful inventor of the term (HeInventedTheTerm). While it is undisputed that Simula predated Smalltalk by several years and that Kay was aware of the work on Simula (he acknowledges the work of Nygard and Dahl in his writings), Kay is widely considered to be the first to actually use the term "OO" (though Nygaard and Dahl used the term "object" in their writings on Simula - see HeDidntInventTheTerm). The Kay definition is the most restrictive, as it excludes many languages (notably CeePlusPlus and JavaLanguage, two languages which Kay has bad-mouthed on numerous opportunities) widely considered by others to be OO. Some say this exclusion is intentional, as C++ and Smalltalk competed for developer mindshare through much of the 80s and early 90s; others say that it is justified (based on the claim that C++ is a poor language). 
** Kay's definition includes PolymorphismEncapsulationInheritance, but adds a few additional requirements:
** All first-class types must be objects. C++ and Java fail here, as both have types which aren't objects as part of the language.
** A singly-rooted inheritance hierarchy. This also trips up C++, which (unique among OO languages) does not have a universal superclass (TopType).
** In addition, Kay has often claimed that StaticTyping is a bad thing, and has written that a good OO language should feature "late binding in all respects".  (Which Smalltalk has). Whether or not Kay considers DynamicTyping a requirement for OO is unclear.
** RobertCecilMartin, OO pundit and founder of Object Mentor, says that basically AlanKay is wrong, and says that OO is about the DependencyInversionPrinciple (see DependencyInversion). To quote, "I define Object Oriented programming as programming in which abstractions are independent, and concrete modules depend upon them. i.e. Dependency Inversion" See http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=3bb75285.7175698%40news.supernews.com (Dated 2001-09-30)  He may have changed his mind since going agile, but this view is not necessarily mutually exclusive with agile methodologies.

* William Cook proposes a modern definition for OO: ''An object is a first-class, dynamically dispatched behavior. A behavior is a collection of named operations that can be invoked by clients where the operations may share additional hidden details. Dynamic dispatch means that different objects can implement the same operation name(s) in different ways, so the specific operation to be invoked must come from the object identified in the client's request. First class means that objects have the same capabilities as other kinds of values, including being passed to operations or returned as the result of an operation. A language or system is object oriented if it supports the dynamic creation and use of objects. Support means that objects are easy to define and use. It is possible to encode objects in C or Haskell, but an encoding is not support.'' This definition is further explained at (http://wcook.blogspot.com/2012/07/proposal-for-simplified-modern.html).
** Re: "Hidden details" - This could exclude some dynamic "OOP" languages which don't have explicit GateKeeper mechanisms.

* Luca Cardelli and Martin Abadi developed SigmaCalculus to model OO, described in the book TheoryOfObjects. While they never outright define OO, they formally address and model elements common to OOP languages: method lookup and dispatch, classes and inheritance, subclasses and specialization, self types, delegation, etc.

* ObjectsAreDictionaries - maps that can readily contain "function pointers" or function containers, with language and/or syntax features that assist in or simplify the usage of these function maps. 
** Variation: "objects are maps that can map interfaces and/or references to other such maps."

* OO is the view that EverythingIsa a behavior (including data structures)

* OO is the "natural extension" of programmer-defined types (sometimes known as user-defined types).

* Inheritance + Encapsulation (no polymorphism): "Inheritance is what separates abstract data type (ADT) programming from OO programming." Section 19.1 of the Feb 2000 Usenet C++ FAQ, which is also published in expanded form in a popular and influential book.  Inheritance without polymorphism, however, is little more than compiler-assisted CopyAndPasteProgramming. Useful, but OO?

* SmugLispWeenie''''''s define GenericFunction''''''s as ObjectOriented, perhaps because ClosuresAndObjectsAreEquivalent. A program is object-oriented when a single function can have many behaviors depending on the types of its arguments.  Some OO languages don't have type overloading, however.  This includes SmalltalkLanguage; the only argument to a Smalltalk message which is used to resolve what method should be used is ''self'', giving rise to the DoubleDispatch pattern.

* DavidMoon, an old-time Lisp god and writer of much of LispMachine Lisp, defines object-oriented as "things are independent of their names".  An OO language is one where as much of the language machinery as possible consist of objects that can be bound to identifiers. Good examples would be Lisp/Dylan/Scheme, with their FirstClassFunction''''''s/Classes/GenericFunction''''''s/Modules. Bad examples would be C++ and Java, where classes/methods/namespaces are language constructs and can't be passed around in variables.  

* Jonathan Rees discusses multiple definitions of OO (see ReesOnObjectOrientedFeatures). In addition to others listed above, he also has
** "6. All you can do is send a message (AYCDISAM) = ActorsModel - there is no direct manipulation of objects, only communication with (or invocation of) them. The presence of fields in Java violates this."
** "9. Sum-of-product-of-function pattern - objects are (in effect) restricted to be functions that take as first argument a distinguished method key argument that is drawn from a finite set of simple names. "
** "So OO is not a well defined concept. Some people (eg. Abelson and Sussman?) say Lisp is OO, by which they mean {3,4,5,7} (with the proviso that all types are in the programmers' heads). Java is supposed to be OO because of {1,2,3,7,8,9}. E is supposed to be more OO than Java because it has {1,2,3,4,5,7,9} and almost has 6; 8 (subclassing) is seen as antagonistic to E's goals and not necessary for OO."
** '...the C/C++ folks see OO as a liberation from a world that has nothing resembling a first-class functions, while Lisp folks see OO as a prison since it limits their use of functions/objects to the style of (9.)"
** Interesting discussion of definitions of "value", "object", "function", and "type"

* ChrisDate (an RDBMS pundit, and highly influential in that realm): "An object is essentially just a ''value'' (if immutable) or a ''variable'' (otherwise)." (24.1 ''Introduction to Database Systems'') It seems clear that essentially all '''OO''' pundits would strongly disagree with that summary, although a lot of Date's discussions of OO '''databases''' are more generally reasonable, if still potentially arguable.

* "Binding Behavior to References" - Disputed in ArgumentsAgainstOop, where it's stated that OOP is one (or few) of many techniques to manage such references, not the existence of references themselves.
----

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:

* Be applicable to both dynamic and static OO languages.
* Not be defined in terms of other vague or contentious terms (unless defining those first)
* Be relatively short. Long definitions are a sign that more work is needed to extract a higher-abstraction essence.
* Make it clear whether OO is discrete or continuous. In other words, can something be "more OO" than another, and how do we measure.
* Make it clear whether OO is a mental process or a coding organization technique. If it is both, then make sure both are tied together in the definition.

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

* ''Re: "computer science is discrete" - Is this mandatory via universal logic, a historical habit, or something else?''
* ''Note that if something involves parts, then having only some of the parts can make it "continuous" from a perspective. For example, if someone defines OOP as having characteristics A, B, and C; but a given thing has only A and C, then one could make a case that it's "2/3 OOP". -t''

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: 
* ClassesPrototypesComparison
* DelegationIsInheritance
* EncapsulationDefinition
* ExternalPolymorphism
* InternalPolymorphism
* IsJavaObjectOriented
* IsCeePlusPlusObjectOriented
* NonPolymorphicInheritance
* ObjectOriented
* PolymorphismAndInheritance
* WhatIsDelegation
----

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

* '''But''', if you like SmallTalk you know where to find it. It is unfair to criticize OO environments who are successful in the marketplace for lacking all the features of the unsuccessful ones. Maybe it was '''precisely''' the everything and the kitchen sink approach that failed, maybe it was something else altogether, but that all that Smalltalk had '''is''' actually necessary in Python, Java or Javascript is not at all clear. Maybe ex-smalltalkers miss them, but if somebody could snap his fingers and throw everything in, then you'd have another Smalltalk. So why bother ? Prove that Smalltalk is successful the way it is, or otherwise try to understand why it failed and create the next great Smalltalk. Endlessly complaining along the lines Java is not Smalltalk has been discredited and is not productive. The BurdenOfProof lies with the Smalltalk community. --CostinCozianu'''

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. 

* ''How are you measuring and comparing "abstraction"? I keep seeing this viewpoint, but have never seen it defined specifically enough to show that OO has it and other things don't. Yes, OO has a "flavor" of abstraction, but not necessarily more abstraction. -t''

* I was trying to explain that some people consider object oriented to be programming with objects, where objects is defined as an opaque datum, a thing, a discrete undividable unit of data, with a certain public interface (which may consist of functions and / or public data members). I claim that is not actually what they mean. When made to think about it, people will agree that object orientated programming is not programming with non-polymorphic objects, no matter how well encapsulated, abstracted, and data-hidden.

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