Notification and Logging

[ittai zeidman]

Hi,

I have a library where I pass a "reporter" to some of the key components in the library to report significant events.

Currently there are 5 events, 4 talk about error cases and one is kind of a heartbeat from the system.

I now wish to add two more events to the initialization and destruction of the library but I'm now not sure those aren't too many events on the same reporter.

On the other hand having multiple reporters seems a bit too much to me.

Would really appreciate your thoughts and feedback,

Ittai

[Steve Freeman]

I don't know what "too many" events is. What I have found with this approach, is that I tend to gather all the event types for a "module", whatever that means in the context, so that there's some coherence.

A thought. Is there a meaningful grouping around create/heartbeat/destroy that's separate from the error cases? Perhaps another thing to think about is the expected use cases for these events. Do they cluster in some interesting way?

S

[ittai zeidman]

Thanks for your prompt reply! For some reason I didn't get the email notification and just dropped by now and saw it.

I think you might have something when you say that maybe the create/heartbeat/destroy should be separate from the error cases.

Currently the events are:

• cannotCompleteFetchingFromRemote
• attemptingToFetchFromRemote
• cannotReadFromPersistentCache
• cannotWriteToPersistentCache
• cannotCompleteInitializingFromRemote
• initiatingShutdown
• startingInitialization
  

I can decide to have a LifecycleReporter and an ErrorReporter but these names sounds a bit too mechanical. WDYT?

On a related note it feels a bit like I'm violating the Interface Segregation Principle since every event currently is only used by one piece of the system but breaking it up to 3-4 reporters for each component seems too fine grained. Would love your thoughts about that too.

Again, sorry for not responding earlier,
Ittai

[sagy rozman]

One possibility is to move from a large Reporter interface to a simpler one containing a single method. Something like 

Reporter.report(Event)

In order to do that you would need a separate class per event so you would have

• CannotCompleteFetchingFromRemote
• AttemptingToFetchFromRemote
• CannotReadFromPersistentCache
• CannotWriteToPersistentCache
• CannotCompleteInitializingFromRemote
• InitiatingShutdown
  

Notice the capital letter indicating class names as opposed to method names. 

All these classes will need to implement the Event interface.

You can then use pattern matching or Double Dispatching in the Reporter's implementation to handle the different events.

This approach prevents the ISP violation and when using Double Dispatch (Visitor pattern) it will also maintain the Open Closed Principle since adding new events is a simple matter of adding a new event class without changing existing API.