13

I can't think of a better place among SO siblings to pose such a question. Originally I wanted to ask "Is python a pure OO language?" but considering troubles and some sort of discomfort people experience while trying to define the term I decided to start with obtaining a clear definition for the term itself.

It would be rather fair to start with correspondence by Dr. Alan Kay, who has coined the term (note the inspiration in biological analogy to cells or other living objects).

There are following ways to approach the task:

  1. Give a comparative analysis by listing programming languages that can exhibit (or fail to do so) certain properties unique and sufficient to define the term (although Smalltalk, Scala, Java, and so on - are possible examples but IMO this way seems neither really complete nor fruitful)
  2. Give a formal definition (or close to it, e.g. in more academic or mathematical style).
  3. Give a philosophical definition that would totally rely on semantical context of concrete language or a priori programming experience (there must be some chance of successful explanation by the community).

My current version: "If a certain programming (formal) language that can (grammatically) differentiate between operations and operands as well as infer about the type of each operand whether this type is an object (in sense of OOP) or not then we call such a language an OO-language as long as there is at least one type in this language which is an object. Finally, if all types of the language are also objects we define such language to be pure (strong) OO-language."

Would appreciate any possible improvement of it. As you can see I just made the definition dependent on the term "object" (often fully referenced as class of objects).

[EDIT]

In addition, I use (luckily well understood) notion of a type as in typed languages. Data type programming or type oriented programing is not only a syntactical interpretation (of the program text, i.e. how to treat certain values of literals and data variables - something that evolves into type safety) but can be attributed to language grammar and studied in formal way (using mathematical logic) as so called type systems. Notice that requiring particular type system to have a so called universal type is one of the ways defining purity of OO language (there are ways to expand this semantically).

NB

how to answer:

  • it helps if you specify a book or a reference that supports/explains your understanding of terminology and concepts (usually a good definition covers or references all depended concepts except elementary).
  • if possible indicate an indented category of your answer/definition if it is not clear otherwise (see above: 1 - by language example, 2 - mathematical logic, 3 - technical description and programming philosophy)
  • classification is important (and also because term pure-OO is included into term OO) while answering try to unmix elements of OO paradigm from other well known methodologies (and by no means confuse/overlap them, e.g. typically elements of modular programming can be covered/embodied with OO programming): try to distinguish OOP from (including or being a part of) Functional programming, Logical programming (especially strongly specialized ), Abstarct Data Types (ADT), Modular, Metaprogramming (generics and LISP's macroexpansion-time), Contracts (e.g. Eiffel), Aspect-oriented (AO), (difference between declarative and functional classification as well as historical definitions of Dijkstra's structured are clear)

on difficulty of giving a formal definition: surprisingly enough it is very easy to give a mathematical description of OOP in form of a certain logical (formal) system (most likely type based) and defining one concept after another. One can even try to do something more practical by applying that formalism to type safety checking or new language design aspects than merely abstract entertainment or exercise (also lookup formulation of OOP in Intuitionistic Type Theory, Dependent types, independently, in FOL formalisms as lambda calculus and just by using category theory). A main point here is that unsurprisingly such formulations IMO are strongly biased (flawed) by most likely initially incomplete understanding of OOP (in computer engineering) and end up being almost inaccessible afterwards (thus hardly contributing backwards to programming world - maybe except certain percentage finds applications back from formal world by being integrated into popular languages).

So yes, it is difficult to give exactly a "good" definition, not just definition. But I am positive of asking this here because of your experience and direct involvement, guys.

Community
  • 1
Yauhen Yakimovich
  • 333
  • 2
  • 11
  • 2
    Well, you've answered yourself for Python. "No". – psr Sep 12 '12 at 01:29
  • 2
    +1 for the nice question, but your version is a bit flawed by the problem that a *type* and an *object* are different things. – Frank Sep 12 '12 at 05:17
  • Speaking of class-based OO languages, imho a type should only be defined by an interface in a pure OO language. – Random42 Sep 12 '12 at 07:49
  • I find it *very* interesting that Alan Kay actually talks *a lot more* about messages than about objects. – Joachim Sauer Sep 12 '12 at 08:36
  • 5
    @JoachimSauer: He said in another mail on the Squeak mailinglist that "the big idea is Messaging" and that he regrets ever having called it "Object-Oriented" and should rather have called it "Message-Oriented" instead. Erlang, for example, is a thoroughly object-oriented language which meets all of Dr. Kay's criteria without having any concept at all of "objects", "methods", "inheritance", "classes", "prototypes" or something like that. – Jörg W Mittag Sep 12 '12 at 10:03
  • @Jörg W Mittag: On the other hand a message does not make much sense without a sender and a receiver. – Giorgio Sep 12 '12 at 10:14
  • Any language in which you write foo.method() instead of method(foo), in all cases. Kind of a troll definition of OO, but I have not seen any other concrete definition. – Ricky Clarkson Sep 12 '12 at 17:33
  • @RickyClarkson Wouldn't your definition exclude Smalltalk, the prototypical OO language? – Andres F. Sep 13 '12 at 01:27
  • @AndresF. Smalltalk's syntax uses different punctuation but the same order. We can expand it to 'datum function' order instead of 'function datum' order. – Ricky Clarkson Sep 13 '12 at 01:35
  • @RickyClarkson I should clarify I wasn't talking about syntax. Java-like languages `obj.method()` isn't like Smalltalk's `obj message` from a behavior point of view, is it? In a way, Java's case is more like `method(obj)` with syntactic sugar... – Andres F. Sep 13 '12 at 01:38
  • @RickyClarkson syntactically your example fails if one creates a variation of C-- grammar and makes '.' char being part of identifier. Your definition tells me no info about semantics though. Is foo indeed an object? – Yauhen Yakimovich Sep 13 '12 at 01:49
  • 1
    This could be a nice illustration that syntaxes is not enough to define an OO language. If one can show that OOP (e.g. as a tool) is semantical only (syntaxes-independent), that changes (inverts) my question completely! – Yauhen Yakimovich Sep 13 '12 at 01:55
  • @AndresF. I've not used Smalltalk much, but I'm not sure what the difference you mentioned is. – Ricky Clarkson Sep 13 '12 at 05:32
  • 2
    @YauhenYakimovich This is one of the root problems in discussing OOP, everyone and his dog has their own idea of what it is. In contrast, structured programming and functional programming can each be defined very simply. This leads me to question whether OO has similar properties to religion instead of science. – Ricky Clarkson Sep 13 '12 at 05:36
  • @RickyClarkson I'm no Smalltalk expert either, btw, but I know `obj message` will "send" the message `message` to `obj`. This is always valid Smalltalk, regardless of whether `obj` knows what to do with this message. Contrast this with Java, where it is an _error_ to call `obj.method()` if `obj` doesn't support it! Because in one language it's illegal, and in the other it's perfectly reasonable code, this shows it's more than mere syntax. – Andres F. Sep 13 '12 at 12:22
  • @AndresF. What happens in Smalltalk if the object doesn't support the method? Do you get an exception or similar? If so, that difference is just the difference between typed and untyped languages. I'm using typed to mean "every expression and variable has a type". – Ricky Clarkson Sep 13 '12 at 13:28
  • 1
    @RickyClarkson I think it raises an exception, yes. However I'd say Smalltalk is _dynamically_ typed, not _untyped_ (there's a difference! Every expression and variable does have a type in Smalltalk!). It's also fundamentally different from Java: every object in Smalltalk can receive a message, but might answer "I don't know what to do". In contrast, in Java writing any method for any object is _illegal_ and definitely not part of the language! I'd say this is more than syntax, and germane to the search for a definition of OO. – Andres F. Sep 13 '12 at 13:43
  • @AndresF. If it raises an exception then it's just the untyped version of what Java does. If every expression and variable has a type in Smalltalk, what type is the variable i in the following? #( 1 2.0 3 4 5 ) collect: [:i | i * 2]. If you have to say 'when?' then the variable doesn't have a type. You might say the value has a type. – Ricky Clarkson Sep 13 '12 at 17:17
  • 1
    @RickyClarkson No, it's not untyped. [Smalltalk is dynamically typed](http://en.wikipedia.org/wiki/Smalltalk); its variables indeed have no types, but values do. That's doesn't make it an untyped language (read the definition on Wikipedia). It also makes the behavior of message passing _fundamentally_ different from Java. There is a category of programs you cannot write in Java (because they don't compile) which you can write in Smalltalk (and you can even write code to recover from "unhandled messages", so they are perfectly valid programs too). – Andres F. Sep 13 '12 at 17:45
  • @RickyClarkson The key point here is that `obj.method()` is not a good catch-all definition for OO languages, since it means something different in Java than in Smalltalk. "Different" in the sense that it can produce an illegal program in one language, but not in the other. I agree with **Yauhen** that a good definition must be about semantics, not syntax. – Andres F. Sep 13 '12 at 17:50
  • Possible duplicate of [Why is there no consistent definition of essential concepts to OOP?](http://programmers.stackexchange.com/questions/312296/why-is-there-no-consistent-definition-of-essential-concepts-to-oop) – gnat Sep 27 '16 at 10:57

5 Answers5

19

OO, according to Alan Kay is all about message passing, and that's it. You will see that qualities such as polymorphism and encapsulation are actually derived from message passing.

Now that stance is in fact very extreme, because it basically means that only Smalltalk and languages alike would qualify.

I think you can define OO as building your system on entities, that fully encapsulate their state, and that are rendered exchangeable due to their inherent polymorphous qualities. One could thus argue a purely OO language ensures these two core qualities are always met. What renders OO languages "impure" would be mechanisms that allow the creation of constructs that do not meet these criteria, such as the possibilities to:

  • declare public fields
  • declare variables that can only hold instances of a specific class and its subclasses (i.e. variables should be typed against interfaces, which is what the biological objects communicate through in Kay's anology), which is rendered even narrower if the class in question is final, as that leaves even less room for polymorphism
  • declare primitives

Then again, IMHO language purity is more a weakness than a strength. OO is not a silver bullet. No single paradigm is.

back2dos
  • 29,980
  • 3
  • 73
  • 114
  • 2
    +1 for "OO is not a silver bullet". – Andres F. Sep 12 '12 at 12:14
  • 1
    @AndresF. Note that practical value of OOP as well as other theoretical knowledge related to programming is not really a part of a question. It is pretty obvious that one can write code in a pretty successful manner w/o any deep understanding of programming techniques or theories (and the other way around). Neither the application properties of OO languages are discussed, etc. – Yauhen Yakimovich Sep 12 '12 at 20:14
  • @YauhenYakimovich Oh, I know. I wouldn't have upvoted the answer if it had been off-topic. Still, I liked an assertion I agree with. – Andres F. Sep 12 '12 at 20:28
  • @AndresF. Sure :-) "OO is not a silver bullet" is most likely true as well as us lacking a perfect programming language. But what exactly makes OOP not a silver bullet? Just as a good bug report I think detailed and precise terminology is the way to answer this. I have invested so much time in working with it that I am just damn curious to bring it to the next level. Is OOP just a bunch of ideas copy pasted from one programing book to another? – Yauhen Yakimovich Sep 12 '12 at 21:51
  • @back2dos +1 for explicitly pointing out the role of "message passing" according to Kay (Smalltalk, Objective-C). Apparently he never intended to see OOP developed towards directions it has today. But I really liked that Kay had those ideas to make objects NOT data (types). He really pushed to attribute them biological qualities, but ended up in "messaging". – Yauhen Yakimovich Sep 13 '12 at 00:27
  • @back2dos would you care to extend your list of elements that cancel property of OO "purity"? E.g. "declare primitives" is not very concrete to me. primitive data-types? immutables? constructs? – Yauhen Yakimovich Sep 13 '12 at 00:32
  • 1
    I'm not sure I agree with all your bullet points: “public fields” aren't a problem so long as they're syntactic sugar for some kind of property accessed via message passing, and whether the type system is involved in constraining what messages can be passed is orthogonal to the purity of the OO (provided the types are objects themselves, of course). But I think you're right about non-OO primitives (no matter how pragmatically useful they are). – Donal Fellows Sep 13 '12 at 08:27
  • I'd say purity is certainly a strength when learning a paradigm, I take your point for production though – jk. Jun 18 '13 at 07:46
6

I would approach this by defining it as a language which uses OOP constructs and nothing else (in the same way that a pure FP language uses pure functions with immutable data and nothing else).

In particular:

  • Every entity that your program operates on is a first class Object - i.e. no primitives, no pointers, no arrays etc.
  • The only thing you can do with an object is call a (potentially polymorphic) method on it (== sending a message). No other operations exist.
  • All data is encapsulated - i.e. no public field access, you must go via methods on an object
  • If you have first class functions then they must also be objects - so you would need to do something like functionObject.call(param1,param2)
  • No global variables - if you want something like this you would need to use an object to represent the current global environment, e.g. environment.getValue("myThing") or put the variable in a class object

Note that this still leaves quite a few options open:

  • Class-based vs. prototype-based object models
  • How inheritance is implemented (if at all)
  • Whether you have single or multiple dispatch on methods
  • Whether your objects are statically or dynamically typed
  • The exact syntax used for method calls (e.g. you could have some syntactic sugar for getters / setters etc.)
mikera
  • 20,617
  • 5
  • 75
  • 80
  • 1
    these are good definitions, but don't confuse object reality with mere syntax. Just because functions and global variables have a friendly syntax, they may actually be objects at heart. – ddyer Sep 12 '12 at 05:51
  • @ddyer - that's correct if it is truly just syntax, but I think that if the syntax also introduces different semantics then it can break the "pureness". For example, w.r.t. global variables the use of `globalVariableName` to access a global variable is a different semantic from a method call on an object, which would be the only way to access a non-local value in pure OOP. – mikera Sep 12 '12 at 07:09
  • I think "Everything" needs to be qualified. If a language has no reflective ability at all (for example, it can't reference a method of an object by an abstract name, or store it in a variable), then do methods need to be objects as well? Are references objects? Are references and objects even different things? – Joachim Sauer Sep 12 '12 at 08:31
  • @Joachim - good point. I qualified it as "every entity that your program operates on" in order to distinguish objects from meta-objects in the language like variable names and syntactic constructs. Obviously if your program actually operates on such things via reflection then they would need to be reified as real objects but that is not always going to be a requirement. Anyway, if you can think of a better qualification though then feel free to edit it in! – mikera Sep 12 '12 at 08:52
  • "Class-based vs. prototype-based object models": but I would say that in both cases you have some sort of classification, i.e. you group together objects with a common structure and behaviour. – Giorgio Sep 12 '12 at 09:59
  • This is a good list of "purist" features. However, if you find a language that matches all the mentioned features, it would still be no guarantee for object-orientated programs. –  Sep 12 '12 at 13:28
  • Indeed, OOP has much loosely formulated theoretical base compared to FP, which is almost one-to-one implementation of lambda calculus (e.g. LISP). OOP has never been motivated by a particular formalism, but instead it has grown with ideas in multiple directions. In academia - those ideas are driven by coming up with a logical system, in industry - by semi-formal, often incomplete, shallow and thus often misleading sets of "concepts" (redressed and relabeled into practices as UML, Design Patterns, etc.). I would be happy with definition that merges best of two worlds. – Yauhen Yakimovich Sep 12 '12 at 21:11
  • @mikera Can you think of different way of formulating high-order object classes, i.e. other then going from FP high-order functions as in http://dl.acm.org/citation.cfm?doid=209866.209867 ? – Yauhen Yakimovich Sep 13 '12 at 00:18
  • Are meta-classes high-order object classes? :-) – Yauhen Yakimovich Sep 13 '12 at 01:09
4

The discussion about so-called OO languages has always been a bit on the brain-washed side. Ie:

"Someone has told me that language X is OO, so therefore language X equals OO then every language that lacks the features of language X cannot possibly be OO. And because I'm writing my code in language X, everything I do is OO."

The term object-oriented design boils down to 3 things:

  1. Modular design with autonomous objects that don't know needless information about the rest of the program, aka as loose coupling as possible.
  2. Encapsulation of data inside objects to prevent external access, both intentional and accidental.
  3. Clearly specified dependencies between objects. To achieve loose coupling, but also to make the program easier to maintain and expand.

1) is pure program design, it can be achieved in any programming language. However, some languages have helpful features such as class/struct and private keywords.

2) is mainly program design, though cannot be fully achieved without language support, since you need language mechanisms like private/static to protect against accidental use.

3) is mainly program design. There are typically three different dependencies: "object X contains object Y", "object X is a kind of Y" and "object X interacts with object Y". There are plenty of language features to help with these dependencies: inheritance/polymorphism, abstract base classes and so on.

Now, if we look at the above we can see that you barely need any language features to write OO programs. The features just make it far easier.

The above goals cannot be achieved by using some muddy backwards-logic: just because you use the class keyword, your program does not automatically get a modular design. Just because you use inheritance, it doesn't automatically mean that your object dependencies make sense. A language with OO features would still allow things like class TheWholeBloodyProgram or "Animal inherits Cat".

Sadly, the topic of good object-oriented program design is rarely mentioned in these kind of discussions. Brainwashed programmers only look at the syntax and yap things like for example "C++ has primitive data types so your C++ program isn't OO", then they go off to write a downright horrible program in their own favourite language, without using any hint of program design what-so-ever.

To answer the question: very few, if any languages have support for proper OO program design. To find out which languages that has certain OO-related features is irrelevant as long as the programmer doesn't know what object-oriented design means. A programmer claiming that certain languages are object-oriented has most likely not grasped the concept of OO as whole. Ask the would-be OO programmer how they design OO programs. If the first thing they do is to start yelling language keywords, then you can safely assume they don't know OO design.

Perhaps there exists some fancy high-level UML-ish tool far above the raw source code, which enforces the programmer to only write programs with good object-oriented design, but I doubt it. The best design tools for OO programming is most likely still the human brain and common sense.

  • Can you clarify how your definition differs from, e.g. modular programming with abstract data types? I think you are on the right track, but I cannot see the train yet! – Jörg W Mittag Sep 12 '12 at 14:24
  • @JörgWMittag It isn't necessarily different, traditional ADT:s can be written using object-oriented design, with proper encapsulation, setters/getters, ways to inherit it etc etc. But they can also be written without regards to OO design. --> –  Sep 12 '12 at 15:43
  • 2
    @JörgWMittag If you have a language like C for example, with limited language support for OO, then it is tricky to write ADT:s in an object-oriented manner. The most common mistake is to leave the allocation of the ADT to the caller, ie give them a public struct with all of the internals exposed, breaking encapsulation. The proper way to do this in C is through so-called "opaque types" (incomplete types), though not many C programmers know to use them. –  Sep 12 '12 at 15:44
  • @Lundin: In the paper posted by JörgWMittag as a comment to another answer there is an (IMO) interesting comparison between ADT and OO. – Giorgio Sep 12 '12 at 18:55
  • I remember from some UML books (probably) an additional point 0. Abstractness (stressing the importance of abstract formulation essential for inter-object relationships as polymorphism, inheritance, aggregation, etc.). – Yauhen Yakimovich Sep 12 '12 at 23:51
  • Is 1. a strong requirement? Seems to be a mixture of Modular programming, Component programming, design patterns, UML and something else. Not sure. Maybe consider to paraphrase? In discussion of (1) you are definitely talking about C++ and languages influenced by it. In that case "private" as visibility keyword corresponds to encapsulation (2), right? Also confused by struct/class point. – Yauhen Yakimovich Sep 13 '12 at 00:03
  • @Ludin (regarding first comment to @JörgWMittag) yes if it is possible to draw a clear line or identify clear origin of ideas it is better to distinguish concepts form different paradigms, even if they can be included embodied in OOP. – Yauhen Yakimovich Sep 13 '12 at 00:08
  • @Lundin do you consider UML a good OOP formalism? Or do you feel there is enough space for shorter and simpler. UML is really abort designing, i.e. generating "interfaces" and describing communication between objects. IMO UML hardly cares/suitable about "purity" or stronger OO properties of the language. – Yauhen Yakimovich Sep 13 '12 at 00:13
  • @YauhenYakimovich Modular design with autonomous objects is indeed a very strong requirement. There is plenty of computer science research showing that tight coupling leads to more bugs and more severe bugs. There is also a direct relation between the number of bugs and program complexity. In addition, modular design makes it easier to maintain and expand the program. So I would say that 1) is most likely one of the most important aspects of program design. –  Sep 13 '12 at 08:08
  • @YauhenYakimovich Regarding UML, I hate it. But the good thing with UML is that it forces you to at least have _some_ sort of design, and it forces you to sit down and think about the design before you start coding. The programmer should consider what objects there are, which objects that make sense, but most importantly the dependencies between them. It should be made perfectly clear which object that is responsible for what. –  Sep 13 '12 at 08:19
  • I think what it all boils down to is programming experience. Program design is perhaps the most qualified programming task of them all. No matter how many nice OO features your language has got, no matter how many paper piles of UML you produce, no matter how many agile waterfall buzzwords you throw around, they will not make your design good by themselves. At best they will give you nudges in the right direction. Sometimes they will even trick you to do bad design. Just as in any other trade, there are no magic shortcuts towards becoming a good programmer. –  Sep 13 '12 at 08:30
  • System architecture design — i.e., the identification of what programs need to exist, what information needs to flow between them, and what format that information flows in — is above and beyond program design. (Why do I say this? Because if you screw it up, no amount of clever datastructures and algorithms will fix it.) – Donal Fellows Jun 18 '13 at 10:14
2

No, there is no formal or even useful definition, and there never will be. To some people, OOP means "Universal base class" and "Must use reference semantics, best with a garbage collector"- and you can even get quibbles about syntax, one of the least relevant things ever invented.

Ultimately, first, you have to answer the question "What is an object?". The more narrow-minded will insist on inheriting from some pointless universal base class and needlessly being allocated on a garbage collector to qualify. But I prefer a much more useful definition. The purpose of OOP is to have some data, and some functions you can call on that data. So

  • An object holds some state and offers some functions on that state.

In this case, even int qualifies. After all, when you write template code in C++ which can accept either primitives or objects, then it becomes difficult to argue that primitives are different in any substantial way. There's nothing meaningfully different about Vector v1, v2; v1 + v2; instead of int v1, v2; v1 + v2; (except the crappy initialization semantics, one must admit). Also, this permits lambdas and such things to be objects, as they hold state- their captures- and offer a function on that state, to call the lambda.

Fortunately, we can also classify pointers to free functions as objects, since they both hold state (an address) and a function on that state (to call it). So a free function should be allowed- even if you were to say that all free functions are in fact global function pointers.

DeadMG
  • 36,794
  • 8
  • 70
  • 139
  • One important idea of object-orientation is that objects have an identity. Integers do not have an identity because e.g. you cannot distinguish two integer **objects** with value 2: there is only one integer number with value 2. – Giorgio Sep 12 '12 at 09:55
  • 2
    I see no need for such a distinction. But secondly, they have the same identity that any other object has- address/reference comparison. The fact that you cannot tell apart two objects with the same state, except by comparing addresses, is far from new and applies to all objects. – DeadMG Sep 12 '12 at 09:57
  • 5
    -1. Starts off with a useless and unnecessary rant, shortly switches to ad hominem attack and the only thing even remotely factual (the definition of *OOP*) is wrong. Please read [*On Understanding Data Abstraction, Revisited*](http://CS.UTexas.Edu/~wcook/Drafts/2009/essay.pdf) by [William R. Cook](http://WCook.BlogSpot.Com/) for the difference between an Abstract Data Type and an Object. – Jörg W Mittag Sep 12 '12 at 09:59
  • 1
    "I see no need for such a distinction.": But this distinction is among the commonly-accepted features of objects. Of course, you can develop your own notion of an object which is different from what is commonly accepted. You are totally free to do it. – Giorgio Sep 12 '12 at 10:03
  • "The fact that you cannot tell apart two objects with the same state, except by comparing addresses, is far from new and applies to all objects.": There is a different between two objects being actually **the same object** as expressed e.g. by the Java == operator on object references, and two objects being equal in some business domain sense (e.g. because all their attributes are equal), as expressed in Java by the equal method. – Giorgio Sep 12 '12 at 10:08
  • "“procedural data values” (objects) facilitate adding new representations." I can exactly do this with a template for any of the primitive integer classes, and it is in fact very common to do so for pointers. – DeadMG Sep 12 '12 at 10:13
  • @Giorgio: Indeed. But a primitive integer supports both those operations. `==` in Java being `&i1 == &i2`, and `.equals()` being `==`. Of course, the paper that Jorg Mittag *just linked* also bans reference-equality comparisons from pure OOP. – DeadMG Sep 12 '12 at 10:14
  • 1
    @Giorgio Nonsense, where is that an important idea of OOP? I’ve never heard nor read of such a requirement and it doesn’t seem very useful. That said, C++ readily fulfils this since the definition of “object” in C++ is something which is uniquely identified by an address in memory. There you go. – Konrad Rudolph Sep 12 '12 at 11:56
  • 2
    @Jörg I beg to differ. I don’t agree entirely with this post but calling the caveat in the first paragraph “useless” or a “rant” is disingenuous. There is no universally agreed on definition for OOP. That is a simple, and widely acknowledged, fact. The rest of the post is *a* definition of OOP. Certainly not the most widely used, nor the one I’d give, but, as DeadMG said, actually quite a useful one. – Konrad Rudolph Sep 12 '12 at 11:57
  • 2
    @KonradRudolph: that paragraph read very different when I wrote my comment, including comparing programmers who care about syntax to racists, even mentioning a specific user of this site by name. – Jörg W Mittag Sep 12 '12 at 14:09
  • @Konrad Rudolph: Well, it is not my idea, I just cited from a classic text book on object orientation: Object-Oriented Modeling and Design. Rumbaugh and others. Prentice Hall, ISBN 0-13-629841-9. The book cites identity, classification, polymorphism, and inheritance as four commonly accepted aspects of object orientation. Since Rumbaugh is (among other things) one of the inventors of UML I thought he should be a quite authoritative source. But maybe what he wrote is just nonsense. – Giorgio Sep 12 '12 at 14:36
  • @Konrad Rudolph: Anyway, the way I understand this is more from a business domain point of view. For example, two twins, even though they look the same, are two distinct entities (with a different identity). Similarly, two printers of the same model are two distinct entities / objects. I guess this is the basic idea. How you implement this in C++, Java or in a database mapping is actually just implementation details. Also note: two C++ objects existing in memory may refer to the same business object. In a database you normally use an extra primary key column to identify each object uniquely. – Giorgio Sep 12 '12 at 14:40
  • @Jorg: I realized that paragraph came off a lot worse than I had intended it, so I replaced it. – DeadMG Sep 12 '12 at 14:48
  • @Jörg Ah sorry, I should have looked at the history. – Konrad Rudolph Sep 12 '12 at 14:56
  • @Konrad Rudolph: Also, I did not want to say that C++ does not support object identity (and therefore C++ lacks a key object-oriented feature): as you pointed out, using the memory address of an object is a possibility. – Giorgio Sep 12 '12 at 18:59
0

You can think of it by negative example. Java is not a pure object oriented language because there are also primitive types that are not objects. These are integers, doubles, arrays and so on. In a pure object language, the semantics of objects are available for everything.

There's also the question of how much of the language is closed to modification, even within the object framework. In java you can't define new subclasses for some classes, such as String or Class.

Which languages are pure? The only candidate that comes to mind is smalltalk.

ddyer
  • 4,060
  • 15
  • 18