> Mike, your position strikes me as a little extreme (or, maybe,
> tongue-in-cheek). But it is not uncommon to see a Java programmer
> occasionally write tuple-based data structures using Hashtables (or Maps).
My opinion was not meant to be tongue-in-cheek. In fact, I build all my
data processing software using dynamically typed, self-describing containers
(e.g. Row and Table). Even before using Java, I did the same with C and
C++. Note that I do not write other sorts of applications using such
containers. Where data is internal to an application and the application
has total control over the data's structure and datatypes, I am a strong
advocate of strict typing. I simply think that data processing applications
have a enough to gain from dynamically typing that it is a win overall.
> The problem with tuples or Hashtables, as I see it, is two-fold.
> First, the
> program becomes less readable and harder to understand, undermining its
> maintainability. And second, you lose compile-time checking of access to
> the data structure, causing you to deal with problems (such as misspelled
> field names) later in the development cycle.
Yes, loss of compile time type checking is a definite draw back, but it is
balanced by the amount of flexibility and reusability it buys in data
processing applications where most of the data is simply passing through the
application on its way from one place to another and who's structure and
typing is out of control of the application. Even if you do use statically
typed containers, you'll still have to deal with loss of type checking at
the interface with the outside world (e.g. the database) and when using the
containers in the java.util package.
Have you ever taken a survey of one of your data processing applications and
counted the number of fields that actually have business rules that depend
on them? I have found that only a small percentage of fields fall into this
category. The rest of the fields are simply passing through untouched. The
application doesn't care what they are for or what their datatype is. Since
it doesn't need to be aware of them, why force it to be aware of them?
You're adding a dependency that isn't buying you anything. If someone
outside your application changes the datatype of a field, removes one, or
adds a new one, you'll need to make changes to your application.
> I am an advocate of simple value object structures. They provide
> clarity of
> code and compile-time checking of field names and types. I'm
> still waffling
> about the accessor methods vs. public fields argument. I tend to think
> accessors are busy-work, providing very little benefit in the value object
> world. I am, however, considering the "value objects should be immutable"
> position. It's not something I have done before, especially since many of
> the value objects I have dealt with contain dozens of fields (and I don't
> like constructors with more than 3 or 4 parameters). But you can still
> create immutable value objects using public (final) fields.
This is exactly one of the reasons I prefer the dynamic approach. Using a
dynamic approach eliminates the problems associated with constructors and
other functions having large numbers of arguments. Functions with 1, 10,
100, or 1000 parameters all look as simple as this:
void updateFoobar( Tuple parameters);
This also handles optional parameters much better than overloaded functions.
Mike Bresnahan
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
