Why not just pass two arguments to the constructor - request and response?
That would model how the Servlet API is designed.
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);
}
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.
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.
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
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.
You asked for my opinion and you got it. :)
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.
>
> I did not know you could extend interfaces multiple times, kind of like
multiple
> inheritance in C++. Solve a problem for me. But it makes a design question
for
> me.
>
> For those who don't know, I am almost done with a 100% Java based
CyberCash API,
> which I'll be releasing to the community in a couple of weeks.
>
> So, you have the scope of what I am trying to do here. And here is my
design
> problem.
>
> I have 2 interfaces (comments stipped for brevity):
>
> public interface CyberCashResponseIF {
> public Properties getResponse();
> public void setResponse(Properties response);
> }
>
> public interface CreditPaymentInformationIF {
> public String getOrderNumber();
> public String getCardType();
> public String getCardZip();
> public String getCardState();
> public String getCardCountry();
> public String getCardCity();
> public String getCardNumber();
> public String getCardName();
> public String getCardExp();
> public String getCardAddress();
> public String getCardAmount();
> }
>
> These of course represent a response and request to a CyberCash Merchant
server.
> I used the names Cybercash does in their MCK documentation,
> CreditPaymentInfomation = request in Cybercash lingo.
>
> The Cybercash "engine" looks likes like this:
>
> public class CyberCash extends Thread {
> public CyberCash([MY DESIGN QUESION HERE] transaction) { }
> public void run() {}
> }
>
> Because I extended Thread, I more or less have to pass everything in via
the
> constructor, so every cybercash transactions has a request and a response
so
> what I did what was this:
>
> public interface CyberCashTransActionIF
> extends CreditPaymentInformationIF, CyberCashResponseIF {
> }
>
> Changed Cybercash constructor to this:
>
> public CyberCash(CyberCashTransActionIF transaction) { }
>
> My question is: Is this a hack?
>
> An interface that just extends 2 other interfaces just to combine them
into a
> nice "package" seem wrong to me OO desing side, but my old C-hack side
says it
> works, so do it.
>
> Futher design details show that there are some object that just do
> CreditPaymentInformation and other classes that just do CyberCashResponse,
but a
> majorit of them do both.
>
>
>
>
> --
> Bob Tanner <tanner at real-time.com> | Phone : (952)943-8700
> http://www.mn-linux.org | Fax : (952)943-8500
> Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9
>
> _______________________________________________
> tclug-devel mailing list
> tclug-devel at mn-linux.org
> https://mailman.mn-linux.org/mailman/listinfo/tclug-devel