OO stands for ‘object-oriented‘, be it design, programming, or thinking. It’s a way of approaching programming problems that relies on building taxonomies of classes of objects, each of which has its own methods for doing things.

Much has been written about the benefits of OO including features such as code-reuse, encapsulation, data abstraction, etc. These are all good things, but mostly not really new. Code-reuse existed before OO, we called them libraries. Encapsulation existed before OO, we called them ‘jackets’ – using function calls to hide the exact implementation. Data abstraction existed before OO, structures in standard LISP allow us to build taxonomies of types. The difference is that OO adds methods to object taxonomies; functions become property values of objects. This allows the major benefit of OO, and the one that is rarely mentioned: done right, OO improves the way you think about the problem.

With OO, each piece ‘knows how’ to do things; it has its own methods for accomplishing tasks. In OO thinking, you tell the object to do something, and it knows how to do it. This is different from more traditional programming because instead of carving out the problem in terms of what needs to be done, you build a model of the problem domain by identifying the pieces that make it up, You then build a class taxonomy for them, decide what they will need to be able to do, and program them to do it. While hardly the best solution at all times and everywhere, building an object model of the problem comes in very handy when trying to solve a complex problem, because the pieces are usually readily apparent, and it lets you separate them into self-managing modules. I will write more about this elsewhere with reference to programming apps using WebKit.

The reason that OO thinking is not mentioned very often in lists of OO features/benefits is that the programming tools do not support it very well. In presentation, they are package, directory and file oriented, not class and object model oriented. If you look at Eclipse, the primary way of navigating through your code on the left side of the window is using directories and files. The class taxonomy has very little visual presence. This is a shame, because packages are a throw-back to structural programming, and giving them primacy does not encourage the programmer to think about the problem in terms of the pieces involved, and what they do. My experience has been that OO way of thinking greatly simplifies the programming of complex problems.