Interface should not have properties?

Question

My office colleague told me today that is bad practice to use properties in interfaces. He red that in some MSDN article(s), which I couldn\'t find (well I was trying few ti

Answer 1

The only way I can think about, why properties are bad for interfaces is, when you define interfaces for services (such as WCF, WebServices, Remoting) that are hosted on diffrent machines or application domains.

Cause properties imply that they are fast (aka. getting and setting values) which is not true for services, due to network and serialization activity. An explizit method for getting or setting values in service interfaces imply it could take some time to complete the operation.

Answer 2

Practically, a property is set of two functions: one to get the value, and one to set the value. Even though properties are first class "features" of C#, this is still true.

Why wouldn't properties be allowed in interfaces?

Answer 3

I can see no reason not to have Properties as part of your Interface. How else would you implement access to data members? Get Methods and Set Methods instead of properties. That would be just plain ugly and so 1990's.

Answer 4

I have never encountered anyone making this claim, nor do I see any good reason for it. The .NET framework is full of interfaces with properties.

Answer 5

It's bad design as you pollute the implementation's variable space which is used for storing the state with variables that used as part of the class contract.

Answer 6

I see this is a .Net question; however, the thinking may be coming from a Java background. It reminds me of Item 22 from Effective Java: Use Interfaces only to define types.

This recommendation does not proscribe all properties in interfaces. It specifically addresses interfaces containing only properties.

When a class implements an interface, the interface serves as a type that can be used to refer to instances of the class. That a class implements an interface should therefore say something about what a client can do with instances of the class. It is inappropriate to define an interface for any other purpose.

One kind of interface that fails this test is the so-called constant interface. Such an interface contains no methods; it consists solely of static final fields...

The constant interface pattern is a poor use of interfaces. That a class uses some constants internally is an implementation detail. Implementing a constant interface causes this implementation detail to leak into the class's exported API... it represents a commitment: if in a future release the class is modified so that it no longer needs to use the constants, it still must implement the interface to ensure binary compatibility. If a nonfinal class implements a constant interface, all of its subclasses will have their namespaces polluted by the constants in the interface.

Of course, Java itself (and probably C#) contain examples of these constant interfaces. The book addresses that as well.

There are several constant interfaces in the Java platform libraries... These interfaces should be regarded as anomalies and should not be emulated.

I agree with previous answers that I have never seen a recommendation to avoid interfaces containing both properties and methods.