In his well-reasoned blog post, [chuck hoffman argues][ch] that what are normally called object-oriented programming languages should probably more rightly be called class-oriented languages. The distinction hopefully becomes clear when you consider this example.

[ch]: http://nothinghappens.net/?p=214

You are modelling people, and you want to create a person type. You should be able to strike up a conversation, so we want a ‘greet’ method for each. Our people (Alice, Bert, Charlie, and Dennis) all respond differently;

– Alice responds to a greeting with “Hi!”, or a surly “what!?” if she hasn’t had her morning coffee.
– Bert responds with either “don’t bother me, I’m walking Spot” or “what can I do for you?”, depending on whether he is walking his dog.
– Charlie responds with either “good morning”, “good afternoon”, or “good evening”, depending on the time of day.
– Dennis responds with “Hello, world!”

Now, in C#, that’s really tricky. Each person uses a different function to answer your greeting. But in C#, the Person class can only have one implementation. You could munge them all together;

class Person
{
string Greet()
{
if (isBert && isWalkingSpot) {return “don’t bother me, I’m walking Spot”; }
else if (isAlice && !hasHadCoffee) { return “what!?”; }
… etc
}
}

But that is monstrous. You could create subclasses;

class Dennis: Person
{
public override string Greet() { return “Hello, World!”; }
}

But this isn’t a class of thing; Dennis is singular. There’s not a whole class of Dennises, just a single solitary one.

What you really want to be able to do is something like this; (excuse the made-up syntax)

Person Alice = new Person();
Alice.HasCoffee = false;
Alice.Greet = { (HasCoffee ? “Hi!” : “what!?”) }

Person Dennis = new Person();
Dennis.Greet = { “Hello, World” };

That’s what an object-oriented, rather than a class-oriented, version of c# might look like.