[jdom-interest] instanceof

Syloke Soong ssoong at protedyne.com
Mon Jan 22 08:18:50 PST 2007


Two weeks ago, CNN.com gallery had an article querying the mystery
behind an old fading picture where a man was sitting on a dead horse in
a town square in Minnesota, circa late 1800's. Incidentally, the weeks
prior were a deeded community's uproar in Colorado about how
anti-American and anti-C over a member's use of a peace wreath as xmas
decoration prominently outside her house. 

I am about to sit on a dead horse. Last month, we had a rather cute
debate on the academics of the propriety of using instanceof and how
anti-object-oriented it is. I have heard that some oo-purists feel
instanceof should be banned or obliterated from the java language (or
any language). I think use instanceof in java seems as anti-OO as the
use of peace wreath for xmas is anti-American.

Enough already on that rambling preamble.

The reason I am musing over this is, besides attempts at detracting from
and, the consequence of, my current frustration on looping over
element.getContent().iterator().

I have not much choice but to test each iterator member with instanceof,
do I?

I mean, if I had a sudden obsessive compulsion to make OO-purists happy,
what should I do with the next() member of the iterator extracted from
getContent()?

Even if jdom had a getContentIterator() from which next() would produce
a Content object rather than a bland Object, and that Content had a
getContentType() which could be either {Element | Text}:

[hypothetical code]
public contentious(Element ej)
{
  ContentIterator citr = ej.getContentIterator();
  while(citr.hasNext())
  {
    Content citrus = citr.next();
    Consume(citrus);
  }
}

public Consume(Text t){...}
public Consume(Element e){...}

[/hypothetical code]

Now the two Consume methods would be useless should rather be:

[hypothetical code]
....
  {
    Content citrus = citr.next();
    Consume(citrus.getContentType(), citrus);
  }
....

public Consume(Class x, Text t){...}
public Consume(Class x, Element e){...} 
[/hypothetical code]

As I said, in the event of my sudden upheaval in life and turned into an
abrupt oo-purist - then I would object to using

Consume(Class classflag, Content cj);

It should be purely Consume(cj);
cj should autonomously tell its own bearing without aid of a flag.

A method should digest an object without further hint. It should
decipher what that object is without a hinting flag. That is the spirit
of the OO I believe in. Imagine, someone handing me a vehicle to paint,
I should look at it and know it is a truck or a car or a plane without
further ado.

Using classflag is cheating. A method should consume an object, decipher
it without the aid of an external flag. It's like the Republican tax
reduction effort. I either pay it at the federal level or it gets
reduced where my state and town finally forced me to pay the shortfall.
Somewhere there is an instanceof.

I surmise the proper way is casting the call:
Consume( (classflag)cj);

i.e.,
Consume( (cj.getContentType)cj),

but the java language (or according to Sun's legal binding, Java
platform), does allow the result of method to be used as a cast.

Rolling moss gathers no stone. Or is it, A rolling stone gathers no
moss. I'm rolling from one level of OO-purification to the next().
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender immediately. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Even though this company takes every precaution to ensure this email is virus-free, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
Protedyne Corporation, 1000 Day Hill Rd, Windsor, CT 06095, USA,                                                                  
www.protedyne.com



More information about the jdom-interest mailing list