Should utility base classes be avoided

Question

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

EDIT:

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 = 
              LogManager.GetLogger(typeof(LogTest2));

    static LogTest2()
    {
        DOMConfigurator.Configure();
    }

    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.

However:

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.

Interface

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.

Answer 1

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.

Answer 2

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.)

Answer 3

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.