A Change In Terminology: Monomorphic Objects. Polymorphic Objects

Happy New Years All,

I read in a concurrent post that the fad that "everything is an object"
is on the way out. That's probably good - I have seen designs where
the classes are actually nothing more than collections of functions
wrapped in something that just happens to have the word "class affixed
to it":

class MemoryScanner
{
   virtual Scan (...)
   // 20 virtual functions, many of which are global functions in
disguise
  // 2 member variables.
} ;

class MemoryScannerBigMem : MemoryScanner
{
   virtual Scan (...)
} ;

class MemoryScannerFactory()
{

  MemoryScanner * GetMemoryScanner();

} ;

MemoryScannerFactory *pMemScannerFactory = new MemoryScannerFactory();
MemoryScanner pMemScan = pMemScannerFactory->GetMem..

Uggh...I get nauseous trying to finish even this small example. But
you get the point. Everything is verb-oriented. Many virtual
functions. Much new()'ing. Much delete()'ing. The mood when reading
the code is "do this, do that." It is almost as if the programmer is
allergic to state. In any case, this style of programming leads too
much getting, and doing, and verifying, and initializing....

Occasionally, the thing that is being "got" is not well-formed (read,
the programmer has not figured out its true nature), so there is a
necessity to make it polymorphic. This in turn leads to other issues
such as lifetime management, etc.

There is a different style of programming that resists the
verb-oriented paradigm. It focuses instead on what things are instead
of what they do, on the principle that, if you know what it is, you
already know what it does. The above example rewritten would be:

class MemoryScanner
{
    void Scan(...) ;
} ;

MemoryScanner scanner;
scanner.Scan(...);

Now this second form has no pointers involved, and there are no
ownership issues. You certainly do not "get" a memory scanner. You
"use" one that you make, on the stack. This is only possible, of
course,if the programmer exercises sufficient forethought to determine
the nature of that which is being objectified so that virtual functions
can be obviated. This, in turn, presumes that it is even possible that
a quasi-terminal form for the latter can be found. That is a matter of
another debate however.

When I discuss the difference between these styles of programming to
other C++ programmers, I find myself at a loss for good terms. In my
mind, the second Scanner is just as much an object as the the first.
In fact, I would say that an object is a thing, and since a purely
abstract class cannot even be instantiated, then it could be regarded
as less of a thing than a concrete object.

The previous sentence hints at another problem. Technically, both these
classes are abstract. After all, that is what we do as coders: we
create suitable abstractions for real things, suitable to the point
where we felt we have captured enough information that a true 1-to-1
correspondence is not necessary (too many silicon atoms would be
required). But the first form is has an "abstract" type and the second
form, well, it has a classification that is not abstract.

Nevertheless, I do not agree that the second form is not
object-oriented programming. I think both are object oriented
programming. I feel that a more appropriate nomenclature would have
been to refer to the former as polymorphic programming and the latter
as monomorphic programming, while still keeping in mind the pro's and
con's of each.

I also speculate that some authors might have been overzealous in
preempting the anticipated tendency of future programmers to forsake
polymorphic programming by "using C++ as a better C". So they employed
the English language to make it clear that:

You are are not really an OO Programmer unless you use polymorphism.

....thus inducing anyone who would dare call himself/herself an OO
Programmer to begin using virtual functions as soon as possible. They
got what they asked for: virtual functions abound, and there is so much
polymorphism, one begins to wonder if something a little more concrete
is in order.

What shall we call the second type of programming? Concrete?
Monomophic? Dead?

-Le Chaud Lapin-

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]