Object Orientation – Required Features for Object Orientation

Code reuse is a pretty good idea. Not a great one.

I have a perspective drawn from about 30 years of software engineering, trying to "reuse".

I started investigating "code reuse" as a research topic back in the 80s, after discovering I had reused the design of one OS I built in the early 70s, for another OS I built in the late 70s.

The good part of code reuse is the ability to sometimes reuse honest-to-god preexisting code. But the world is full of code; how can find what you want? Here's what I call the Reuse Curse:

I'm Santa Claus (ok Open Source), and I have a bag of 1 billion software components. You can have any one of them.

Good luck choosing.

To solve the reuse problem well:

• the reuser needs to somehow specify what he needs (functionaly, performance, target language, environment assumptions, ...)
• there must be a library of "reusable" code that has been indexed in various ways by these potential criteria
• some mechanism must exist to pick out candidate elements (at a billion elements, you can't look at them all personally)
• there needs to be a way to characterizer how far away from the specification the chosen candidates are
• some regular process should exist to allow the reuser to modify the chosen reusable code (here is OOP's greatest contribution: you can edit an existing component/object by overriding its slots. OOP doesn't provide any other help).
• all this must clearly be cheaper than simply recoding it

Mostly what has been discovered over the years is that for code to be reusable, it sort of has to be designed for that purpose, or it contains too many implicit assumptions. The most successful code reuse libraries have actually been pretty small. Arguably libraries and frameworks are "reusable" code and they are extremely successful; Java and C# succeed not because they are pretty good computer languages, but rather because they have huge well-designed, implemented and documented libraries available. But people don't look at the source code in the libraries; they simply call a well-documented API (designed to be generally usable).

What code reuse hasn't done (OOP neither) is provide orders of magnitude improvement in our ability to code systems.

I think the key flaw is that any kind of code reuse is fundamentally limited because code has too many assumptions built in. If you make the code tiny, you minimize assumptions, but then the cost to build from scratch isn't very big and the reuse gains are not effective. If you make the code chunks huge, they're pretty much useless in a new context. Like Gulliver, they are tied to the beach by a million tiny strings, and you simply can't afford to cut them all.

What we should be working on is reuse of knowledge to construct code. If we can do this, then we can apply that knowledge to construct code that we need, handling the current set of assumptions.

To do this, one still needs the same specification capability to characterize software components (you still have to say what you want!). But then you apply this "construction" knowledge to the specifications to generate the code you want.

As a community, we aren't very good at this yet. But people do it all the time; why can't we automate it? There is a lot of research, and this shows it can be done in many circumstances.

One key piece of machinery needed for this are mechanical tools for accepting "component descriptions" (these are just formal documents and can be parsed like programming languages) and apply program transformations to them.

Compilers already do this :-} And they are really good at the class of problem they tackle.

UML models with code generation are one attempt to do this. Not a very good attempt; pretty much what one says in most UML models is "I have data that looks like this". Pretty hard to generate a real program if the functionality is left out.

I'm trying to build practical program transformation systems, a tool called DMS. Been pretty well distracted by applying program transformations not so much to abstract specifications to generate code, but rather to legacy code to clean it up. (These are the same problem in the abstract!). (To build such tools takes a lot of time; I've been doing this for 15 years and in the mean time you have to eat).

But DMS has the two key properties I described above: the ability to process arbitrary formal specifications, and the ability to capture "code generation knowledge" as transforms, and apply them on demand. And remarkably, we do generate in some special cases, some rather interesting code from specifications; DMS is largely built using itself to generate its implementation. That has achieved for us at least some of the promise of (knowledge) reuse: extremely significant productivity gains. I have a team of about 7 technical people; we've written probably 1-2 MSLOC of "specifications" for DMS, but have some 10MSLOC of generated code.

Summary: reuse of generation knowledge is the win, not reuse of code.

PEP 435 was the proposal to add enumerations to Python. The motivation for adding enumerations:

The properties of an enumeration are useful for defining an immutable, related set of constant values that may or may not have a semantic meaning. Classic examples are days of the week (Sunday through Saturday) and school assessment grades ('A' through 'D', and 'F'). Other examples include error status values and states within a defined process.

Enumerations serve the same purpose in object-oriented code as in procedural code.