I am just wondering, what exactly are the features a language or a library must provide in order for it to be defined as 'Object Oriented'. Is Object Orientation something that can, more or less, be achieved in any general-purpose programming language with decent features? Or is it something that can only be achieved in languages that specifically advertise that they support Object Oriented Programming?

For example, look at the following C code:

SDL_Surface* screen = SDL_SetVideoMode( 640, 480, 16, SDL_HWSURFACE);
SDL_FreeSurface( screen );

or the code discussed here.

Now the above code does not use inheritance , runtime-polymorphism ( ? ) , virtual functions etc. But it seems pretty much OOP to me.

Is Object-Orientation simply writing code which is based on creatable and destructable data structures such as objects, classes, structs etc. which does not require on any special pattern or features provided by the Programming Language or a library ?

  • 2
    OOP generally requires objects. However it's possible to write code that looks OOP in most languages (I doubt you can say "this assembly looks OOP")
    – Raynos
    Commented Jan 31, 2012 at 9:56
  • The above code does not use an if statement or a loop. It doesn't use multiplication or addition. You can't use two lines of code, and a list of things not shown, to make any judgement at all. From those two lines of code, I could deduce that it's a strictly lazy functional programming language, not an OO language. Using two lines of code as part of a generalization is not a real question.
    – S.Lott
    Commented Jan 31, 2012 at 10:43
  • The link is also included in the above code which I judged upon. Also note that it is not a judgement, I'm asking you whether this could be considered OOP. Commented Jan 31, 2012 at 10:46
  • The trivial answer is yes. My point is this. You can't -- from code examples -- make a judgement about OOP. It's a trivial matter of definition. Either the language is defined as an OOP language or it isn't. Any given code samples may not require all OOP features. Indeed, OOP code can use very, very few features. In Python, for example, 1+2 really is Object-Oriented. It is a constructor that builds a new object from two existing objects. Using code samples reveals nothing.
    – S.Lott
    Commented Jan 31, 2012 at 11:01
  • What's wrong with using this definition and comparing that with the language (not two code samples)? en.wikipedia.org/wiki/…
    – S.Lott
    Commented Jan 31, 2012 at 11:04

7 Answers 7


According to Alan Kay, who invented the term "object oriented",

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.

Messaging (as implemented in Smalltalk) is a comparable concept to polymorphism, but rather more powerful (at least than the kind of polymorphism supported by C++ or Java). It can be done in all languages, but is rather painful if not supported directly by the language. Basically it means objects can send each other messages containing anything, amd can react however they want to messages they receive. To fully support messaging, there must be a way for objects to react flexibly to messages without enumerating them in the source code (which is basically what method/function definitions do).

local retention and protection and hiding of state-process - AKA encapsulation - can be done by convention in all languages, but that's cheating somewhat. Local retention on the language level actually seems to be the one feature all languages that claim to be OO (and many that don't) share - there's generally a way to create compound datatypes with multiple instances. The protection and hiding, on the other hand, is often only done by convention.

late-binding of all things - a sliding scale on which C is really far away from Kay's vision (As is C++, while Java is much closer). Can be faked (see COM), but that will be a pain to use.

Note how Kay does not mention inheritance. In the same email he wrote

I didn't like the way Simula I or Simula 67 did inheritance (though I thought Nygaard and Dahl were just tremendous thinkers and designers). So I decided to leave out inheritance as a built-in feature until I understood it better

  • 4
    Exactly how are Java and C# closer to late-binding than C++? Commented Jan 31, 2012 at 12:03
  • @FredOverflow: Java lazily loads class definitions at runtime when they are first used, and does so implicitly via an extremely flexible mechanism that easily allows adding new classes or even generating them on the fly. C++ requires you to relink your executable or explicitly load libraries. The situation with C# seems to be less clear than I thought, so I removed the reference to ti. Commented Jan 31, 2012 at 12:56

Object-oriented programming is not about syntax features, it's a coding and design philosphy. At its core stands the concept of an object, which is a construct that groups state with routines to act upon it (or, depending on your point of view, responses to messages). The other important aspect of OOP is encapsulation: wrapping implementation details into opaque structures and connecting them through well-defined interfaces. Pretty much everything else in OOP theory goes back to these two fundamentals.

So, any language that can somehow model objects (entities that contain both data and code) and encapsulation can be used to do OOP. For example, in C you can use function pointers to store functions in structs, and you can use the header / source file system to realize encapsulation. It's not convenient, but it is enough to do OOP. You can probably even bend something like Haskell or ML into doing OOP, and I wouldn't be surprised if someone could come up with a way of doing OOP in assembly.

Practically speaking, though, a language can be called 'object-oriented' if it provides a complete set of syntax features for explicit object-oriented programming. Typically, this means that such a language should have: * a notion of an object * a notion of method calling or message passing * a comfortable and straightforward way of controlling access to object members * a comfortable and straightforward way of defining interfaces

Consequently, I'd call a piece of code object-oriented if it adheres to OOP principles and uses the available OOP syntax.

BTW., your code example probably does use polymorphism and virtual functions, although the C syntax doesn't make it obvious. I'm not an expert on SDL, but I'd expect an SDL_surface to be able to represent various different types of surfaces, each with its own specific set of implementations - blitting something onto a memory bitmap and blitting to a screen surface requires radically different code, but the interface (the functions that take an SDL_surface* as an argument) remains the same. Just like that, it also implements encapsulation: you can't access a surface's underlying representation directly, you have to go through functions that know how to handle an SDL_surface, because that's all you have. It's a nice example of how you'd do OOP in C.

  • Abstract Data Types, data modeling and encapsulation are not unique to OO, though (as you briefly mention yourself). I would prefer to describe OO based on its more unique features (dynamic binding of method calls, polymorphism via said method calls, etc)
    – hugomg
    Commented Jan 31, 2012 at 14:15

My understanding of OO is that OO is a way of thinking and an implementation that is based on the idea that a computational task can be achieved by one worker(object) or by collaboration of individual workers (objects) via message passing between those workers(objects) at run-time. This run-time behavior requires solid static, and dynamic constructs to enable it.

The specific syntax to implement OO is not the key that determines whether a language is an OO or not. For example, Smalltalk and C# have different syntaxes but both are OO languages (to a varying degrees). The key is whether the given language preserves the philosophy (above) and provides the implantation means required.


When I was a student I was taught that object-oriented programming stands on three pillars:

  • encapsulation,
  • polymorphism, and
  • inheritance.

A language will have to support those features in order to be considered an object-oriented language.

Note that this describes a set of features, rather than syntax. Hence, whether you have to write

type obj; // or type obj = new type;


type* ptr = create_type();
func(ptr, arg); 

doesn't matter.

So you can indeed program according to the object-oriented paradigm in C. But the language offers no support for this, which makes it a rather painful exercise. This is why C is not considered an object-oriented language.

  • 2
    Teaching these "pillars" has probably done more harm than good to the world. Encapsulation is good, but that's about it.
    – tdammers
    Commented Jan 31, 2012 at 11:01
  • 1
    They're in this list, so they seem to be widely accepted: en.wikipedia.org/wiki/…
    – S.Lott
    Commented Jan 31, 2012 at 11:05
  • Can you explain why Polymorphism and Inherritance are bad?
    – MathAttack
    Commented Jan 31, 2012 at 12:05
  • @MathAttack: Are you talking to me? Because I certainly didn't said so.
    – sbi
    Commented Jan 31, 2012 at 12:12
  • 1
    @missingno: Something does not have to be unique to some paradigm to be deemed important to distinguish the paradigm. Encapsulation does no more have to be unique to OOP as functions have to be unique to structured programming.
    – sbi
    Commented Jan 31, 2012 at 15:07

You can do OO in any decent general-purpose language.

It's easier to do it in an "OO" language, because you have idiomatic constructs available and don't have to resort to something like OO in C - which is possible, but horrible.

Whether the OO constructs are provided by the language itself, by its standard library, or by some other library, doesn't matter much, as some languages (e.g. Scala) allow libraries to add language constructs so that from the programmer's viewpoint it's almost impossible to distinguish which things are provided by the core language and which by a library.


If you look at the range of languages which have been widely accepted as OO and those who haven't, the test seems to be the support for inclusion polymorphism (aka sub-type polymorphism, but inclusion polymorphism is the term used by Cardelli in the paper which introduced me, and I think quite a lot of others, to a classification of kinds of polymorphism). I.E. the possibility for some variables to have values of different types and the possibility for some calls to dispatch to different routines depending on the type of one or several values. Everything else has been present in languages not accepted as OO or been missing from languages well accepted as OO.

The two major other characteristics associated with OO languages have been provided by non OO languages:

  • Encapsulation is quite well provided by Ada83;
  • Inheritance is provided by Oberon (Oberon is interesting, Wirth wanted to provide an OO language with as less cruft as possible, but had to revisite his conception to get one -- Oberon-2 is OO).

Object orientation is defined as

also check out wikipedia entries. those are the features a language must provide for it to be defined as object oriented.

consider your code object oriented if it is in a object oriented programming language. even if you write something that appears to be procedural it will be acting upon methods in objects from classes using polymorphism via encapsulation [maybe] :)

regarding your last question the answer is probably. yes. object oriented is basically just acting on methods on objects and passing around those objects as parameters.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.