Interface should not have properties?

问题:

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

回答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.

回答2:

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.

回答3:

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.

回答4:

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.

回答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.

回答6:

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.

回答7:

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.

回答8:

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?

回答9:

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.

回答10:

The only disadvantage I can see to properties versus methods is that while there is no problem having an interface with a get method, an interface with a set method, and an interface which combines the two (a scenario which would allow maximum flexibility with covariance and contravariance), properties do not combine nicely. I'm not sure why a read-write property isn't simply regarded the same as a read property and a write property, but it isn't. If an interface would support a read-only property and a write-only property of the same name, any attempt to access the properties through the combined interface will fail on the basis of claimed ambiguity.

回答11:

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.

回答12:

IEnumerator is a perfect example for scenario where will need property as interface member. How you are going to store Current element if do not enforce implementer to do so?

回答13:

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.