With the recent changes to interfaces that came in C# 8.0, I'm a little confused about how the accessibilities are supposed to work (which are now valid on interfaces, they didn't used to be).
This seemingly simple example does not work as you'd expect:
public interface IFoo
{
public string Bar { get; internal set; }
}
public class Foo : IFoo
{
public string Bar { get; internal set; } //Error - Non-public accessor "Bar.set" cannot implement accessor from interface IFoo
}
The only "working" code I can seem to get for the IFoo interface is this:
public interface IFoo
{
public string Bar { get; internal set; }
}
public class Foo : IFoo
{
string IFoo.Bar { get; set; }
}
In other words, the interface must be implemented explicitly.
Why is the first example invalid? Why does this situation require explicit implementation?
My explanation, with some conjecture on my side:
There's an old rule that if you'd rather not implement an interface member as a public class member, then you must use explicit implementation. This allows to make prescribed interface members "hard to access" because in your implementation they are not suitable for public usage. Note that even then the implementation remains public.
This also seems to apply to interface parts that can now declare themselves with less-than-public visibility, it now seems to be: any member of an interface that *isn't fully public* or that you *don't want to implement as public* must use explicit implementation. Note: I have no source for this, I distilled it from what I see is happening.
Since your property is only "half public", apparently all of it falls under that rule.
Then there is another rule, quoting from the documentation:
An explicit interface implementation doesn't have an access modifier since it isn't accessible as a member of the type it's defined in. Instead, it's only accessible when called through an instance of the interface.
This explains why as soon as you use explicit implementation (forced or not), you can't add access modifiers of your own because the interface defines the applicable access modifiers (with public being the default if omitted).
Consequences of doing this
To access even the public getter, all client code needs to use IFoo:
var f = new Foo(); var x = ((IFoo)f).Bar; // works
IFoo f = new Foo(); var x = f.Bar; // works
var x = new Foo().Bar; // does not compile
It's up to you to decide if it is worth to force this requirement onto your callers.
If needed then I see two ways to avoid that requirement, first way means leaving the internal setter out of the interface and only put it in Foo, but then code using the setter must use Foo as the variable type, it can't use IFoo, while code using the getter can do whatever it likes:
public interface IFoo
{
public string Bar { get; } // no setter (and you can omit `public`)
}
public class Foo : IFoo
{
public string Bar { get; internal set; } // add internal setter as class member
}
Second way, having an internal void SetBar(string value) in the interface, now all code using SetBar() must use IFoo as the variable type, and code using the getter can do whatever it likes:
public interface IFoo
{
public string Bar { get; }
internal void SetBar(string value);
}
public class Foo : IFoo
{
public string Bar { get; private set; } // add private setter as class member
void IFoo.SetBar(string value) { Bar = value; } // use private setter
}
Related
This question already has answers here:
Adding setter to inherited read-only property in C# interface
(3 answers)
Closed 6 years ago.
Consider the following code:
public interface IFoo
{
int Bar { get; }
}
public interface IModifiableFoo : IFoo
{
int Bar { set; }
}
public class FooImpl : IModifiableFoo
{
public int Bar { get; set; }
}
static void Main()
{
IModifiableFoo f = new FooImpl();
int bar = f.Bar; // Compiler error
}
This is the error message:
error CS0154: The property or indexer 'MyNamespace.IModifiableFoo.Bar' cannot be used in this context because it lacks the get accessor
Since IModifiableFoo inherits IFoo, the get accessor (i.e. get_Bar() method) should be accessible. What is going on here?
Note: This is different from question Adding setter to inherited read-only property in C# interface because that question does not address compiler error in calling getter via writable interface.
The reason is that your IModifiableFoo interface's property hides the one it gets inherited from IFoo, instead of overriding it. So if you want your get functionality in your derived interface, you have to explicitly add it.
Actually, you'd better mark your Bar property in IModifiableFoo with new keyword, to explicitly show that it hides something behind, in order to not get confused when looking up the code.
Getters and setters are not individual members. So a setter in one interface does not add to the getter of the base interface. Instead, interfaces only define members, and that member here is either a readable or writable property.
The inheriting interface defines a property (a member) with the same name as the base interface. So it will hide the base interface’s member. So with two interfaces, you now have two members you could explicitly implement:
int IFoo.Bar { get; }
int IModifiableFoo.Bar { set; }
Note that the compiler should give you a warning about this behavior, and advises you to use the new keyboard in the inheriting interface to mark this as intentional:
public interface IModifiableFoo : IFoo
{
new int Bar { get; set; }
}
Don't use properties and interface inheritance here. Use regular methods and two separate interfaces:
public interface IFooReader
{
int GetBar();
}
public interface IFooWriter
{
void SetBar(int value);
}
public class FooImpl : IFooReader, IFooWriter
{
public int GetBar() { /* ... */ }
public void SetBar(int value) { /* ... */ }
}
I have an interface 'IBase' that specifies a nullable int. A later interface 'IDerived' hides the nullable int and 'redefines' it as non-nullable.
interface IBase
{
int? Redefineable { get; set; }
}
interface IDerived : IBase
{
new int Redefineable { get; set; }
}
The class that implements these interfaces must explicitly implement the hidden property, however it's private so the client can't see it.
class TheClass : IDerived
{
public int Redefineable { get; set; }
int? IBase.Redefineable { get; set; }
}
However, even though it's a private property, I can still access it through the IBase interface!
var o = new TheClass();
o.Redefineable = 1; // ok
var hack = o as IBase;
hack.Redefineable = null; // uh!
This seems like some kind of violation of C# access modifiers, but either way it isn't really what I had in mind for redefining (not just hiding) a property. It's correct in the sense that it does what you're asking, get an IBase interface which has a nullable int but this is non-intuitive to the client who could then modify the wrong version of the property.
What I really want, is that if the client accesses IBase.Redefinable, then it behaves as if it's accessing the IDerived.Redefinable property, the 'real' property of TheClass. That way it's actually redefined, as in back through the hierarchy.
class TheClass : IDerived
{
public int Redefineable { get; set; }
int? IBase.Redefineable {
get {
// redirect to redefined property
return this.Redefineable;
}
set
{
// stop client setting it to null
if (!value.HasValue)
throw new InvalidOperationException();
// redirect to redefined property
this.Redefineable = value.Value;
}
}
}
This just feels like a hack, almost as if I'm missing something, so I want to ask if anyone knows a better/alternative way to implement re-definable properties?
However, even though it's a private property, I can still access it through the IBase interface!
It's not a private property. It's just a property using explicit interface implementation. That means it's public through the interface, but only available through the interface. Explicit interface implementation is mostly designed to make it feasible to implement "contradictory" interfaces, as well as being used to "discourage" (but not prohibit) the use of some interface methods. It's not meant to give the impression that the members don't exist at all.
Fundamentally, it sounds like you shouldn't be using inheritance here - if you don't want something to be able to act as an IBase, you shouldn't inherit from IBase.
So I am trying to convert some VB code to C#. The property definition goes like this:
Public Overridable ReadOnly Property [Error]() As String Implements System.ComponentModel.IDataErrorInfo.Error
The conversion that I have seen makes it look like this:
public virtual string Error
Now I understand everything here except that it ignores the Implements line. Is this just not necessary in C#?
Is this just not necessary in C#?
No - C# will implicitly implement an interface by default. Normally you can explicitly implement an interface method:
string System.ComponentModel.IDataErrorInfo.Error
but in your case the property is virtual so you can't use explicit implementation (explicit implementations must be private which makes no sense for virtual members).
The main difference in implicit and explicit implementation is that a consumer will need to have a reference of the interface type, or cast the class to the interface:
MyDataErrorInfo impl = new MyDataErrorInfo();
string s;
IDataErrorInfo i = new MyDataErrorInfo(); // implicitly cast
s = i.Error; // works
s = ((IDataErrorInfo)impl).Error; // works
s = impl.Error; // does not work
A property implementation of an interface in C# doesn't need to mention the interface:
public virtual string Error { get; set; }
If you want an explicit interface implementation:
string IDataErrorInfo.Error { get; set; }
If you want to keep the property as readonly, then you need to use non-automatic properties (VB also forbids an automatic property implementing a readonly property):
Implicit implementation:
public string Error
{
get
{
//...
}
}
Explicit implementation:
string System.ComponentModel.IDataErrorInfo.Error
{
get
{
//...
}
}
As the question title suggests, I want to add an Action<string> to an interface. Is this possible? At the moment it says Interfaces cannot contain fields
You'd need to add it as a property:
public interface IYourInterface
{
Action<string> YourAction { get; set; }
}
Without the get/set it's just a field, and as the compiler points out interfaces can't contain fields. This does mean that when you implement this interface you'll need to supply the actual property as well (though obviously it can be a simple auto-property):
public class Foo : IYourInterface
{
public Action<string> YourAction { get; set; }
// ...
}
Given that, you can then use your Action<string> from the interface:
IYourInterface iFoo = new Foo();
iFoo.YourAction = s => Console.WriteLine(s);
iFoo.YourAction("Hello World!");
As Hans indicated, you can indicate in your interface just a get (or even just a set) if you want. This doesn't mean the class can't have the other, it just means it won't be accessible through the interface. For example:
public interface IYourInterface
{
Action<string> YourAction { get; }
}
public class Foo : IYourInterface
{
public Action<string> YourAction { get; set; }
}
So in the above code, you could access the YourAction property only as a get through the interface, but you could set or get it from the Foo class.
An interface can't contain fields, but they can contain properties, so you could add it that way.
I quote:
"Interfaces consist of methods, properties, events, indexers, or any
combination of those four member types. An interface cannot contain
constants, fields, operators, instance constructors, destructors, or
types. It cannot contain static members. Interfaces members are
automatically public, and they cannot include any access modifiers"
since Action is a feild - it couldn't be a part of interface.
http://msdn.microsoft.com/en-us/library/ms173156.aspx
Greetings everyone...
If I have the following interface:
interface IMyInterface
{
int property { get; set; }
}
And the following implementation:
class MyClass : IMyInterface
{
// anything
}
How can I hide the set method of property from the instances of MyClass... In other words, I don't want the set method of property to be public, is that possible?
It would be easy to do with abstract class:
abstract class IMyInterface
{
int property { get; protected set; }
}
Then I could only set the property within the class that implements the abstract class above...
Don't have the set in the interface to begin with. You can still implement it as private.
You can't "hide" it, it's part of the contract. If you don't want it to be part of the contract, don't define it.
If you use the following interface the set method will be unavailable when classes are manipulated via the interface:
interface IMyInterface
{
int property { get; }
}
You could then implement the class like this:
class MyClass : IMyInterface
{
int property { get; protected set; }
}
If some implementations will only implement some parts of an interface, it may be a good idea to subdivide the interface into the parts which each implementation will either implement completely or not at all, and then define interfaces which inherit all the common combinations of them. Adapting your example:
interface IMyReadableInterface
{
int property { get; }
}
interface IMyFullInterface : IMyReadableInterface
{
new int property { get; set; }
}
Classes which want to support read-write access should implement IMyFullInterface; those which want to only support read access should only implement IMyReadableInterface. This segregation will not require any extra work for implementations of either interface which are written in C# and implement property implicitly. Code which implements property in VB, or explicitly implements property in C#, will have to define two implementations of property--a read-only one and a read-write one, but such is life. Note that while one could define an IMyWritableInterface which just had a setter, and have IMyFullInterface inherit both IMyReadableInterface and IMyWritableInterface, IMyFullInterface would still have to define a read-write property of its own, and when using explicit implementation one would then have to define three properties (I really don't understand why C# can't use a read-only and write-only property together as thought they were a read-write property, but it can't).
Assuming you need the setter to be part of the interface but for some reason it does not make sense for it to be used on a particular implementer (in this case MyClass) you can always throw an exception in the setter (such as an InvalidOperationException). This will not protect you at compile time, only at run time. It is a bit strange though, as code that operates on the interface has no idea whether calling the setter is allowed.
There are certainly cases where you want the interface to have a set and then hide it in some concrete class.
I believe the code below shows what we want to accomplish. I.e. the implementation hides the setter, but any IMyInterface aware component will have access to it.
public static void Main()
{
var myClass = new MyClass();
myClass.Property = 123; // Error
((IMyInterface)myClass).Property = 123; // OK
}
It's basically the same pattern you often see for IDisposable.Dispose() where you have an Explicit Interface Implementation. Here's an example for completeness.
public interface IMyInterface
{
int Property { get; set; }
}
public class MyClass : IMyInterface, IDisposable
{
public int Property { get; private set; }
int IMyInterface.Property
{
get => Property;
set => Property = value;
}
void IDisposable.Dispose() {}
}
Too much typing :(
C# doesn't help us much here. Ideally, it would be possible to have an explicit interface implementation for the setter:
// In C# 10 maybe we can do this instead:
public class MyFutureClass : IMyInterface
{
public int Property { get; IMyInterface.set; }
}
See C# feature proposal here.
There is no protected or private in interface, everything is public. Either you don't define any set or use it as public.