Paul Hammant wrote, On 02/04/2003 23.56:
Folks,
So, to simplify the most what about changing the following
public interface ServerMonitor {
void closeError(Class clazz, String s, IOException e);
void badConnection(Class clazz, String s, BadConnectionException bce);
void classNotFound(Class clazz, ClassNotFoundException e);
void unexpectedException(Class clazz, String s, Exception e);
void stopServerError(Class clazz, String s, Exception e);
}
To a
public interface Notifier{ void notify(Object[] notifications); }
and
setNotifier(myNotifier);
Those two approach are really similar to the way it is done in aspect-oriented programming. In fact the only thing it changes is the coupling as it does not mandate the comp developper to tangle his code with the monitor/notifier calls.
where the notifications are any object, that the implementation can decide to use or not. Exceptions for example would be typical notifications for example.
Object r�ification of the message call would be very practical here, and an ease for evolution.
For instance:
notify(new CloseErrorMessage(this, CloseError.SOCKET_CLOSED));
Logging orders are just transmitted via Message objects with a log() method to different logging subsystems. Those do then decide whether to call error(), info() or debug() and what target to use, etc...
And those can build together a chain of responsability for example.
Exception are a good candidate in deed yes but IMHO maybe those are too negative. I see logging like the exposition by the component of its state. Most of the time it is error reporting. But there would have use cases where exposition of the component state is about exceptional situtation yet not erroneous. (However it is possible, and many do, to use exception for positive exceptional situations.)
This would really decouple.
But... this would mean that we would need a notification.jar that has the above interface. Interfaces are bad for API coupling.
The simplest solution would be to adopt an interface from standard Java API. Example:
addObserver(java.util.Observer o);
Does this concept have legs? My feeling is that application coders choose a logging mechanism, but bean/comp coders should not do so. My proof for the this is born from TDD. Why log? - You don't test the textual output to a logger? If you do it is pointless testing it as no deterministic use of that textual dump is ever coded. for a bean/comp user. Much better a monitor.
What about a standard JDK java.util.Observer?
Yes and EventObjects may be also good candidate. However IMHO they do not render the instantaneous apparition of such situation.
The join point reflective object is such a thing in aspect-oriented programming. Thus you may take profit of it for doing logging or what ever thing. You just have to take the appropriate decision depending on what the situation is. This would really decouple. However you certainly find the need to have aspects every time too much coupling.
Nevertheless, in an aspect, i would use an API to log too. I was thinking of using LogEnabled/Logger pattern. But if such a API exists that is reified as Nicolas suggests it, i would be the first to use it. ;)
...
Does anyone want to help me crisp this up?
How can we ?? Would like to/could help too.
A+. Didier.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
