C# Interfaces – Implementing Multiple Disparate Interfaces in a Single Base Class

cinheritanceinterfaces

(This is probably a dupe, but if so I haven't seen it yet, although it may be Best practice for encapsulating a parameter that requires multiple interfaces to be implemented, but that question doesn't answer my situation)

Normally I don't care that c# only has single inheritance, but I have run into something where I think that multiple inheritance actually would improve things, and I can't see a clean way to do it with single inheritance.

This comes about from wanting to support both INotifyPropertyChanged and INotifyDataErrorInfo in a re-usable manner. These interfaces are independent and require a non-trivial amount of code to support them, and up until now I have only considered INotifyPropertyChanged and have a system of:

public class MyPropertyChangedBase : INotifyPropertyChanged
{
   // re-usable code to support INotifyPropertyChanged
}

public MyViewModel : MyPropertyChangedBase
{
  // various WPF bound properties that notify the UI on change
}

However, now I want to implement INotifyDataErrorInfo in a re-usable manner, but the code to support this interface is totally orthogonal and unrelated to the INotifyPropertyChanged code. So ideally they should be implemented in unrelated base classes and use multiple inheritance for my view model. EG (note this is NOT valid c# code – it is only for highlighting an 'idealistic' situation):

public class MyPropertyChangedBase : INotifyPropertyChanged
{
   // re-usable code to support INotifyPropertyChanged
}

public class MyErrorChangedBase : INotifyDataErrorInfo
{
   // re-usable code to support INotifyDataErrorInfo
}

public MyViewModel : MyPropertyChangedBase, MyErrorChangedBase
{
  // various WPF bound properties that notify the UI on change and error
}

(Note that I can't use composition to fix this, as I would need to map from the components to the public instances of the interface elements, which just shifts the problem and doesn't solve it)

So what I seem to be left with is having either the INotifyPropertyChanged code rely on the INotifyDataErrorInfo code or vice versa. EG

public class MyPropertyChangedBase : INotifyPropertyChanged
{
   // re-usable code to support INotifyPropertyChanged
}

public class MyPropertyAndErrorChangedBase : MyPropertyChangedBase , INotifyDataErrorInfo
{
   // re-usable code to support INotifyDataErrorInfo
}

public MyViewModel : MyPropertyAndErrorChangedBase
{
  // various WPF bound properties that notify the UI on change and error
}

This reliance of one independent class on another doesn't sit well with me. So is there a cleaner way to do it? Or am I stuck with it?

Finally, I do recognize that realistically you would not implement INotifyDataErrorInfo without first having implemented INotifyPropertyChanged, so the reliance of one class on the other may be a pragmatic tradeoff. But I am still trying to find the cleanest way of doing this.

Best Answer

As Greg has already mentioned, your two interfaces relate to the View. More specifically, they both relate to ViewModel<->View interactions. So, having one class implement both is not a big deal.

I do, however, understand that you might want to evolve the behaviour of each interface implementation independently, so how about this composition-based approach:

public abstract class MyPropertyChangedBase : INotifyPropertyChanged
{
    // re-usable code to support INotifyPropertyChanged
}

public abstract class MyErrorChangedBase : INotifyDataErrorInfo
{
    // re-usable code to support INotifyDataErrorInfo
}

public abstract class ViewModelBase : MyPropertyChangedBase
{
    // classic VM
}

public abstract class ErrorAwareViewModelBase : INotifyPropertyChanged, INotifyDataErrorInfo
{
    private readonly MyPropertyChangedBase changeNotifier;
    private readonly MyErrorChangedBase errorNotifier;

    public ErrorAwareViewModelBase(MyPropertyChangedBase changeNotifier, MyErrorChangedBase errorNotifier)
    {
        this.changeNotifier = changeNotifier;
        this.errorNotifier = errorNotifier;
    }

    event PropertyChangedEventHandler INotifyPropertyChanged.PropertyChanged
    {
        add
        {
            this.changeNotifier.PropertyChanged += value;
        }

        remove
        {
            this.changeNotifier.PropertyChanged -= value;
        }
    }

    bool INotifyDataErrorInfo.HasErrors => this.errorNotifier.HasErrors;

    event EventHandler<DataErrorsChangedEventArgs> INotifyDataErrorInfo.ErrorsChanged
    {
        add
        {
            this.errorNotifier.ErrorsChanged += value;
        }

        remove
        {
            this.errorNotifier.ErrorsChanged -= value;
        }
    }

    IEnumerable INotifyDataErrorInfo.GetErrors(string propertyName)
    {
        return this.errorNotifier.GetErrors(propertyName);
    }
}

Related Solutions

C# Design Patterns – Using Abstract Base Class with Interfaces as Behaviors

[1] Add virtual "getters" & "setters" to your properties, I had to hack another control library, because I need this feature:

abstract class Control
{
    // internal fields for properties
    protected int _Width;
    protected int _Height;
    protected int _BackColor;
    protected int _X;
    protected int _Y;
    protected bool Visible;

    protected int BorderWidth;
    protected int BorderColor;


    // getters & setters virtual !!!

    public virtual int getWidth(...) { ... }
    public virtual void setWidth(...) { ... }

    public virtual int getHeight(...) { ... }
    public virtual void setHeight(...) { ... }

    public virtual int getBackColor(...) { ... }
    public virtual void setBackColor(...) { ... }

    public virtual int getX(...) { ... }
    public virtual void setX(...) { ... }

    public virtual int getY(...) { ... }
    public virtual void setY(...) { ... }

    public virtual int getBorderWidth(...) { ... }
    public virtual void setBorderWidth(...) { ... }

    public virtual int getBorderColor(...) { ... }
    public virtual void setBorderColor(...) { ... }

    public virtual bool getVisible(...) { ... }
    public virtual void setVisible(...) { ... }

    // properties WITH virtual getters & setters

    public int Width { get getWidth(); set setWidth(value); }

    public int Height { get getHeight(); set setHeight(value); }

    public int BackColor { get getBackColor(); set setBackColor(value); }

    public int X { get getX(); set setX(value); }

    public int Y { get getY(); set setY(value); }

    public int BorderWidth { get getBorderWidth(); set setBorderWidth(value); }

    public int BorderColor { get getBorderColor(); set setBorderColor(value); }

    public bool Visible { get getVisible(); set setVisible(value); }

    // other methods

    public Rectangle ClipRectange { get; protected set; }   
    abstract public void Draw();
} // class Control

/* concrete */ class MyControl: Control
{
    public override bool getVisible(...) { ... }
    public override void setVisible(...) { ... }
} // class MyControl: Control

I know this suggestion is more "verbose" or complex, but, its very useful in real world.

[2] Add an "IsEnabled" property, do not confuse with "IsReadOnly":

abstract class Control
{
    // internal fields for properties
    protected bool _IsEnabled;

    public virtual bool getIsEnabled(...) { ... }
    public virtual void setIsEnabled(...) { ... }

    public bool IsEnabled{ get getIsEnabled(); set setIsEnabled(value); }
} // class Control

Means you may have to show your control, but don't show any information.

[3] Add a "IsReadOnly" property, do not confuse with "IsEnabled":

abstract class Control
{
    // internal fields for properties
    protected bool _IsReadOnly;

    public virtual bool getIsReadOnly(...) { ... }
    public virtual void setIsReadOnly(...) { ... }

    public bool IsReadOnly{ get getIsReadOnly(); set setIsReadOnly(value); }
} // class Control

That means the control can display information, but cannot be changed by the user.

C# Inheritance – Adding Base-Class Functionality to Uncontrolled Classes

Why don't you just use interfaces?

If you're concerned about sharing functionality, you can use extension methods to serve as your pseudo-base class. It's not exactly ideal, but it should get what you're looking for done.

Something along the lines of:

public interface IAnimalWithSuperPower {
    public SuperPower power { get; set; }
}

public class SuperCat : Cat, IAnimalWithSuperPower {
    public SuperPower power { get; set; }
    public SuperCat() {
        SuperPower = SuperPower.SuperStrength;
    }
}

public static void UseSuperPower(this IAnimalWithSuperPower animal) {
    animal.power.doSomething();
}

Best Answer

Related Solutions

C# Design Patterns – Using Abstract Base Class with Interfaces as Behaviors

C# Inheritance – Adding Base-Class Functionality to Uncontrolled Classes

Related Topic