[...]
public interface Notifier{ void notify(Object[] notifications); }
[..]
setNotifier(myNotifier);
[..]
addObserver(java.util.Observer o);
> But... this would mean that we would need a notification.jar that has the above interface. Interfaces are bad for API coupling.
That last a bit sweeping. Interface/impl separation is a good thing in general. Premature publication of an interface model is a bad thing.
My take is that the use of a simplified interface is neat in that it means that an evolving package will never cause compilation errors in user-community code. However, given it is a black-box, there would be nothing to stop it it breaking at /runtime/ if a slight difference occured on the arrays of objects being passed into the black-box.
The same thing another way - I'd like to be informed by the compiler that there is some subtle change in API. It helps me have high test coverage. Of course test coverage is irrelevant if your only view of monitoring is logging to a text file somewhere in a file system. My contention on testing and TDD is that logging (as a means to an ends) is not an API, thus not test-worthy.
Thus, I err towards a strong interface design and away from a loosely-coupled design like those above.
Regards,
- Paul
-- http://www.thoughtworks.com -> The art of heavy lifting. Home for many Agile practicing, Open Source activists...
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
