Adding a set accessor to a property in a class that derives from an abstract class with only a get accessor

Question

I have an abstract class, AbsClass that implements an interface, IClass. IClass has a couple properties with only Get accessors. AbsClass implements the properties of IClass as abstract properties to be defined in the classes that derive from AbsClass.

So all of the classes that derive from AbsClass will also need to satisfy IClass by having the same properties with Get accessors. However, in some cases I want to be able to add set accessors to the properties from IClass. Yet if I try to override the abstract properties in AbsClass with a set accessor I get this error

ConcClassA.Bottom.Set cannot override because AbsClass.Bottom does not have an overridable set accessor

See ConcClassA below.

If I have a class that is only implementing the IClass interface, but not inheriting from AbsClass then I am able to add a set accessor with out problems. See ConcClassB below.

I could just implement IClass at each derivation of AbsClass rather then directly for AbsClass. Yet I know from my design that every AbsClass needs to also be an IClass so I'd rather specify that higher up in the hierarchy.

public interface IClass
{
    double Top
    {
        get;
    }
    double Bottom
    {
        get;
    }
}

abstract class AbsClass:IClass
{
    public abstract double Top
    {
        get;
    }

    public abstract double Bottom
    {
        get;
    }
}



class ConcClassA : AbsClass
{
    public override double Top
    {
        get { return 1; }
    }

    public override double Bottom
    {
        get { return 1; }

        //adding a Set accessor causes error:
        //ConcClassA.Bottom.Set cannot override because AbsClass.Bottom does not have an overridable set accessor

        //set { }
    }

}

class ConcClassB : IClass
{
    public double Top
    {
        get { return 1; }
        //added a set accessor to an interface does not cause problem
        set { }
    }
    public double Bottom
    {
        get { return 1; }
    }
}

---

Update

So I think this will make more sense if I explain exactly what I'm trying to do rather then using the abstract example. I work for an Architecture firm and these are business objects related to an architectural design project.

I have an abstract class RhNodeBuilding that represents one type of building on a project. There is some general functionality, like the ability to have floors, that is defined in RhNodeBuilding. RhNodeBuilding also inherits from another abstract classes that allow it be part of a larger project tree structure.

RhNodeBuilding implements from an interface IBuilding which defines a number of read only properties that all buildings should be able to provide such as TopElevation, BottomElevation, Height, NumberOfFloors, etc..etc.. Keep in mind there are other building types that do not derive from RhNodeBuilding, but still need to implement IBuilding.

Right now I have two types that derive from RhNodeBuilding: MassBuilding and FootPrintBuilding. MassBuilding is defined by a 3D shape created by the user. That shape has a TopElevation and a BottomElevation that should be accessible through the corresponding properties, but you shouldn't be able to edit the 3D volume by changing the properties.

FootPrintBuilding on the other hand is defined by a closed curve and a height range to extrude that curve through. So not only should the class be able to return what the current elevations are but these elevations should also be able to be changed to redefine the height range.

So in summary. All buildings (IBuildings) need to be able to return a TopElevation and BottomElevation, but not all buildings should allow TopElevation or BottomElevation to be set directly. All RhNodeBuildings are IBuildings, and classes that derive from RhNodeBuilding may or may not need to be able to directly set TopElevation and BottomElevation.

public interface IBuilding
{
    double Top
    {
        get;
    }
    double Bottom
    {
        get;
    }
}

abstract class RhNodeBuilding:IBuilding
{
    public abstract double Top
    {
        get;
    }

    public abstract double Bottom
    {
        get;
    }
}



class MassBuilding: AbsClass
{

   //mass building only returns Top and Bottom properties so it works fine
    public override double Bottom
    {
        get { return 1; }
    }

    public override double Top
    {
        get { return 1; }
    }

}


class FootPrintBuilding: AbsClass
{
    //Top and Bottom of FootPrintBuilding can both be retrieved and set
    public override double Top
    {
        get { return 1; }
        //adding a Set accessor causes error:
        //cannot override because RhNodeBuilding.Top does not have an overridable set accessor

        //set { }
    }

    public override double Bottom
    {
        get { return 1; }

        //adding a Set accessor causes error:
        //cannot override because RhNodeBuilding.Bottom does not have an overridable set accessor

        //set { }
    }

}

Right now it seems like the best option is to not have RhNodeBuilding implement IBuilding, but rather have every class that derives from RhNodeBuilding implement IBuilding. That way I can define the properties from IBuilding directly rather then as overrides.

abstract class AltRhNodeBuilding
{
    public abstract double Top
    {
        get;
    }
}


class AltFootPrintBuilding: IClass
{
    public override double Top
    {
        get { return 1; }

       //Can't add set access to overridden abstract property
        set { }
    }

    //No problem adding set accessor to interface property
    public double Bottom
    {
        get { return 1; }
        set {  }
    }
}

Answer 1

This works the way it does because properties aren't truly virtual - their accessor methods are. Thus, you cannot override set if there wasn't one in the base class.

What you can do is override and shadow the base class implementation, and provide your own new read/write properties. I don't know of any way to do this without introducing an additional class in the hierarchy:

class AbsClassB : AbsClass
{
    public override double Top { get { return ((ConcClassB)this).Top } }
    public override double Bottom { get { return ((ConcClassB)this).Bottom } }
}


class ConcClassB :  AbsClassB
{
    new public double Top
    {
        get { ... }
        set { ... }
    }

    new public double Bottom
    {
        get { ... }
        set { ... }
    }
}

A better idea would be to define a protected virtual method right in AbsClass, and implement Top.get and Bottom.get in terms of that method. Then you can override that method directly in ConcClassB, and shadow the properties, without the need for an extra class:

abstract class AbsClass : IClass
{
    public double Top
    {
        get { return GetTop(); }
    }

    public double Bottom
    {
        get { return GetBottom(); }
    }

    protected abstract double GetTop();

    protected abstract double GetBottom();
}

class ConcClassB :  AbsClass
{
    new public double Top
    {
        get { ... }
        set { ... }
    }

    new public double Bottom
    {
        get { ... }
        set { ... }
    }

    protected override double GetTop()
    {
        return Top;
    }

    protected override double GetBottom()
    {
        return Bottom;
    }
}

Answer 2

I am kind of curious as to why you would want these implementation classes to have public setter methods that are not part of the public interface. It sounds to me like you may actually want these to be more restricted than public?

Other than that, I'm having a hard time thinking of a problem with this approach. They would "hide" any properties from the superclass, but there are no property setters in the superclass anyway, so that seems ok. It seems like it may be the simplest workaround.

Answer 3

Use a global variable.