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/