So far, there are essentially three different proposals, two by me and
one
by Nicola. I will enumerate the advantages and disadvantages of each.
--------- From Nicola (Morpher interface) ----------
public interface Morpher
{
void setInput(Object input) throws ObjectFlavorException;
void setOutput(Object output) throws ObjectFlavorException;
void morph() throws MorphException;
}
public interface MorpherPipeline extends Morpher
{
void addStage(Morpher nextMorpher);
}
------------------ NOTES -----------------
* The bidirectional registration ( setInput(), setOutput() ) seems
unnecessary. A pipeline flows in one direction--from the input
to the output. Our API should reflect that.
* The MorpherPipeline (or equiv.) interface may make it easier to add
stages, but InfoMover's logic is pretty simple. It the pipeline
can safely be implicit instead of explicit. We have no need of
caching pipelines or other more esoteric solutions. IMO they
are FS. If we need to cache, that should be designed intelligently
into the system.
* There is no distinction between Input, Output, and Manipulator.
I think that these should have a definite distinction.
* Required method ordering precludes the ability to have ThreadSafe
implementations, which can cause resource strains on a loaded system.
I don't want to be a victim of those issues if I can help it.
* The morph() method doesn't make sense in this context.
----------- From Me (First Version) ---------
interface Input
{
void setDestination( Output out );
}
interface Output
{
Response processTransaction( Transaction trans );
}
interface Manipulator extends Input, Output {}
---------------- NOTES -----------------
* Requires registration, but it is unidirectional. Still Manipulators
can't be threadsafe.
* as Nicola pointed out, setDestination() is not intuitive
* The more I look at it the less I like it
------------ From Me (Second Version ) -----------
interface Input
{
Transaction getNextTransaction();
}
interface Output
{
Response process( Transaction trans );
}
interface Manipulator extends Input, Output {}
------------------ NOTES -----------------------
* Does not require any registration of the next stage in the pipeline
* It is more intuitive to use
* The Job is in finite control of the pipeline
* Manipulator still has issues with threadsafe implementations, and
worse, if the calls to process() and getNextTransaction() are not
symetrical we can get some weird runtime errors--so that is a blocker.
---------------- From Me (Third Version) --------------
interface Input
{
Transaction getNextTransaction();
}
interface Output
{
Response process( Transaction trans );
}
interface Manipulator
{
Transaction manipulate( Transaction trans );
}
----------------- NOTES -------------------
* has all the strengths of the second version, but finally gets
rid of the method ordering issues.
* The Manipulator does what it does best, manipulates a transaction.
Unfortunately we have no way of extracting a Response if the
transaction
violates some integrity checking issues.
- We can create a "struct" like class that encapsulates the
Transaction
and Response together, allowing us to keep the same strengths and
check
if the transaction is still good.
- We can alter the Transaction so that we can make the Response
encapsulated
inside the Transaction. That would cut down on Response object
creation,
and still let us know if the transaction was successful. This is
probably
the better of the two solutions.
---------------------------------------------
Ok, any comments? Do you guys agree?
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
