|
"Program to Interfaces, not Implementations" we've all heard, however I
now identified a scenario where this idiom can not be used (I think) and
is searching for another approach.
I have a method exposed as a webservice (JAX-RPC) which specifies that
the pass/return types must adhere to primitive types, beans and/or arrys
of these.
My application is supplying an argument in the form of an ArchiveItem
instance when calling the webservice:
// Argument bean
class BookItem
{
String Title;
String Publisher;
}
// Calling webservice
...lookup( ArchiveItem );
However, what if I wanted to plan ahead, knowing that probably soon I
will have to add another customer who wish to search by another field,
say Author. At the same time, I wish to let the existing customers use
their existing code and call the now "deprecated versions". By
implementation enheritance I could:
// Argument bean
class BookItemAdvanced extends BookItem
{
String Author;
}
// Calling webservice
lookup( ArchiveItemAdvanced );
This would solve the problem, but it requires implementing a new
(overloaded) webservice and introducing a potentially large versioned
hiarachy (Next extension would be BookItemSuperAdvanced...).
Is there a smarter way from a design perspective that does not simply
pass an interface; I am unable to pass/return interfaces over
WebServices pressumely because of serializabilty issues.
Thanks in advance,
Casper
| 
