Re: OO and Procedural Work Units (was switch string)

A lot of recent postings have suggested that it is typical
and normal for O-O to represent this massive investement,
with benefits delayed and maybe never seen.

There are certainly cases where the benefit of O-O is delayed.

You make this big massive investment and then spend a long
time writting little bitty subclasses to make a profit on the
intial investment.  This is what the books tend to focus on.

However, sometimes, you can begin to do reuse at once,
even during the initial coding.  This is often overlooked and
can be an immediate payoff.

Take Joe's example of a "table abstraction" where the
output could be HTML or XML.

Now, I must confess I didn't read Joe's examples closely
as I had other fires white hot at the time.  But, let me
proceed with something similar.

We all know it turns out a lot of tags in both XML
and HTML have a common structure:

<CONST_STRING>
simple string data that's the real interesting stuff
</CONST_STRING>

Now, you could have a generic class that everyone either includes or
inherits
from (not sure which on this five minute thought, probably includes)
that would go like this:

class GenericTag {
   String start;
   String end;
   GenericTag(String tagname) {
   start = "<" + tagname + ">";
   end = "</" + tagname + ">";
   }
   void putTag(Writer cout,String contents) {
           cout.write(start); cout.write(contents); cout,write(end);
   }
   void getStart() { return start; }
   void getEnd() { return end; }
}

. . .this can be used to pretty directly implement TD, TR, TABLE
and several other HTML tags.  It could even implement a paragraph
tag (<P>) because </P> is legal HTML albeit rarely seen.

Now, I don't remember Joe's examples exactly, and
it doesn't matter if this maps exactly anyway, but
let's assume Joe has an abstract "table" object and
related objects to  represent the concept of "row"
and individual "column" or entry
within the row.  Thus, a table is a collection of rows
and a row is a collection of individual column elements.
Thus, there would be "list" objects that contain
an unknown number of rows and columns, respectively.

Further, let's assume that the abstractions
like "row" and "column" were abstract parent objects
and had individual children for the specific XML and HTML
object types.  (This parent/child relationship
may depart from what Joe has, actually, but it is
easy for showing the reuse-on-the-fly concept I have in
mind here).

So, if you do it by including GenericTag rather than inheritance:

class tableColHTML extends tableCol {
    GenericTag gen;
    String contents;
      . . .
    tableColHTML(. . ,String contents, . .  .) {
       gen = new genericTag("TD");
   }
   String toString() { return this.getStart()+contents+this.getEnd(); };
}

and in the XML side

class tableRowXML extends tableRow {
   GenericTag gen;
   tableColumnList col;
   tableRowXML(String meaningfulXMLName, ... , ) {
      gen = new genericTag(meaningfulXMLName);
         . . .

   }
   String toString() {
          String colcontents= this.getStart();
         /* This really should be in tableColumnList but
               it makes the example shorter to put it here */
         for( i = 0; i< col.length; i++)   { colcontents = colcontents+
                col[i].toString();
          }
         colcontents = colcontents + this.getEnd();
         return colcontents;
}

And, finally:

class tableXML  extends table {
    GenericTag gen;
    tableRowList allrows;
     tableXML(String meaningfulXMLName name) {
           gen = new GenericTag(meaningfulXMLName);
           . . .
     }
    void outputTable(Writer cout) {
          /* tableRowList, not shown, does a for loop type
                   of thing to get each column's info wrappered
                   by the TR or MeaningfulXMLName for the row */
          String tableInformation = allrows.toString();
          putTag(cout,tableInformation);
    }
}

And you get reuse at once.

Note also that for more complicated elements that don't fit this pattern,
all of this can be readily overridden, but for the many tags
that meet this pattern, the reuse of GenericTag is simply there
to be used.  It might even be possible to beef up GenericTag somewhat
to have more than one "contents" variable and maybe things like
integers and so on.  Or, critically, maybe children of GenericTag
that do those things.  Yet, the code above for tableRow and so on would
not change if that were true, because GenericTag or its children would do
things
like detect that the second and subsequent contents variables were nulls
and so "do the right thing" without affecting their callers.  So, all the
interfaces would
stay the same.  This means O-O benefits on the initial coding.

Of course, it is barely imaginable to do this procedurally.  However, look
at how
objects make this easy.  The key data you need is right there, well-defined
in
GenericTag.  It could be extended without changing a single line of code
to cover attributes and multiple "content" variables.

And, it is encapsulated so the compiler keeps you from
clobbering it or sending it as a parameter to someone else.  You can
beef up GenericTag without changing the methods that all the
existing users have.  The JVM can even notice you never
change "start" and "end" and do nice things as a result.

Differences are easily accounted for; you see constants for the HTML
form in the GenericTag constructor, because there is only one possibility.
Yet, in the XML form, because each tag has some potential semantic
significance,
and maybe a particular name, it becomes a parameter.

Note finally that this approach redoubles the power of the built-in Java
object
set.  You don't know or care whether this is an ordinary file, pipes, or
what.  The
Java O-O object I/O structure takes care of that for you.

And, you get all of this benefit even if you never reuse this code on
another
project.


PS, keep in mind that this is an example; I haven't given it as much
thought as Joe did in terms of being practical for a real professional
design.
This simply illustrates some common O-O concepts.


Larry W. Loen  -   Senior Java and AS/400 Performance Analyst
                          Dept HP4, Rochester MN


+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---