C# – Is it ok to have an empty abstract class to make concrete classes polymorphic

cinheritanceinterfacesobject-orientedpolymorphism

BEFORE:

I have an interface that has one method definition

public interface IDockable
{
    void Dock(DockerContainerConfig config);
}

Everything is ok for my first implementation

public class DockerContainer : IDockable
{
    public void Dock(DockerContainerConfig config)
    {

    }
}

public class DockerContainerConfig
{ 
    //machine configuration properties here 
}

On my second implementation however, I realized that I need to use a different set of configuration.

public class DockerMachine : IDockable
{
    public void Dock(DockerMachineConfig config)
    {

    }
}

public class DockerMachineConfig
{
    //machine configuration properties here 
}

AFTER:

In order to make the Configuration Classes polymorphic, I created a parent class and let the Configuration Classes inherit from it.

public class DockerConfig
{

}

public class DockerMachineConfig : DockerConfig
{
    //machine configuration properties here 
}

public class DockerContainerConfig : DockerConfig
{
    //container configuration properties here 
}

With this I also changed the method definition for the interface.

public interface IDockable
{
    void Dock(DockerConfig config);
}

And in my concrete classes, I just did a cast on the configuration class objects. Please note that the two configuration classes are totally different, nothing is common. One deals with the machine so it needs machine configuration and the other deals with the container so it needs container configuration. But either way you do it, DockerContainer and DockerMachine does the same thing. "dock a container inside a machine". It's something like DockerMachine does things from the outside and DockerContainer does things from the inside. You get the idea 🙂

public class DockerContainer : IDockable
{
    public void Dock(DockerConfig config)
    {
        DockerContainerConfig container = config as DockerContainerConfig;
    }
}

public class DockerMachine : IDockable
{
    public void Dock(DockerConfig config)
    {
        DockerMachineConfig machine = config as DockerMachineConfig;
    }
}

There are two things that I think I made a mistake here:

I changed the method definition in my interface from void Dock(DockerContainerConfig config); to void Dock(DockerConfig config);
I created an empty parent class public class DockerConfig{} just to be able to make my Configuration Classes polymorphic

I would like to know if the changes I made conforming to good design and best practices.

Best Answer

public interface IDockable<T>
{
    public void Dock(T config);
}

By having a type parameter, you can specify the parameter you want to accept within the Dock method in your classes. Example:

public class DockerMachine : IDockable<DockerMachineConfig>
{
    public void Dock(DockerMachineConfig config)
    {
    }
}

public class DockerContainer : IDockable<DockerContainerConfig>
{
    public void Dock(DockerContainerConfig config)
    {
    }
}

That would be my personal preferred way to do this, but there are plenty of other ways which you'll be able to come up with. What you're currently doing could definitely be simplified by having a type parameter on the IDockable interface which would be a little bit cleaner in my opinion.

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