Knowing that C# doesn't support multiple inheritance, is it considered bad form to write a utility base class?

Some initial thoughts:

  • I could create an interface and a concretion, but then the implementation isn't portable
  • Should the developer need to extend the class in say, a decorator pattern, they could implement this new class and inherit the base class in their new class


N.B. I'm not talking about vanilla inheritance here e.g. poodle<--dog<--mammal<--animal

More this sort of thing (lifted from here):

    using log4net;
    using log4net.Config;

    public class LogTest2
        private static readonly ILog logger = 

    static LogTest2()

    static void Main(string[] args)
        logger.Debug("Here is a debug log.");
        logger.Info("... and an Info log.");
        logger.Warn("... and a warning.");
        logger.Error("... and an error.");
        logger.Fatal("... and a fatal error.");

If I were to drop this into say, a WCF service, it would be expedient for the private member variable, constructor and perhaps some wrapper methods to sit in a base class to save cluttering up the service code (and make it reusable).

So far, so dull.


What if I wanted to add some other sort of logging not supported by log4net? E.g. Acme Corp provide some class to iMessage the support team if an issue occurs.

Base class

Had I implemented the log4net stuff in a base class, I'd then have to create some new master base class that supports both classes and inherit this.


I could implement an interface but the concretion would still be in the service code which we're trying to avoid. Acme Corp's class can of course now drop straight in but we're implementing two sets of code which do very similar things in different ways.

  • 2
    Umm, what? This isn't very clear.
    – Telastyn
    Mar 13, 2014 at 16:45
  • Writing base classes is what polymorphism is all about.
    – Bobson
    Mar 13, 2014 at 17:14
  • I guess what bugs me is the case where I need to inherit a class and there is already a base class. I have to then create a parent to inherit the original base. This seems like cruft to me. Just wondering if given the opportunity whether you should always prefer an interface if you're writing the initial code.
    – Robbie Dee
    Mar 13, 2014 at 19:12
  • @RobbieDee: It very much depends on what you're doing. Just because you're designing a breed of Horse with green fur does not mean it should inherit from Tree. Both might have LeafGreenBrushs, though. You have to be very careful deciding what gets inherited. Think carefully about whether something really needs to inherit from a second parent. If the class is well designed and does one thing, it probably doesn't need to.
    – Magus
    Mar 13, 2014 at 19:50
  • OK, I've added an example by way of clarification
    – Robbie Dee
    Mar 13, 2014 at 22:26

3 Answers 3


I think you are on the road to a very often seen form of wrong use of inheritance. If you want a class X which uses an exchangeable type of logger, inject an object of type ILog by passing it as a constructor parameter. If your logger needs specific initialization, create a specific logger, inherited from ILog. Don't bury the logger initialization in some kind of artifical base class A of X, in attempt to make this reusable. The latter would actually work against reusability (and testability) of X, and also against the reusability of your specific logger outside of the context of X.


I could create an interface and a concretion, but then the implementation isn't portable

There's a design trade-off between using a sealed class (or a class with a finite number of subclasses) and interfaces. With a sealed class, you have the same implementation everywhere in the program. With an interface, you gain the flexibility of having alternative implementations, but you have to hope every implementation is correct; a particular part of the program could be using Implementation A which is correct, while another part may rely on the same interface but be using buggy Implementation B.

So, no, having a dependency on a concrete class isn't inherently a bad thing.

(As for unsealed classes, these behave similarly to interfaces in that you have to trust that all subclasses are correct, but are not as flexible as interfaces and run the risk of the Fragile Base Class Problem.)

Should the developer need to extend the class in say, a decorator pattern, they could implement this new class and inherit the base class in their new class

If you need this kind of extensibility, then use an interface. You should forbid inheritance unless you design your class for it (and you probably don't want to if you can avoid it at all, because composition is, well, more composable.)


I would recommend the interface and the concretion. The implementation can still be portable through the use of delegation, ie. another class implementing the interface can get a hold of an instance of the concrete version and delegate to it when it needs to use the concrete functionality. This provides a greater flexibility if you really expect implementing/sub-classes to need to inherit from multiple other sources.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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