C# Design Patterns – Using Abstract Properties in Base Classes

abstract classcdesign-patternsvisual studio

I'm coding with a state pattern for an embedded device. I have a base/abstract class called State and then each discrete(concrete) state class implements the abstract State Class.

In the State Class I have several Abstract Methods. If I don't implement the abstract methods in the discrete(concrete) class, Visual Studio will give an error something like this:

…Error 1 'myConcreteState' does not implement inherited abstract member 'myAbstractState'

Now: I'm trying to create a String property for each State called StateName. Whenever I create a new concrete class, I need to define StateName. I want VS to throw an error if I don't use it. Is there a simple way to do this?

I've tried this in the abstract/base class:

public abstract string StateName { get; set; }

But I don't need to implement the Get and Set methods in each State.

Revised Question:
In an ideal situation, each State Class would be required to have StateName defines and be inherited from the abstract base class.

StateName = "MyState1"; //or whatever the state's name is

If that statement is missing then Visual Studio will generate an error as described above. Is this possible and if so, how?

Best Answer

I guess the "correct" way to do this is to have a protected constructor on the base class which requires the state name as a parameter.

public abstract class State
{
    private readonly string _name;

    protected State(string name)
    {
        if(String.IsNullOrEmpty(name))
            throw new ArgumentException("Must not be empty", "name");

        _name = name;
    }

    public string Name { get { return _name; } }
}

The concrete states then provide a public constructor which implicitly calls the base class constructor with the appropriate name.

public abstract class SomeState : State
{
    public SomeState() : base("The name of this state")
    {
        // ...
    }
}

Since the base class does not expose any other constructors (neither protected nor public) each inheriting class needs to go through this single constructor and thus needs to define a name.

Note that you don't need to provide the name when you instantiate a concrete state because its constructor takes care of that:

var someState = new SomeState(); // No need to define the name here
var name = someState.Name; // returns "The name of this state"

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# – Empty virtual method on base class VS abstract methods

In this case the base class should know nothing of SectionA. The derived class should implement the extra properties that that type needs.

For certain operations where another class needs to pull information out regardless of the type of document you will want that method on the base class ideally virtual with a basic implementation and allow derived classes to override it if needed (eg ToPlainText which would just output all the sections of a document would be on Document, FancyDocument can override the implementation to also output SectionA).

For instances where another class doesn't care about the type of document but does care if it has certain properties use interfaces. IDocument would have all the common sections and Document would implement it. IDocumentWithSectionA would inheerit IDocument and FancyDocument would implement that. This then lets you derive another NeitherFancyNorNotFancyDocument that has SectionA which can also implement IDocumentsWithSectionA.

Obviously You'd have more useful names than IDocumentWithSectionA but that depends on the usecase.

TL;DR use the abstract class for what should be common to all documents and some common functionality, use interfaces as the contract saying what a document has.

Best Answer

Related Solutions

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

C# – Empty virtual method on base class VS abstract methods

Related Topic