I have just recently joined a new company and one of the classes used to log information has not been written properly. So I have been asked to add new functionality to the logger.

Rather than amending the Logger class I want to follow the O in SOLID and extend the class by creating a derived class and adding functionality that way. My issue however is, what do I name this derived logger class? NewLogger or LoggerTwo just seem like poor class names.

The functionality I am trying to extend is adding statuses to the log. So I could call it StatusLogger. But that doesn’t seem right either because the logger does more than log statuses. Any ideas?

  • What exactly do you mean by "add statuses"? Is there an extra parameter "status" passed at each "log" call? Would someone may come up with the requirement to activate or deactivate status logging at run time? Or is the idea to have two "log" members, one just with a text as parameter, and a second with text + status field? And what exactly are the specific use cases? Good naming is hard and requires context, and this question hardly provide enough context to let strangers like us make a good recommendation.
    – Doc Brown
    Aug 7, 2022 at 9:21
  • ... also, did you derive from the existing logger because you were not allowed to change the original loggers code? Or are you allowed, but just hesitating since you are "the new member" in the team?
    – Doc Brown
    Aug 7, 2022 at 9:25
  • The logger has a constructor that takes in the arguments to be logged. I want to add an additonal argument to allow the statuses to be logged. What status is doesnt really matter. Its just an additional parameter to be logged Aug 7, 2022 at 10:22
  • If there are no technical or organizational reasons which forbid to change the original logger code (in a backwards-compatible fashion, and with a low risk of breaking existing code, of course), then I am with Philip - it is probably best to keep the old logger and extend it's code. The fact you have problems with coming up with a new name is a clear sign you actually don't want a new logger abstraction, you want the old one extended, If there are, however, hard reasons which forbid to change the old code, use some arbitrary name like "ExtendedLogger" ...
    – Doc Brown
    Aug 7, 2022 at 10:29
  • ... or a name which indicates the specific context in which this new logger will be used (assumed their will be a specific context where only this new logger will be required). For example, if the new logger is part of ModuleFoo and only used there, you could name it FooLogger. That's why I am stressing the context here. Unfortunately, it seems you were too lazy to give more information, so I am voting to close ("needs details or clarity").
    – Doc Brown
    Aug 7, 2022 at 10:32

1 Answer 1


It sounds very much like you should just be fixing the bug in the original class, not creating a new one. Open-closed does not mean that you never fix bugs in the original class, it just means that it is possible to change it's behaviour without modifying it.

In this particular case, would anyone ever use the unmodified version of the class? If not, then there is no value in it without modifying, and no value in creating a new class.

  • 1
    This answer is fine, but let me stress that I would have written "Open-closed does not mean that you never change anything in the original class" (not just fixing bugs, that is what several people misunderstand). The OCP is about the design of the original logger, for making it possible to add new features / extensions.
    – Doc Brown
    Aug 7, 2022 at 9:00

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