Re: [MO-java-users] any pattern for this?

[Steve F. <st...@m3...>]

J. Xue wrote:
> Sometimes, it does make sense to define an abstract interface between
> a client and its vendor, but not all the time, especially when the
> usage of the vendor requires strong assumptions.  In this castor
> case, castor's (rather intrusive) usage paradigm has made a lot of
> impact on my code, e.g., all the classes handled by the marshalling
> engine must have either public getters/setters or have their own
> castor-dependent handlers.  Another example is that I had to make
> special wrapper classes simply because the XML unmarshaller cannot 
> effectively unmarshal a map.  From the design point of view, it would
> be just illusional to have an "un/marshaller interface" and pretend
> to have the ability to "plug in" another un/marshaller.

that's true, I think we were talking about a higher level interface that
has meaning in your domain. It might even be worth distinguishing
between "Castor" objects which are wrapped by "domain" objects.
Actually, that's not a bad idea given that the Castor objects have this
marhshalling baggage. Alternatively, you might want to have some kind of
common factory object that gets passed around and wraps the castor
infrastructure.

> Well, my question is, then, do mock objects drive, or do they
> actually *force* the design? Following this pattern, wouldn't I have
> to define interfaces for every 3rd party class I use that does not
> support a factory, in order to be able to plug in my own mocked
> version of those classes?

See above, maybe there's a thin veneer that converts between state 
(managed by Castor) and behaviour (which is yours).

S.