Why Object Based Programming Discussion

This page contains discussion of ObjectBasedProgramming in response to WhyObjectBasedProgramming.

Years ago I did some of this. It was for an embedded system. Today I could justify doing such a thing only if there was no C++ compiler for the target processor or I was threatened at gunpoint. It was an odd experience. I looked through the code generated by Glockenspiel's CFront port and ended up doing many of the things in the ObjectBasedProgramming pattern, but I used macros extensively to hide details.

The problem with implementing OO in a non-OO language is the brittleness that it creates. The more conventions that programmers have to adopt which create work, the more likely that they will be ditched accidently or for expediency, making the code less readable. Secondarily, ObjectBasedProgramming makes you do work on a per "class" basis that OO languages do behind the scenes for all classes. Thus, the ratio of attention that programmers pay to the problem versus the implementation decreases. Programmer's loath to change things in those kinds of systems because of the amount of work involved.

I've seen the same situation occur in distributed systems when "classes" each bear the brunt of distribution. The object model ends up having two or three classes for each conceptual class in the system to handle the different roles they have to face in distribution.

In my opinion, these are both problems require something like AspectOrientedProgramming, but that is currently a research topic rather than a practical tool.

I'd offer that when you get to the point that using C or C++ really makes a speed difference to you, you are really dealing with areas where it is the design (the partitioning of structs/classes) which needs to be altered rather than the language. In that case, remember that C++ compilers eat valid C. Work in C++ and optimize the heck out of it using ObjectBasedProgramming tricks later. Incurring the work of ObjectBasedProgramming from the beginning just strikes me as unnecessarily painful, unless you just don't have a C++ compiler.

-- MichaelFeathers

Writing the program in C++, and optimize the rest in OBP sounds wonderful, but I wondered how well it will work in practice. A C++ program has high size overhead, not just because a class implementation generates more code, but rather it has to include all the C++ engine and run-time library (e.g. the class dictionary, the OO mechanics, the RTTI mechanics, and the exception handling mechanics). Rewriting a particular class in OBP is not going to help much. Furthermore, each C++ compiler has a different implementation. The class-look-up tables (and etc.) have different formats. This does not bode well for multi-platform development mixing OOP and OBP. OBP however has no dependency on compilers (as a demonstration, our OBP-programmed system runs on Intel and Motorola platforms). -- StephenCheng

There is not a C++ compiler for the 8 bit micro used in my current project.

It is for embedded systems that StephenCheng, KeithDerrick and I feel the need to discuss this. There may well be many dozens of people around the world that are creating embedded systems, and while trying to maintain a professional approach to our jobs we would like to take advantage, as best we can, of software engineering principles such as OOA/OOD. Although we do not have an OOPL available, this does not stop us attempting to obtain the reuse and flexibility aspect of our designs from OOA/D.

I cant say that I concur with everything you say about the 'brittleness' and 'loath to change' aspect of ObjectbasedProgramming?. I do agree that there is a need for a bit of 'brain power' to get an OO design implemented with ObjectBasedProgramming, though in the small teams I work with, one or two people, it does not take long to get people to buy into the ObjectBasedProgramming method. If we were to follow anybody's software design method, there is always some 'brain power' required to get from the design documents to an implementation. I do not feel that the ObjectBasedProgramming method requires any extra effort on top of that! -- ScottWalsh

I personally don't think OBP requires too much 'brain power'. However it is the intention of this pattern to even further reduce the need for 'brain power' and to reduce the learning curve for OO beginners. When this pattern language is completed, the programmers can simply choose an OBP implementation technique, such that their 'brain power' can be applied to what they have been paid for (and not thinking about this). -- StephenCheng

Scott, it seems we agree that if you do not have a C++ compiler for an embedded platform, ObjectBasedProgramming is the way to go. I was writing in response to WhyObjectBasedProgramming, which mentioned embedded systems in only a minor way and did not talk about the downside. At first reading it seemed to be making a general argument for ObjectBasedProgramming to gain flexibility. I tend to feel that ObjectBasedProgramming is a great tool (I've used it) but only when my back is up against the wall.

Regarding the overhead, I notice a big difference when working on those kinds of systems. When developers have to write additional code on a per method and per class basis, or in a very stylized manner, to serve some goal that is not part of the logical design, it is harder to RefactorMercilessly.

-- MichaelFeathers

Sometimes technology is not the limiting factor - human is. Even in this enlightened days, there are still a sizable contingent of non-OO capable embedded software engineers. To introduce OO to such a culture often involves overcoming the cultural resistance and extensive training. I believe OBP is a great training ground for OO, since the underlying OO concepts become so visible. OBP also has values in overcoming cultural and managerial resistance ( the 'we are still using C' argument). -- StephenCheng