Why is it allowed to change the visibility and existence of getters or setters in a property when implementing an interface?
interface IFoo
{
string Bar { get; }
}
class RealFoo : IFoo
{
public RealFoo(string bar)
{
this.Bar = bar;
}
public string Bar { get; private set; }
}
class StubFoo : IFoo
{
public string Bar { get; set; }
}
...and not legal to do the same when implementing an abstract class?
abstract class AbstractFoo : IFoo
{
public abstract string Bar { get; }
}
class RealFoo : AbstractFoo
{
public RealFoo(string bar)
{
this.Bar = bar;
}
// Cannot override because 'Bar' does not have an overridable set accessor
public override string Bar { get; private set; }
}
The interface declares what public properties the class must have (It's just a contract). Which means you need to have those properties, but can add to them.
The abstract class declares the actual structure of those properties. So if you don't have the setter in the abstract base, you can't add to it in the implementation.
When you write the override modifier it looks in the base class for something to override.
It perhaps becomes clearer if you think of the getters and setters as the methods that they eventually become.
In the case of the interface you are defining this:
interface IFoo
{
string GetBar();
}
Which can be read as "all classes that implement this interface must include this method."
Both of your classes do:
class RealFoo : IFoo
{
public string GetBar();
private void SetBar(string value);
}
they also implement SetBar(), but that is immaterial; they have fulfilled the contract defined by the interface and are valid.
The abstract class, on the other hand is this:
abstract class AbstractFoo : IFoo
{
public abstract string GetBar();
}
Which means that all child classes must provide a method body for GetBar()
The class you made is this:
class RealFoo : AbstractFoo
{
public override string GetBar();
public override void SetBar(string value);
}
By putting the override modifier in front of the SetBar method the compiler is expecting to find an abstract or virtual version in the base class. You don't have that so the compilation fails.
An abstract class is a class that cannot be instantiated, but must be inherited from. An abstract class may be fully implemented, but is more usually partially implemented or not implemented at all, thereby encapsulating common functionality for inherited classes.
An interface, by contrast, is a totally abstract set of members that can be thought of as defining a contract for conduct. The implementation of an interface is left completely to the developer.
Taken from the MSDN
http://msdn.microsoft.com/en-us/library/scsyfw1d(v=VS.71).aspx
According to the C# specification
An accessor that is used to implement
an interface may not have an
accessor-modifier. If only one
accessor is used to implement an
interface, the other accessor may be
declared with an accessor-modifier:
public interface I
{
string Prop { get; }
}
public class C: I
{
public Prop {
get { return "April"; } // Must not have a modifier here
internal set {...} // Ok, because I.Prop has no set accessor
}
}
That means it is OK to have an access modified on a class implementing the interface. However, the abstract class declares an implementation and you cannot change that with a derived class.
Related
Consider the following class definition.
public abstract class FooBase : IBar
{
public int Value {get; set;}
public string ToString()
{
//Return a string.
}
}
public interface IBar
{
int Value;
string ToString();
}
FooBase is a base class that provides implementation of the IBar interface.
As an abstract class, FooBase cannot be directly instantiated. Therfore, another class must derive from this class for it to be useful.
Now, consider the scenario where you need an object like FooBase that implements the the IBar interface, however, for once specific member IBar you need the children of FooBase to implement it, not FooBase itself.
Is there a way to implement/address a member in an abstract class like FooBase, derived from IBar, in such a way that any child of FooBase must implement a single member from IBar, rather than relying on the base implementations of FooBase?
I assume there isn't because the compiler is telling that declaring a value like public abstract int Value is not allowed but I figured it was worth asking and verifying. But, maybe I'm wrong and if so, is there a proper way to force the child implementation of my base class to implement a member from a parent interface on my base?
assume there isn't because the compiler is telling that declaring a value like public abstract int Value is not allowed
Of course it is allowed, this compiles perfectly fine:
interface IBar
{
int Foo { get; set; }
string Blah();
}
abstract class Base: IBar
{
public abstract int Foo { get; set;}
public string Blah() => null;
}
And now:
class Derived: Base
{
//must implement Foo
}
Your code by the way doesn't compile, you can't define fields in an interface.
This compiles just fine:
public abstract class FooBase : IBar
{
public abstract int Value { get; set; }
}
public interface IBar
{
int Value { get; }
}
Any class that derives from FooBase must override Value:
public class Concrete : FooBase
{
public override int Value { get; set; }
}
As per title, and just to deeper understand the reasons, why does in c# interface forces you to manually implement the its members, whereas abstract class doesn't?
I found Reasons not to use abstract class instead of interface?, but it seems to cover just part of the answer exhaustive.
public abstract class Bar
{
public int MemberA {get;set;}
public string MemberB {get;set;}
}
public interface IBar
{
public int MemberA {get;set;}
public string MemberB {get;set;}
}
Implement this is fine:
public class Foo1 : Bar
{
}
Implementing this raises a compile error:
public class Foo2 : IBar
{
}
Error:
'Foo2' does not implement interface member 'IBar.MemberA'
'Foo2' does not implement interface member 'IBar.MemberB'
I have the following class with some methods and I would like to use this as a base class of another class.
public class BaseClass
{
public string DoWork(string str)
{
// some codes...
}
// other methods...
}
I don't want this class to be instantiated, but the derived class should still use the original implementation of the methods of its base class.
Is it possible? What should be my modifier?
Since you don't want this class to be instantiated, make it an abstract class. You can still have implementation on the class.
abstract
snippet,
public abstract class BaseClass
{
public virtual string DoWork(string str)
{
// can have implementation here
// and classes that inherits can overide this method because of virtual.
}
// other methods...
}
Make BaseClass abstract:
public abstract class BaseClass
{
// Only available to BaseClass
private string _myString;
public string DoWork(string str)
{
// Available to everyone
return _myString;
}
protected void DoWorkInternal() {
// Only available to classes who inherit base class
}
}
This way, you can define your own code within BaseClass - but it cannot be initialized directly, it must be inherited from.
I have the following class hierarchy:
public abstract class BaseClass : IBaseInterface
{
public int PropertyA{
get
{
return this.propertyA;
}
set
{
this.propertyA = value;
// ... some additional processing ...
}
}
}
DerivedClassB : BaseClass
{
// some other fields
}
public class ContainingClassC
{
public IBaseInterface BaseInterfaceObjectD
{
get;
set;
}
}
Now, in order to access PropertyA of a DerivedClassB-Object (inherited from BaseClass), I have to cast the object to BaseClassA's ancestor, like so:
// This ContainingClassC is returned from a static, enum-like class:
// containingObject.PropertyA is DerivedClassB by default.
ContainingClassC containingObject = new ContainingClassC();
((IBaseInterface)containingObject.BaseInterfaceObjectD).PropertyA = 42;
Is there a way I can restructure these classes to do away with the cast? This code is part of a library, and my colleague wants me to get rid of the cast.
The goal is to simply write containingObject.BaseInterfaceObjectD.PropertyA = 42.
First of all in the line ((IBaseInterface)containingObject.BaseInterfaceObjectD).PropertyA = 42; you are casting the member to the same type that it is declared in, so the casting doesn't actually do anything.
To be able to access the PropertyA in the derived class - since you are casting it to an interface - the property must be declared in the interface and then implemented in the BaseClass.
public interface IBaseInterface{
int PropertyA{get;set;}
}
public abstract class BaseClass : IBaseInterface{
public int PropertyA{
get{ return this.propertyA;}
set {this.propertyA = value;}
}
}
As long as the interface is implemented properly, ProprtyA should be available in the base class, the derived class or with either of them cast'ed to the interface type.
If it's just a problem of the property not showing up in IntelliSense, then it might be a problem with your settings. Check out Options->Text Editor->C# and make sure you have IntelliSense turned on and not set to hiding anythig.
In a base class, I want to define an abstract get, but at that point, I don't care about the set. How can I define a setter in my child class?
I tried a few things, but I can't get it to work. For example I tried :
public class BaseClass
{
public abstract bool MyBool { get; }
}
public class ChildClass : BaseClass
{
public override bool MyBool { get; protected set;}
}
And :
public class BaseClass
{
public bool MyBool { abstract get; }
}
public class ChildClass : BaseClass
{
public bool MyBool { override get; protected set;}
}
I know I can workaround this by not using automatic properties in the child class and directly setting the underlying field instead of creating a setter, but I'm looking for something better.
Edit: I don't want to add an abstract setter in the BaseClass.
It may make more sense to use an interface rather than a base class. Then you simply have the classes that need to provide that property implement that interface.
For instance, you can create this interface:
public interface IBoolable {
bool MyBool { get; }
}
Then it is still valid to implement the interface like so:
public class BoolableItem : IBoolable {
public bool MyBool { get; protected set; }
}
Done this way, your code can safely assume anything that implements IBoolable has a property called MyBool that is at minimum read-only.
One solution is to make MyProperty not abstract but delegate its implementation to an abstract protected property that children must override:
public abstract class BaseClass
{
public bool MyBool { get { return MyBoolInternal; } }
protected abstract bool MyBoolInternal { get; set; }
}
public class ChildClass : BaseClass
{
protected override bool MyBoolInternal { get; set; }
}
You have to make up your mind what behavior you want: if it is defined as abstract then a deriving class MUST implement it.
So what you should do is this:
public abstract class BaseClass
{
public abstract string MyProperty { get; set; }
}
public class DerivedClass : BaseClass
{
public override string MyProperty
{
get { return "myValue"; }
set { /* do nothing, not applicable for this class */ }
}
}
Don't throw the NotImplementedException - that is not what you want, you simply want the setter to do nothing for some child classes.
To leave it ambiguous whether you want a setter in inherited classes would violate OOP principles--that is, if a class (abstract or not) has a public/protected setter (abstract or not), then all inheriting classes must also; if a class does not, then inheriting classes must not.
Another way to think about this is to consider properties such that read-only or read-write is part of the contract of the class. Since instances of inheriting classes must adhere to an "Is-a relationship" (the LSP), inheriting classes cannot "add a setter" where the main class didn't have one, because the fact that the main class had a property without as setter is part of the main class definition. In effect, since the main class cannot change the property in question via a setter, therefore all inheriting classes MUST guarantee the same behavior.
Consider using a protected backing field; then you can split this property into a read-only property and a separate setter method. Then, the main class can have the property only and the subclass can have a setter method that the main class doesn't know about. However, I'm not sure this would be a good design either.