2

I want to add a logging mechanism to my project but I am afraid to have logging code spread all over the place.

I thus had the idea of having only one class Logger responsible for writing relevant information into the log, and all the other classes A, B, ... having a Logger object and just calling the corresponding logging function in that one Logger class instead of implementing logging function in classes A, B, directly.

class A {
  public:
    Logger logger;
    ...
    void foo {
       ...
       logger.log(this);
    }
};

...

class Logger {
  public:
    void log(A a);
    void log(B b);
...

};

Is that considered good practice or what is a clean way of doing logging without cluttering the production code?

5
  • Yes, this is a good practice. Your logging class would have a single responsibility, help to remove code duplication and centralize logic.
    – JDT
    Aug 10, 2015 at 7:04
  • 1
    It'd be even better if you can use one of the freely available log4* classes in your code to avoid writing a new Logger class at all.
    – imel96
    Aug 10, 2015 at 7:23
  • The log4net log4cpp log4J (etc) libraries are very good indeed, fast and simple and still very configurable. If you're even thinking of writing your own wheel, then you're probably don't understand the problem.
    – gbjbaanb
    Aug 10, 2015 at 7:39
  • 1
    @imel96 thank you for your comment. I was afraid that my question is ambiguous: I do use an available logging library, but I still need to format the values I want to log, and my question was w.r.t. the place this formatting should be done.
    – 1v0
    Aug 10, 2015 at 13:38
  • @1v0: What language are you using? The best practices usually differ for different languages. Aug 20, 2015 at 12:56

2 Answers 2

3

I would heavily recommend against this design. You are creating a cyclic dependency between your project's individual classes A, B, C, ... and your Logger class, which makes your Logger unusable in other projects or in components of your project which shall not depend on A, B and C. Moreover, whenever you are going to add a new class which needs logging, you will not only have to chance that class, but also the Logger. And if you ever want to put the Logger into a separated, reusable library, you get a cyclic dependency between that lib and the library where A, B, C live (luckily, in languages like C# the latter is forbidden).

That is exactly the way to the well-known "big-ball-of-mud architecture".

2

It's worth the time to learn the log4* library, e.g., for reasons like hierarchical logging, filters, different output formats or targets (files, databases, instant messengers, ...).

But it will not remove the logging statements from your code, just a good starting point. To minimize logging code, you could either try Aspect Oriented Programming, that "weaves" statements into functions that match a specific pattern, or...

You could take advantage of your software architecture: Some architectures allow logging code at central sensitive points, e.g. message dispatchers or Dependency Injection containers etc. IMHO it's a good idea to centralize exception handling (using a "security facade" pattern). This would make another central point for error logging.

Just some options.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.