If you feel there is value in attaching names to your tuples, then you can
always do this:
class MyTupleName extends Tuple { }
Or more simply in C, C++, or CORBA IDL:
typedef Tuple MyTupleName;
I agree that there is a cost when to use dynamic typing. I illuded to it
and you elaborated on it. However, Java makes this trade-off all over the
place and it always will until they add the equivalent of C++ templates
(e.g. the container classes). Additionally, in the type of applications I
have written over the past 7 years, the source and destination of the data
is dynamically typed. For example, the source and/or destination is often a
RDBMS and the interface to the RDBMS (JDBC) is dynamically typed. Thus
using static typing does not save you as much as you might want.
Concerning the data validation logic you mentioned. I agree, the simple
Tuple class I described does not support this. However, you could conceieve
of one that did. Additionally, in my experience, 90% of the data elements
in a given tuple do not have any business logic associated with them. To
the application they are just plain old data going from one location to
another - perhaps to the display monitor or to a RDBMS. As time passes and
requirments change, elements get added, change type, or get removed, but the
application really doesn't give a hoot. A dynamically typed architecture
makes it much easier to maintain this sort of thing. For example, Bob, is
there business logic in your application that depends on the zip code
existing and having particular datatype - i.e. a dependency? Assuming there
is none, then why force your application to have such a dependency?
Unnecessary dependencies are the bane of software quality. This is same
agrument used to advocate data abstraction and the same mistake that caused
the Y2K problem.
Note that I do believe in static typing for elements that do have a lot of
application logic attached to them.
Why do you think patterns are over used, Bill? My opinion is that they are
way _under_ used. In any case, the Producer-Consumer pattern is the perfect
fit for the problem and the one I've seen used in many similar servers. The
idea is there you have a single request handler thread that does nothing but
recieve requests and put them on a queue and a pool of worker threads taking
requests of the queue and processing them. You may also want a response
handler thread to deliver the responses asynchronisly.
Mike
----- Original Message -----
From: "Bill Gladen" <nobody170 at yahoo.com>
To: "Mike Bresnahan" <mike at fruitioninc.com>; <tclug-devel at mn-linux.org>
Sent: Friday, July 13, 2001 9:29 AM
Subject: Re: [TCLUG-DEVEL] Java Interfaces and multi-extends?
> Well, I just can't resist weighing in on some of these, so here I go.
>
> Responses interwoven
>
> --- Mike Bresnahan <mike at fruitioninc.com> wrote:
> > Why not just pass two arguments to the constructor - request and
> > response?
> > That would model how the Servlet API is designed.
>
> A very valid point. Basically a decision should be made as to wether
> the resulting combination forms a logical union
>
>
> > By the way, my personal taste is to never design an interface or
> > class that
> > has nothing but get()/set() functions. I don't think such a class
> > has
> > enough interesting behavior to be a class of its own. You can easily
> > factor
> > out the reusable behavior of such a class and all bizillion other
> > similar
> > classes into a interface like this:
> >
> > interface Tuple {
> > public Object getValue( String Key);
> > public void putValue( String Key, Object value);
> > }
>
> AAHHHH!!! It Hurtsess usss!!! Makesss it go awayyyy.
>
> There are often valid reasons to provide a class that is primarily
> getters and setters. One of the easiest to defend is data integrity.
> If your class must have values for ((A and B) or (B and C) or D) at any
> given time for it to be a valid instance, you can provide constructors
> that force you to pass enough values in, and put checks in the setters
> that prevent you from setting something to null incorrectly.
>
> Another BigThing you lose is clarity. The above will work and may be
> easier to write, but figuring out what it does later is a real pain if
> you have a bunch of Tuple s floating around in your code, rather than
> an Account, a CommissionModel, and three LineItem s.
>
>
> > Here's a couple quick examples that illustrate the advantages of this
> > design:
> >
> > - you only need to write one toString() function, not a bizillion
> > - you only need to write one function to insert, update, or delete
> > this
> > tuple from a RDBMS, not a bizillion
> >
> > Thus the design eliminates a lot of redundant code and therefore
> > reduces
> > bugs, complexity, compile time, etc. However it comes at the cost of
> > dynamic typing vs static typing.
>
> It may reduce the code, bugs, complexity, and compile time of this
> code, but it will increase the complexity of using the code, thereby
> increasing the downstream bugs, and the compile time you reduced will
> be time you have to spend by hand later finding out that you typed:
>
> theTuple.set( "weight", new Integer( weight ) );
>
> in one class, and retrieved the value with either
>
> int weight = ((Integer)theTuple.get( "wieght" )).intValue();
> or
> String weight = (String)theTuple.get( "wieght" );
>
> in another class. The compiler would have found either type of error
> much more quickly than you will.
>
>
>
> > If I didn't want to pay the costs of dynamic typing and really really
> > wanted
> > it to be statically typed, then I would just create a "struct" like
> > class to
> > be a convenient way of grouping the data elements together.
> >
> > public class CreditPaymentInformationIF {
> > public String orderNumber;
> > //...
> > }
> >
> > You may stop and say, "But its not encapsulated!". But I will
> > counter with,
> > "Yes it is, but the encapsulation barrier is the function that
> > returns the
> > instance of the class." That function is the black box where all the
> > interesting behavior happens. The above class is simply the
> > resulting data.
>
> I would only agree with this if the data were all uncontrolled and
> always will remain so. If you need any sort of control of any of the
> data, or_even_if_you_may_in_the_future, you should encapsulate.
> Otherwise, to change it later, you will break all of the using classes
> that rely on the data being public.
>
>
> > One other thing... it seems possibly bad design to be passing the
> > request
> > and response to a Thread constructor for two reasons.
> >
> > - Creating threads and handling requests are conceptually two
> > different
> > things - one is a performance optimization and the other is a
> > business
> > process.
> > - Creating a thread for every request could be a performance problem
>
> I agree with this. Creating a Thread is really expensive. Actually,
> creating a Thread object is as cheap as any other object, but calling
> start() is very expensive. You probably want to give the CyberCache
> object some other method like 'processRequest' rather than 'run', and
> then create some Thread s that service the requests one after another.
>
>
> > You might be better off seperating the two concepts and also using a
> > thread
> > pool and Producer-Consumer pattern to handle incoming requests. If
> > you do
> > it right, the request handler could be generic enough to be reuable
> > by your
> > next server application.
>
> Be really carefull with patterns. They are generally over-used in my
> opinion.
>
>
> > You asked for my opinion and you got it. :)
>
> insert evil grin
>
>
> > Mike
> > ----- Original Message -----
> > From: "Bob Tanner" <tanner at real-time.com>
> > To: <tclug-devel at mn-linux.org>
> > Sent: Friday, July 13, 2001 1:46 AM
> > Subject: [TCLUG-DEVEL] Java Interfaces and multi-extends?
> >
> >
> > > Well, smack me and call me silly.
> <snip/>
>
>
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail
> http://personal.mail.yahoo.com/