Let's say I have 2 interfaces defined like so:
public interface ISkuItem
{
public string SKU { get; set; }
}
public interface ICartItem : ISkuItem
{
public int Quantity { get; set; }
public bool IsDiscountable { get; set; }
}
When I go to implement the interface in C#, VS produces the following templated code:
public class CartItem : ICartItem
{
#region ICartItem Members
public int Quantity { get {...} set {...} }
public bool IsDiscountable { get {...} set {...} }
#endregion
#region ISkuItem Members
public string SKU { get {...} set {...} }
#endregion
}
In VB.NET, the same class is built out like so:
Public Class CartItem
Implements ICartItem
Public Property IsDiscountable As Boolean Implements ICartItem.IsDiscountable
'GET SET'
End Property
Public Property Quantity As Integer Implements ICartItem.Quantity
'GET SET'
End Property
Public Property SKU As String Implements ISkuItem.SKU
'GET SET'
End Property
End Class
VB.NET explicitly requires you to add Implements IInterfaceName.PropertyName
after each property that gets implemented whereas C# simply uses region
s to indicate which properties and methods belong to the interface.
Interestingly in VB.NET, on the SKU
property, I can specify either Implements ISkuItem.SKU
or Implements ICartItem.SKU
. Although the template built by VS defaults to ISkuItem
, I can also specify ICartItem
if I want. Oddly, because C# only uses region
s to block out inherited properties, it seems that I can't explicitly specify the implementing interface of SKU
in C# like I can in VB.NET.
My question is: Is there any importance behind being able to specify one interface or another to implement properties in VB.NET, and if so, is there a way to mimic this functionality in C#? Furthermore, what is the effect of specifying one interface over another when implementing properties?
Yes this is importance, this called Explicit and Implicit interface implementation.
In C# you can do this by prefixing method name with an interface name, like that:
I think the other answers are actually a little off the mark here.
In the example you've posted, one interface inherits from the other. This simply means that it offers the same members as its base, plus some additional members.
These are not two independent interfaces that happen to expose members with the same name.
ICartItem.SKU
is the same thing asISkuItem.SKU
. ThatICartItem
inherits fromISkuItem
simply means thatISkuItem
, as an interface, represents a subset of the functionality offered byICartItem
.Consider this code:
This class will not compile. You cannot define
ICartItem.SKU
explicitly in this case, becauseICartItem.SKU
is justISkuItem.SKU
. There's no "other"SKU
property to define.So, to answer your questions directly:
When they are separate, unrelated interfaces: yes.
As others have pointed out, you can provide different implementations for different interfaces' members sharing a common name.
But when one interface inherits from the other: no.
It doesn't matter because they're the same thing.
Again, if they're unrelated interfaces, it has the effect already discussed by others: providing different implementations for the two interfaces. But if one derives from the other, it has no effect.
Yes, you can implement different functionality behind each interface. Assume both interfaces have the same signature. Depending on which interface you cast your implementation to will control which interface is executed.
... C# Example of explict interfaces ...
... Similar Code in VB.Net ...