What makes a language Object-Oriented?

StackOverflow https://stackoverflow.com/questions/29099

Question

Since debate without meaningful terms is meaningless, I figured I would point at the elephant in the room and ask: What exactly makes a language "object-oriented"? I'm not looking for a textbook answer here, but one based on your experiences with OO languages that work well in your domain, whatever it may be.

A related question that might help to answer first is: What is the archetype of object-oriented languages and why?

Was it helpful?

Solution

Definitions for Object-Orientation are of course a huge can of worms, but here are my 2 cents:

To me, Object-Orientation is all about objects that collaborate by sending messages. That is, to me, the single most important trait of an object-oriented language.

If I had to put up an ordered list of all the features that an object-oriented language must have, it would look like this:

  1. Objects sending messages to other objects
  2. Everything is an Object
  3. Late Binding
  4. Subtype Polymorphism
  5. Inheritance or something similarly expressive, like Delegation
  6. Encapsulation
  7. Information Hiding
  8. Abstraction

Obviously, this list is very controversial, since it excludes a great variety of languages that are widely regarded as object-oriented, such as Java, C# and C++, all of which violate points 1, 2 and 3. However, there is no doubt that those languages allow for object-oriented programming (but so does C) and even facilitate it (which C doesn't). So, I have come to call languages that satisfy those requirements "purely object-oriented".

As archetypical object-oriented languages I would name Self and Newspeak.

Both satisfy the above-mentioned requirements. Both are inspired by and successors to Smalltalk, and both actually manage to be "more OO" in some sense. The things that I like about Self and Newspeak are that both take the message sending paradigm to the extreme (Newspeak even more so than Self).

In Newspeak, everything is a message send. There are no instance variables, no fields, no attributes, no constants, no class names. They are all emulated by using getters and setters.

In Self, there are no classes, only objects. This emphasizes, what OO is really about: objects, not classes.

OTHER TIPS

According to Booch, the following elements: Major:

  • Abstraction
  • Encapsulation
  • Modularity
  • Hierarchy (Inheritance)

Minor:

  • Typing
  • Concurrency
  • Persistence

Basically Object Oriented really boils down to "message passing"

In a procedural language, I call a function like this :

  f(x)

And the name f is probably bound to a particular block of code at compile time. (Unless this is a procedural language with higher order functions or pointers to functions, but lets ignore that possibility for a second.) So this line of code can only mean one unambiguous thing.

In an object oriented language I pass a message to an object, perhaps like this :

 o.m(x)

In this case. m is not the name of a block of code, but a "method selector" and which block of code gets called actually depends on the object o in some way. This line of code is more ambiguous or general because it can mean different things in different situations, depending on o.

In the majority of OO languages, the object o has a "class", and the class determines which block of code is called. In a couple of OO languages (most famously, Javascript) o doesn't have a class, but has methods directly attached to it at runtime, or has inherited them from a prototype.

My demarcation is that neither classes nor inheritance are necessary for a language to be OO. But this polymorphic handling of messages is essential.

Although you can fake this with function pointers in say C, that's not sufficient for C to be called an OO language, because you're going to have to implement your own infrastructure. You can do that, and a OO style is possible, but the language hasn't given it to you.

It's not really the languages that are OO, it's the code.

It is possible to write object-oriented C code (with structs and even function pointer members, if you wish) and I have seen some pretty good examples of it. (Quake 2/3 SDK comes to mind.) It is also definitely possible to write procedural (i.e. non-OO) code in C++.

Given that, I'd say it's the language's support for writing good OO code that makes it an "Object Oriented Language." I would never bother with using function pointer members in structs in C, for example, for what would be ordinary member functions; therefore I will say that C is not an OO language.

(Expanding on this, one could say that Python is not object oriented, either, with the mandatory "self" reference on every step and constructors called init, whatnot; but that's a Religious Discussion.)

Smalltalk is usually considered the archetypal OO language, although Simula is often cited as the first OO language.

Current OO languages can be loosely categorized by which language they borrow the most concepts from:

  • Smalltalk-like: Ruby, Objective-C
  • Simula-like: C++, Object Pascal, Java, C#

As far as I can tell, the main view of what makes a language "Object Oriented" is supporting the idea of grouping data, and methods that work on that data, which is generally achieved through classes, modules, inheritance, polymorphism, etc.

See this discussion for an overview of what people think (thought?) Object-Orientation means.

As for the "archetypal" OO language - that is indeed Smalltalk, as Kristopher pointed out.

Supports classes, methods, attributes, encapsulation, data hiding, inheritance, polymorphism, abstraction...?

Disregarding the theoretical implications, it seems to be

"Any language that has a keyword called 'class'" :-P

To further what aib said, I would say that a language isn't really object oriented unless the standard libraries that are available are object oriented. The biggest example of this is PHP. Although it supports all the standard object oriented concepts, the fact that such a large percentage of the standard libraries aren't object oriented means that it's almost impossible to write your code in an object oriented way.

It doesn't matter that they are introducing namespaces if all the standard libraries still require you to prefix all your function calls with stuff like mysql_ and pgsql_, when in a language that supported namespaces in the actual API, you could get rid of functions with mysql_ and have just a simple "include system.db.mysql.*" at the top of your file so that it would know where those things came from.

when you can make classes, it is object-oriented
for example : java is object-oriented, javascript is not, and c++ looks like some kind of "object-curious" language

In my experience, languages are not object-oriented, code is.

A few years ago I was writing a suite of programs in AppleScript, which doesn't really enforce any object-oriented features, when I started to grok OO. It's clumsy to write Objects in AppleScript, although it is possible to create classes, constructors, and so forth if you take the time to figure out how.

The language was the correct language for the domain: getting different programs on the Macintosh to work together to accomplish some automatic tasks based on input files. Taking the trouble to self-enforce an object-oriented style was the correct programming choice because it resulted in code that was easier to trouble-shoot, test, and understand.

The feature that I noticed the most in changing that code over from procedural to OO was encapsulation: both of properties and method calls.

Simples:(compare insurance character)

1-Polymorphism 2-Inheritance 3-Encapsulation 4-Re-use. :)

Object: An object is a repository of data. For example, if MyList is a ShoppingList object, MyList might record your shopping list.

Class: A class is a type of object. Many objects of the same class might exist; for instance, MyList and YourList may both be ShoppingList objects.

Method: A procedure or function that operates on an object or a class. A method is associated with a particular class. For instance, addItem might be a method that adds an item to any ShoppingList object. Sometimes a method is associated with a family of classes. For instance, addItem might operate on any List, of which a ShoppingList is just one type.

Inheritance: A class may inherit properties from a more general class. For example, the ShoppingList class inherits from the List class the property of storing a sequence of items.

Polymorphism: The ability to have one method call work on several different classes of objects, even if those classes need different implementations of the method call. For example, one line of code might be able to call the "addItem" method on every kind of List, even though adding an item to a ShoppingList is completely different from adding an item to a ShoppingCart.

Object-Oriented: Each object knows its own class and which methods manipulate objects in that class. Each ShoppingList and each ShoppingCart knows which implementation of addItem applies to it.

In this list, the one thing that truly distinguishes object-oriented languages from procedural languages (C, Fortran, Basic, Pascal) is polymorphism.

Source: https://www.youtube.com/watch?v=mFPmKGIrQs4&list=PL-XXv-cvA_iAlnI-BQr9hjqADPBtujFJd

I am happy to share this with you guys, it was quite interesting and helpful to me. This is an extract from a 1994 Rolling Stone interview where Steve (not a programmer) explains OOP in simple terms.

Jeff Goodell: Would you explain, in simple terms, exactly what object-oriented software is?

Steve Jobs: Objects are like people. They’re living, breathing things that have knowledge inside them about how to do things and have memory inside them so they can remember things. And rather than interacting with them at a very low level, you interact with them at a very high level of abstraction, like we’re doing right here.

Here’s an example: If I’m your laundry object, you can give me your dirty clothes and send me a message that says, “Can you get my clothes laundered, please.” I happen to know where the best laundry place in San Francisco is. And I speak English, and I have dollars in my pockets. So I go out and hail a taxicab and tell the driver to take me to this place in San Francisco. I go get your clothes laundered, I jump back in the cab, I get back here. I give you your clean clothes and say, “Here are your clean clothes.”

You have no idea how I did that. You have no knowledge of the laundry place. Maybe you speak French, and you can’t even hail a taxi. You can’t pay for one, you don’t have dollars in your pocket. Yet, I knew how to do all of that. And you didn’t have to know any of it. All that complexity was hidden inside of me, and we were able to interact at a very high level of abstraction. That’s what objects are. They encapsulate complexity, and the interfaces to that complexity are high level.

Archetype

The ability to express real-world scenarios in code.

foreach(House house in location.Houses)
{
 foreach(Deliverable mail in new Mailbag(new Deliverable[]
              {
              GetLetters(), 
              GetPackages(), 
              GetAdvertisingJunk()
              })
 {
    if(mail.AddressedTo(house))
    {
        house.Deliver(mail);
    }
 }
}

-

foreach(Deliverable myMail in GetMail())
{
    IReadable readable = myMail as IReadable;
    if ( readable != null )
    {
        Console.WriteLine(readable.Text);
    }
}

Why?

To help us understand this more easily. It makes better sense in our heads and if implemented correctly makes the code more efficient, re-usable and reduces repetition.

To achieve this you need:

  • Pointers/References to ensure that this == this and this != that.
  • Classes to point to (e.g. Arm) that store data (int hairyness) and operations (Throw(IThrowable))
  • Polymorphism (Inheritance and/or Interfaces) to treat specific objects in a generic fashion so you can read books as well as graffiti on the wall (both implement IReadable)
  • Encapsulation because an apple doesn't expose an Atoms[] property
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top