Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Java design issue: Preparing for future extensions/versions...

72 views
Skip to first unread message

Casper B

unread,
Apr 1, 2005, 5:26:32 AM4/1/05
to
"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

0 new messages