Oo Is Not About Reuse

One of the big selling points of OO was that it would facilitate re-use, and re-use was obviously a very good thing. The benefits of re-use seemed to go largely unquestioned, but that's another subject.

Anyway, OO's (hypothetical) re-use benefits were pitched so agressively that people seemed to confuse the two. In reality, OO and re-use have turned out to be really orthogonal things. Re-usable components might be implemented in an OO language like C++ or Smalltalk, or they might be implemented in a non-OO language like VB. Likewise, some OO systems are re-usable and some aren't.

People who confuse OO with re-use are likely to conclude that OoHasFailed and miss the fact that OO has other benefits.

It might well be that OoIsNotAboutReuse, but rather OoIsJustGoodEngineering.

Software reuse is a management problem, not a technical problem. Always has been, always will be. The best we can hope for from technology (e.g. OO, components, or whatever) is to make reuse more effective once the management problems have been overcome. -- JohnDaniels

Software reuse can mean many things. OO is certainly about one kind of reuse: the ability to cleanly reuse generic base class mechanism without disturbing or duplicating their implementation, because you can selectively override portions of the generic mechanism as needed. And this kind of software reuse scales with the right environment and personnel, with the same approach working for multi-layered vertical application frameworks used by distributed programming teams as well as one person programming alone.

Oddly enough, I've always found OO to be more about this kind of reuse than anything else, and saw how all the focus on object-centric problem decomposition left many otherwise experienced and rational engineers/programmers quite confused (and still programming in Basic, C, or FORTRAN). --ScottJohnston

To me, OO is about internal reuse. You reuse the code base you develop within the project you are developing. OnceAndOnlyOnce is a form of reuse. External reuse, the reuse everyone talks about, is hard.

To me there are technical aspects to the problem. Each OO program creates its own ontology. Your account class and my account class will not be the same. Even if you have namespaces, the cognitive dissonance that you get from "slightly off" abstractions can be maddening. Add to this the fact it is easy to create inadvertent dependencies in many languages.

The most reusable piece of code that I ever worked on (in C++) abstracted out memory management, error recovery, the primitive types of the language, all OS references, and scuttled all non-const static data. It also had a completely disjoint class hierarchy. No external classes were used. Making dependencies that explicit is not the normal course.

AndrewKoenig wrote an interesting article a while ago called TheConsideredHarmful? ("The" Considered Harmful). The notion is that whenever you assume that you have only one of something ("the"), you could be hurting yourself. In the article he mentioned things like C++'s cout and cin streams, but in my typically tangential way I started wondering about classes. In OO programs, we create instances of classes in our code. Typically instances of other classes can be created in the same place. The class chosen (and hardcoded) typically just provides the minimum capability for the context. You can't get more "the" than "the" account class.

-- MichaelFeathers

An interesting article that I think address Michael's comments about "The": http://www.riehle.org/computer-science-research/1997/cacm-1997-frameworks.pdf

I agree that the reuse potential of OO was overhyped. Our experience was that people were happy building new hierarchies, but tended not to reuse other people's. By contrast FlowBasedProgramming (FBP) is an excellent reuse tool, largely because each process has its own thread of control, and the processes only communicate by means of data streams, rather than through calls (even if indirect). In conventional OO, the timing of execution of an object's methods is controlled by other objects, so objects don't have the autonomy needed for true reuse. In FBP, the processes are black boxes, and the connections between them can be changed without having to change their internals. NateEdwards calls this ConfigurableModularity, which is so normal in real life that we don't even notice it! See also http://www.jpaulmorrison.com/fbp/reuse.htm. --PaulMorrison

I agree that OO is not about reuse, and that OoIsJustGoodEngineering (although that page is a mess in serious need of cleanup). In the embedded systems industry we are constantly striving to accurately reflect the machine hardware in the software model, but reuse is very low on the priority list. This is because computer-controlled electronics rarely moves from one generation of product or one family of product to the next one without some pretty radical changes in the capability of the underlying hardware platform. Reuse is a "nice thing to have," but simply doesn't apply. -- MartySchrader

CategoryReuse