C# – Should Utility Base Classes Be Avoided?

cinheritance

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.

Best Answer

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.

Related Solutions

C# Web Development – Sharing Methods and Properties Between Custom Web Controls

As I can't use true multiple inheritance in C#, how would I design this to be able to share the methods and properties?

This is the right way to share the methods and properties. But:

The trouble now is that in my extendedTextBox class I can't cast my extendedTextBox as a 'BaseExtendedControl' to use the extension methods, as the extendedTextBox inherits from the standard TextBox class like this:
public class ExtendedTextBox : TextBox, IExtendedControl
so there's no common base to cast ExtendedTextBox as 'BaseExtendedControl' as it doesn't inherit from it.

Yes, you're right there is no common class, but you can solve the problem by casting to the IExtentedControl interface which is common to your classes and contains the methods that you need. So what about:

public static class ExtendedControlHelper
{
    public static void AddRequiredFieldValidator(this IExtendedControl control)
    {
        control.rfv = new RequiredFieldValidator();
        control.rfv.ErrorMessage = control.RequiredMessage;
        ConfigureAndAddValidator(control, control.rfv);
    }

    public static void ConfigureAndAddValidator(this IExtendedControl control, BaseValidator validator)
    {
        validator.ControlToValidate = control.ID;
        validator.Display = ValidatorDisplay.Dynamic;
        validator.CssClass = "validationMessage ";
        validator.CssClass += control.ValidatorCssClass;
        validator.EnableClientScript = control.ClientScript;
        control.Controls.Add(validator);
    }
}

I don't think you need to implement the IExtendedControl interface in the ExtendedControlHelper class. Moreover I corrected the grammar of the interface name from IExtendendControl to IExtendedControl.

EDIT :

Another solution could be to use the dynamic keyword. The dynamic keyword is like object but the type is checked at run time instead of compile time:

public static class ExtendedControlHelper
{
    public static void AddRequiredFieldValidator(this dynamic control)
    {
        //...
    }

    public static void ConfigureAndAddValidator(this dynamic control, BaseValidator validator)
    {
         //...
    }
}

The dynamic type doesn't exist at run time because it's solved by the compiler, so if you write this: myExtendedTextBox.AddRequiredFieldValidator(); the method is solved as

//...
public static void AddRequiredFieldValidator(this ExtendedTextBox control)
{
    //...
}

and so on. So the type can change continuously at run time.

For more informations give a look here.

Using Protected Inheritance to Hide Implemented Interface in C++

We can establish that it is legal (i.e. valid) C++ because it compiles. You've used it on GCC and clang and I've done exactly same thing with MSVC++ so that covers the majority of the compiler market.
This is why protected/private (btw, I would use private) modifier was introduced. It allows your class to implement callback interfaces which are needed for other classes it is using internally, but a) the rest of the world doesn't need to know that you are using those other classes and b) the rest of the world should not be able to even call on any of those functions because they are meant to be hidden and used only by internals.

When I transitioned from C++ to C#, I actually felt weird that I couldn't have private interface inheritance. If something is an implementation detail and not intended to be seen/used by the public, it should be kept hidden and I think the method you described is a great and simple way of doing that.
Using pImpl just generates more overhead. When you allocate your objects (obviously assuming dynamic allocation), you end up going to the heap twice as many times. You also reduce the locality of your code because now View and ViewImpl might be in different pages in memory and will cause more cache misses. And you've increased the amount of boiler plate code you have to write because now you are forwarding all public interface calls from the View to ViewImpl.

This is all just my opinion but in the end, I cannot think of any reason not to have private interface inheritance. I've written code like this for 6+ years and never had any readability/maintainability problems because of it.

Best Answer

Related Solutions

C# Web Development – Sharing Methods and Properties Between Custom Web Controls

Using Protected Inheritance to Hide Implemented Interface in C++

Related Topic