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 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 2

An interface is a contract for a class to implement and I see no reason why properties should be excluded from such a contract. Furthermore, properties are intrinsic to .NET.

As an example: ICollection<T> has both Count and IsReadOnly.

Answer 3

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 4

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 5

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 6

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 7

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 8

There is widely recognized term "code smell". I suggest introducing "programmer smell" concept - if someone insists on some rule, but can not explain why - it is a smell. Your colleague should be able to explain why properties in the interface are bad. If he can not - he is probably wrong even if article he is referring to is right.

That article may be was talking about some specific kinds of interfaces, may be it had something to do with COM and interoperability or whatever. Or he may be just got it wrong. Understanding rules and being able to explain them is important part of using rules.