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 { }
}
}
A get property accessor is used to return the property value, and a set property accessor is used to assign a new value. In C# 9 and later, an init property accessor is used to assign a new value only during object construction. These accessors can have different access levels.
The set keyword defines an accessor method in a property or indexer that assigns a value to the property or the indexer element. For more information and examples, see Properties, Auto-Implemented Properties, and Indexers. The following example defines both a get and a set accessor for a property named Seconds .
In properties, a get accessor is used to return a property value and a set accessor is used to assign a new value. The value keyword in set accessor is used to define a value that is going to be assigned by the set accessor. In c#, the properties are categorized as read-write, read-only, or write-only.
An abstract class cannot be instantiated. An abstract class not only contains abstract methods and assessors but also contains non-abstract methods, properties, and indexers. It is not possible to modify an abstract class with the sealed modifier because the two modifiers have opposite meanings.
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;
}
}
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With