(my catch on) Object-oriented programming methodologies

what's real and what's hype

Writing code in an object-oriented language does not make the code object-oriented. The object-oriented approach is a way of analyzing a problem and designing a solution, and of writing code that clearly and efficiently describes the problem and solution. The languages do not do this for you: they only make it easier and more natural.

When done remotely right, this code can in fact be much easier to maintain and extend. Code is in fact much easier to re-use.

It is often claimed that code written in object-oriented languages is slow. This is hogwash. If somebody says this to you, they are not to be trusted on any topic relating to computers. The truth is, the speed of the program mostly depends on the programmer's abilities. Programmers can make the fastest computer work like a slug.

In the particular case of C vs C++, the deal is: the same compiler is typically used for both. Most code that works in C also works in C++ with no alteration, and the compiler produces precisely the same program, and it runs at the same speed.

On the other hand, the greatest gains to be made in program speed tend to come at the algorithmic level; well designed code can provide a "level of indirection" that facilitates replacement of and experimentation with algorithms. Competent programmers can build in such a level of indirection, and object-oriented programming gives several more ways to accomplish that.

history

complexity ceilings

kinds of things

In everyday life, we normally speak of kinds of things, which interact with other things according to their respective kinds. In object-oriented methodologies, the notion of a "kind" of thing is dealt with directly: it is called a "class", and a "thing of a given kind" is called an "object of a given class". Object-oriented programming languages have syntax for describing the relations and interactions of objects of one class with objects of other classes.

effect on code

Well designed object-oriented code is structured very differently from conventional code.

A remark often made by conventional programmers on their first acquaintance with good object-oriented code is: "I can't find the code—it's all type declarations".

In conventional code, the only actor is the program. In order to do different things, the code "switches modes": "first I am in the mode of doing this. In this situation, I go into the mode of doing something else."

In the object-oriented view, the code describes different sets of objects, which may all be actors, each behaving according to what they are. Most of the code describes how one kind of object relates to and interacts with other objects. Often the interactions involve very little code. The spaghetti of "modal programming" is absorbed into the structure of relationships between kinds of objects.

So object-oriented code isn't all type declarations. Typically, there are a few lines in each method. The lines will say something like, "when I am created, I also create some other things", "when I do activity A, I also tell some other object to do activity B".

But often the big chunk of code that was the "main event loop" of conventional programming devolves into the creation of a single object, which in turn creates other objects, which in turn create more objects. There may be a main loop somewhere, but it will only tell some controlling object to do its thing, and that thing will be to tell a set of live objects each to do their thing.