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.

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

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.

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.

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.