Bob Scheifler wrote:
Rick Moynihan wrote:
Briefly, my main issue with these classes (and I guess other parts of
Jini) is that code which uses these classes is hard to unit test
because they don't have interfaces.
If the issue is just unit testing, what prevents you from simply writing
your own alternate implementations of the classes and linking them in?
I know the question was for Rick, but nevertheless I like to take the
opportunity to react.
Around the 'expectation' the contract of some important functionality is
specified as an interface a bunch of tools have been developed, for
example a product such as EasyMock (for more info read
http://today.java.net/pub/a/today/2006/06/20/getting-started-with-easymock-2.html,
haven't used it so don't know whether it is handy or not). Also things
as Google Guice and other DI frameworks most times use in their examples
interfaces instead of classes that can be extended, resulting in a
mindset that interfaces is what people expect for DI (note I'm not
saying this is correct).
But my main argument against alternate implementations (by extension
that is), is that you often end up with those nasty constructors that
require proper arguments which you don't have or don't want to provide
or that even might fail at construction time. Together with all the
environmental assumptions that lie in the implementation of the class
you are extending, also you might drag in a lot of code just because of
the implementation.
Interfaces gives an ultimate freedom and allow for minimal dependencies
and I don't see why we can't factor out some of the functionality of SDM
e.g. into an interface, do you Bob?
--
Mark
