33

Could anyone please help me out whether it's a best practice to include properties on Interface or Abstract Class?

I would imagine an Interface should only have method signatures?

bryanmac
  • 38,941
  • 11
  • 91
  • 99
Nil Pun
  • 17,035
  • 39
  • 172
  • 294
  • possible duplicate of [Interface vs Abstract Class (general OO)](http://stackoverflow.com/questions/761194/interface-vs-abstract-class-general-oo) – MPelletier Dec 15 '11 at 01:21
  • 2
    how is that a dupe? As Kyle pointed out below both interfaces and abstract classes can have properties so there's no "vs." here. – bryanmac Dec 15 '11 at 01:23

5 Answers5

25

Properties are syntactic sugar for methods. Consider this:

I have a property:

String PropertyA { get; set; }

At runtime this becomes something like this:

String get_PropertyA() { ... }
void set_PropertyA(String value) { ... }

Note that the "..." indicates code that would be put there by the code generator. Effectively what I am saying is that properties don't really exist beyond C#, as they compile down to methods using a convetion indicated in my example. To confirm what I am saying you can use reflection and have a look at what the reflected code looks like.

It can be bad practice however to put properties on an interface if they do something that is non trivial in the implementation. For example, if I want to set a variable and that updates other variables, or setting a property might deny my property assignment because of an internal condition, then a property shouldn't be used. I think that is a general rule that would apply beyond interfaces.

John Weisz
  • 30,137
  • 13
  • 89
  • 132
Dessus
  • 2,147
  • 1
  • 14
  • 24
  • 2
    Doing something non-trivial is a bad practice for properties period as you pointed out. It causes problems in the debugger and it's not clear to the consumer of the class that significant work will be done. For interfaces, you can't determine whether it's non-trivial since it doesn't have an implementation. All you can do is imply non-trivial work by the name - but by definition work. naturally implies a method. – bryanmac Dec 15 '11 at 01:52
  • 1
    Using only getter properties makes perfect sense for DTO-interfaces. – mbx Jun 24 '13 at 14:41
  • How do we define non-trivial? I've been wrestling with the decision to make a few members on my interface properties or methods. On one implementation, it will be a straight set/get of a field, but on another, it will need to perform a regular expression to extract the value out of a field's member. How can we know if it will be non-trivial if we don't yet know the various implementations of the interface? – dark_perfect Aug 28 '14 at 14:46
  • I would recommend based on your description (and this is opinion here) that you think about the architecture and what the purpose of your class is in the grander over all picture. If your class has one purpose such as acting as a DTO object etc. then you might find, that while the desired outcome is to filter etc, that filtering is additional to core intent of the DTO object (and hence should be in a separate class ideally so as to not void the single responsibility philosophy). – Dessus Sep 06 '14 at 22:42
  • You could however argue in the opposite direction to what I have said that the purpose of your class is to transfer data in the way you want it, or in a way that is performant (by not storing rubbish data that is not wanted etc). Those could be valid concerns too. It really comes down to your business requirements. I would try to keep DTOs overly clean, and extend them to get what I wanted as it is really a class that acts as a contract, and putting business requirements into the DTO feels wrong. I prefer excluding even helper methods from my DTOs. Keep your single responsibilities thin. – Dessus Sep 06 '14 at 22:47
12

It is perfectly acceptable to have properties in an interface. I do it all the time.

Daniel A. White
  • 187,200
  • 47
  • 362
  • 445
  • Perhaps it's just a question of preference. Well, I am going to forget these debates and do as what you do. – SWIIWII Nov 16 '17 at 18:36
11

Properties are fine in an interface

See:

http://msdn.microsoft.com/en-us/library/ms173156.aspx

Interfaces consist of methods, properties, events, indexers, or any combination of those four member types. An interface cannot contain constants, fields, operators, instance constructors, destructors, or types. It cannot contain static members. Interfaces members are automatically public, and they cannot include any access modifiers.

bryanmac
  • 38,941
  • 11
  • 91
  • 99
6

It is perfectly valid to include a property in an interface or abstract class.

Kyle Trauberman
  • 25,414
  • 13
  • 85
  • 121
2

I don't believe there is best practice for this.

Properties (which really are methods) are allowed on interfaces. Anything more than this is just an opinion. This includes my point about anything more being an opinion.

tymtam
  • 31,798
  • 8
  • 86
  • 126