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 times on google, probably with wrong key words). He also told me that only methods should be in interface. Now, I am aware that is is not strict rule, since obviously in .net you can make property signature in interface and compile it.

But is this true to be a bad practice/design/oop? And why?

Pointing out to right literature or web resource would be helpful too.

Thanks

Answer 1

I'll just add my voice in here as well - I've never come across this recommendation. A property is effectively a pair of get/set methods.

Like every other design decision. If it genuintely makes sense; if it is appropriate for the system under design, if it doesn't cause maintenance problems, if it doesn't cause performance problems, there should be no reason you can't do it.

Answer 2

I can think of no documentation to support that premise. Additionally I can think of many examples in the BCL which do quite the opposite. Take a look at pretty much any of the collection interfaces and you will see properties.

Answer 3

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.

Answer 4

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 5

Never seen anything like this per se, but there was some talk a while ago about not using properties in cross-platform interface definitions as there are many platforms which don't support properties, but just about everything supports methods.

Answer 6

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.