28

Interfaces, as defined by MSDN "contain only the signatures of methods, delegates or events." However, since properties are no more than syntactic sugar for a get and set method, they are also allowed in interfaces. My question is - is there any situation where defining properties in an interface is appropriate or should we stick to the scenarios described by MSDN?

Ryan
  • 3,127
  • 6
  • 32
  • 48
Otávio Décio
  • 73,752
  • 17
  • 161
  • 228

4 Answers4

37

I think properties are perfectly acceptable in interfaces.

As you said, they really are a get, set, or get and set method. Many interfaces in the Framework define properties, such as IAsyncResult and IWebProxy.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • Thank you, Reed. In this case, should these properties be of elementary (non user defined) types? The reason I ask is because if you for example define it as a domain type, you may end up with a circular reference. – Otávio Décio Mar 21 '10 at 23:37
  • 2
    @Otávio Décio: Keep in mind the purpose of an interface. An interface defines a contract. If a property is required for the contract, then it's fine. You shouldn't end up with circular references, since the properties shouldn't be types that are directly implementing the interface, but rather either basic, framework types, or types that, themselves, form part of the "contract". IWebProxy (linked above) is a good example - it has a Credentials property, which is of ICredentials. That's part of the contract, but essential a "user defined" type still (for that lib). – Reed Copsey Mar 21 '10 at 23:40
  • 1
    just to make sure - properties defined in interfaces should either be non user defined concrete types or interface types (user defined or not). – Otávio Décio Mar 21 '10 at 23:43
  • 2
    @Otávio Décio: I don't have a problem with user defined concrete types, either - but I think care needs to be maintained in this case... – Reed Copsey Mar 21 '10 at 23:57
15

The article you link to also states:

An interface can be a member of a namespace or a class and can contain signatures of the following members:

  • Methods
  • Properties
  • Indexers
  • Events
Simon Bartlett
  • 2,010
  • 14
  • 15
3

Yes, An interface should define properties when it really in need. Please suppose that. There is a IUser interface that has defined a property "Name" then you can use it without worry about if the object didn't implement the property.

public void main()
{
    IUser u = User.GetUser("id");
    string name = u.Name;
}
Edison Chuang
  • 2,911
  • 4
  • 26
  • 28
1

It is completely legitimate to define properties in interfaces. A fairly good and detailed explanation as to why you can use properties but cannot use fields is given in the answer here: Why Can's C Sharp Interfaces Contain Fields

You'll want to bear in mind that any properties defined in an interface will always be public. That is to say, if you define a getter and a setter within the interface, then both the getter and the setter must be public. You can, if you wish, define only the getter in the interface and then define a private setter in the implementing class. It's definitely an area to work carefully in.

Similarly, Java does not allow for instance variables in its interfaces. However, it does allow variables to be declared, and these will be treated as static & readonly. The convention in Java is to write getMyVariable() and setMyVariable() methods if you require them in the implementing class. C# essentially just allows for a cleaner syntax.

Josh Flash
  • 11
  • 1
  • 1