Architectural issue (Singleton?)

  • Thread starter Thread starter Giulio Petrucci
  • Start date Start date
G

Giulio Petrucci

Hi everybody,

I have class library used by an application to log it's activity. This
application has got several Plug-Ins, and all these Plug-Ins use the same
library to log their activity. As the application logs everything on the
same log file for each day, I implemented a LogManager that's actually a
Singleton, in order to manage concurrent accesses on daily log files.
For each running Plug-In the LogManager creates a LogSession, that's
actually nothing more than a buffer, in which the running Plug-in writes
its log entries. When a Plug-In has finished its work, it closes its
LogSession, that rises an event (LogSessionClosed), the event is caught
from the LogManager that writes the content of the closed LogSession on the
current log files (I think it's quite simple and intuitive...).

Now, I have to write a new Plug-In, made by several interoperating objects,
and I need all of them to be able to log their activity. So I'll have a
general Client class which ask the LogManager for a new LogSession object.
Within this Client object, I'll have a lot of SubClient objects. What can I
do, in order to make them log on the same LogSession? I have three
solutions (may be all wrong :-) ):

A) add a LogSession argument to all the SubClient class constructors;
B) add to each SubClient class an event LogSomething: they rise this event
when they want to log anything, the Client class catch it and log on the
LogSession (actually I think this is the most flexible implementation,
anyway, because of the tipically high number of log entries I think this
approach can depply impact the application performances...);
C) build a sort of Singleton within the main Client class, so that each
SubClient can refer to the same LogSession object... Actually I cannot
either think to a way to implement such a solution: how can I create a
Singleton (that's a static class) using a non-static instance (the
LogSession object)?

Do you have any suggestion?
Thanks in advance!
Kind regards,
Giulio - Italia

--
 
Giulio,

Personally, I would go with B), because it doesn't couple your class
with the log provider as A) and C) does. The event doesn't necessarily have
to be "LogSomething", but rather, if the component exposes events, then your
client class can subscribe to them and log the appropriate information.

Hope this helps.
 
Giulio,

Personally, I would go with B), because it doesn't couple your class
with the log provider as A) and C) does. The event doesn't necessarily have
to be "LogSomething", but rather, if the component exposes events, then your
client class can subscribe to them and log the appropriate information.

Hope this helps.
Click to expand...

Just to show there's another point of view, I'd personally go with
something like A. Instead of passing the LogSession object though, I'd
pass some kind of ILogger interface instead, which would allow you to
swap out logging mechanisms with ease.

If you could really get away with not having a LogSomething event, then
I'd be more likely to agree with Nicholas here, but in my experience the
sub-clients are going to want to log things that don't correspond well
to other events.
 
Back
Top