Messages

Going back to Alan Kay’s definition, one of the fundamental aspects of object-oriented programming is message passing. Translated to today’s languages, we could say that:

When object A wants object B to run one of its methods, object A sends a message to object B to make that happen.

A message is made up of the name of the method we want to call and its parameters, both input and output. The parameters define the method’s signature and, if we’re talking about “pure” object-oriented programming, the parameters are also objects themselves.

Keep in mind that in C# (and in other languages) this doesn’t hold 100% because we don’t limit ourselves to calling methods that we pass objects to as parameters:

  • We can use data structures as method parameters.
  • We can send messages through other “sugared” mechanisms, such as events.
  • We have properties, which are basically more “sugar” for dealing with “Getter” and “Setter” methods.

But in the end they’re still messages, even if they’re used in an alternative way to express a different use depending on the kind of message.

Kinds of messages

Looking at the intent of the message, we can come up with a fairly simple classification:

  • Informative messages are used to report something that happened in the past. We usually call them events.
  • We also have interrogative messages, which are basically the ones we use to ask the object for some kind of information. The get of a property or any GetXXX() method would be an example.
  • We use imperative messages to give orders to the object. They’d be the equivalent of running commands against the object.

Depending on the kind of messages we use, we can control the flow of execution one way or another.

Taking messages beyond the paradigm

Although we’ve been talking about methods, properties and events, if we take the conceptual side we can explore other interpretations on existing languages, opening up lots of possibilities for the flow of execution, such as using event/message/command buses, mediators, the actor model, etc. Although we could say this already goes beyond the object-oriented paradigm itself and gets us into patterns, execution models and other parties.

For now I’ll stop here with messages, because it’s a topic we’ll get more out of in later posts, after covering topics like polymorphism.

Classes

I’m going to say very little about classes because I think it’s a well-worn topic. I’m only mentioning it to at least lay the groundwork for the concepts that come next, since all of them revolve around the class. If we were talking about other languages, talking about classes might even be unnecessary. But I’m using C# as the reference language, so here it makes all the sense in the world.

We use classes to define the “blueprints” needed to build our objects. Through them we’ll design our objects, trying to apply encapsulation wisely (not always :P), defining the right data structures and the catalog of messages we can use to communicate with our objects.

Taking the quick definition from the previous post, the class is the tool we use to draw the perimeter and give it a name ;)

Sometimes the concept of a class gets confused with that of an object. Classes aren’t objects. We use the new operator on the class to create an instance of it. That instance is the object.

Inheritance

The cover image comes from the Petabridge website