views:

141

answers:

3

I am writing a logging service for one of my applications but I am sure many other applications would use this. In that case, would it make sense to make the application extend a class and have all my logging enabled by default (because some logging like application entry point and exit point are required at any cost) in the original class or just make the application instantiate a new logging object and then place logging statements wherever required?

+4  A: 

Instantiate a new logging object. Your objects are not loggers after all, are they?

If you inherit from logger, you additionally get the following problems

  1. Your object can be used as logger which is probably not what it is intended for
  2. You can't inherit from some other class
  3. You can't easily switch logging policy, especially in the runtime

In general, one should be really careful when it comes to drawing a generalization between two classes.

Dmitry
Thanks. I think the problems are clear to me.
Legend
+2  A: 

Rather than create a new logging service - why not use one of the logging frameworks out there? With all due respect - they will be better tested and better documented than anything you write!

I wouldn't go down the inheritance route, this ties you down at an early stage to a class that may well evolve and change.

Fortyrunner
You are right. I am better off using an existing logging library. The only reason I was thinking of this was because its not really a full blown logging service as such but also provides some project specific functionality. In any case, thanks for the reply.
Legend
A: 

In OOP you have to observe the law that an object gathers data and logic.

If your object have to do some task (service) or manipulate some data, it's OK. But it's not a logger.

You should fire an event to another service or object to do the log.

Also be careful at how your object knows about the logger... Injection, composition, factory... It's about your logging framework and your object tasks.

LDU