[GOOS] 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

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.

[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

Post by 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

Post by ittai zeidman
I have a library where I pass a "reporter" to some of the key components

in the library to report significant events.

Post by ittai zeidman
Currently there are 5 events, 4 talk about error cases and one is kind

of a heartbeat from the system.

Post by ittai zeidman
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.

Post by ittai zeidman
On the other hand having multiple reporters seems a bit too much to me.

[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.

Post by 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.
- 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

Post by 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

Post by ittai zeidman
I have a library where I pass a "reporter" to some of the key

components in the library to report significant events.

Post by ittai zeidman
Currently there are 5 events, 4 talk about error cases and one is kind

of a heartbeat from the system.

Post by ittai zeidman
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.

Post by ittai zeidman
On the other hand having multiple reporters seems a bit too much to me.