Real world musings

From: Richard MacDonald (macdonaldrj_at_worldnet.att.net)
Date: 12/14/03 

Date: Sun, 14 Dec 2003 16:06:52 GMT

I'd first like to ask Uncle Bob a question: "Bob, did you ever go through
a 'real world' phase?" I presume not, since you were expert before OO.

I went through real world phase when I got into OO. It paralyzed me for
2 yrs - a total failure. Then I got enough knowhow to blaze my own trail
and overcome this handicap. When I came across Uncle Bob's "nuts and
bolts" OO definition, I was initially repelled, then attracted, now I
love it.

But I still believe that the best OO model is one that closely models the
"real world". Not for any philosophical reasons; simply because I find
its more likely to handle future changes gracefully, since its more
"aligned" in some vague sense. (I found myself thinking about this while
lurking the bowling problem threads...yes, the simple solution solves the
problem, but I'm in the camp that worries about all the future
requirements that will probably hose that TDD-discovered model.)

Of course, that "real world" is a fictional one: The "real world" model
that exists in my head to solve the problem. If you'll buy the concept of
a "real world algorithm", I'll buy the real world definition :-)

I was thinking about this because I'm currently experiencing two
conflicting arguments on a project:

1) I've written a jdbc framework. Initially, it was for testing purposes,
to create and tear down databases for junit. Since there is no consistent
SQL creation code (oracle, sqlserver, and hypersonic), this was rather
complex stuff. I'd initially created a SqlDatabase, SqlTable, and SqlRow
object to handle this (read: "real world approach"), but I was overruled
and we went with a single object that just strung out a bunch of String
fragments into a StringBuffer (read: screw the real world, go with simple
and effective code). This worked ok, but note that it did no insert,
select and udpdate, only create and delete database (we used Toplink for
that).

My current project required insert, select and update. This killed my
single String fragment class, so I refactored to add back my SqlDatabase,
SqlTable, and SqlRow objects. A few more objects and a bit more
complexity, but it handled the new requirements much better.

Score one for the "real world". But its not a knock on TDD and simplest-
thing because the refactoring was easy.

2) The composite object I have to persist is a simple one: A "parent"
object with a collection of "children" objects, one of which is the
"default". Each child is uniquely named, so the "real world" model
logically modelled the relationship with a hash table owned by the
parent, keyed on the unique name. Makes sense, right?

Wrong. First I have to read this object from an xml document sent via
http post, then I check this object against the database to see if it
already exists, then I merge the two (the xml document can represent an
append or a replace). I used SAX to read the xml document and I placed my
validation code into the SAX objects. Validation turned out quite
doable...until I realized a constraint I had forgotten about: For the
append scenario, to check the uniqueness of the children names and to
verify that the default child exists in the collection, I have to read
the persistent object as well.

I had done TDD to handle all the constraints and it had worked to date.
The SAX validation was the simplest technique so I had chosen it. Now,
the next simplest step was for my SAX validation code to access the
database and read the "already-persisted" object. But this would also
produce a horrific dependency between the SAX objects and the persistent
objects, i.e., I could never use this SAX parser without the database.
This is an example of coding into a "local optimum" (next simplest thing
works, but globally ugly).

One solution was to read the persisted object before parsing, then pass
this object into the parser. An easy refactor, but still ugly, since I've
had to write some "persistedObject == null" case code and so forth.

Another solution was to take the validation out of the SAX parser: Use
the parser to read the object without validation, then have some other
object perform validation of the new and persisted objects. This seems to
be the best solution.

But it breaks my real world model. I need to fail if I read two children
with the same name. If I validate after parsing/construction, I need to
alter my domain model to use a collection rather than a hash table, i.e.,
store them all first, *then* check names.

Alternatively, I can create a new intermediate object to store the
results from the parser (simple Strings rather than objects), then
validate this object, then construct my domain object from this
intermediate object. Workable, but not the simplest thing. OTOH, its
probably the best thing. But it repels me as well because of the extra
code and objects.

("Final" decision has not been made.)

In summary, I confess that while I buy into TDD, I always keep an eye on
the "real world" and try and align my domain model to that. I'll override
the "simplest-thing" in favor of "real-world-alignment", but I also
recognize that there is invariably something in the problem that will
conflict with this "real-world" and I will have to make some compromise.
I'd even call it a hack (in the bad sense). But its required.

Anyway, just musings I thought I'd share. A simple problem but lots of
interesting consequences.

Relevant Pages

  • Re: Real world musings
    ... structures of that problem space. ... I used SAX to read the xml document and I placed my ... > validation code into the SAX objects. ... > objects, i.e., I could never use this SAX parser without the database. ...
    (comp.object)
  • Re: Real world musings
    ... Your string fragment class as well as your database classes all of ... I used SAX to read the xml document and I placed my ... >validation code into the SAX objects. ... >objects, i.e., I could never use this SAX parser without the database. ...
    (comp.object)
  • Re: [Full-disclosure] Apache Illegal Request Handling Possible XSS Vulnerability
    ... parser: validation is stupid, validation is boring, validation is ... occasional experience of reluctant HTTP request parser writer ... Seriously, who the hell cares. ...
    (Full-Disclosure)
  • Re: RegExp.test() funkiness (fails every second call)
    ... In order to validate for the w3c parser. ... For the rest it will work, also if failing validation, no human will ... peace, peace, mercutio, peace! ...
    (comp.lang.javascript)
  • Re: SAX parser problem
    ... against a given schema. ... turns on validation, whether it be against a DTD or any other schema ... attribute within the XML file, which will probably be in a remote ... the parser up and not by simply using the setValidationmethod. ...
    (comp.lang.java.programmer)