1

Does it make sense to make an Interface readonly?

While using Resharper 8.0, i got the following suggestion and I was not sure how this will help me.

enter image description here

What I've found from researching (still not clear how it works against an Interface):

  • It's simply a check to ensure that once the object is fully constructed, that field cannot be pointed to a new value.
  • The real advantage of this keyword is to generate immutable data structures. Immutable data structures by definition cannot be changed once constructed
  • The readonly keyword is used to declare a member variable a constant, but allows the value to be calculated at runtime.
  • Use readonly if you don't want to have to recompile external DLLs that reference the constant (since it gets replaced at compile time)

Cited: What are the benefits to marking a field as `readonly` in C#?

Community
  • 1
  • 1
Dayan
  • 7,634
  • 11
  • 49
  • 76
  • 6
    The "interface" part doesn't seem very relevant; you get the same hint for concrete types. So: [What are the benefits to marking a field as `readonly` in C#?](http://stackoverflow.com/questions/277010/what-are-the-benefits-to-marking-a-field-as-readonly-in-c). – CodeCaster Jul 03 '14 at 14:58
  • The last point (readonly vs constant) is only relevant for basic types like int and string – Patrick Huizinga Jul 03 '14 at 15:02
  • [APPLY ALL THE RESHARPER RECOMMENDATIONS!](http://i.imgur.com/jCotHuM.jpg) – Uwe Keim Jul 03 '14 at 15:02
  • 2
    @CodeCaster Thats the question I was looking over. So technically we are setting `readonly` on the field and not the interface per say. – Dayan Jul 03 '14 at 15:09
  • Please read all answers in [question](http://stackoverflow.com/questions/277010/what-are-the-benefits-to-marking-a-field-as-readonly-in-c) you've cited - I believe "Declaring something as readonly is akin to putting a contract for that variable's usage in the code." covers case of using `readonly` for fields set by DI very well (same idea is re-worded in Stilgar's answer) – Alexei Levenkov Jul 03 '14 at 15:10
  • Side note: please make sure to highlight why do you think interface case is not covered in the original question (consider linking it from post too). – Alexei Levenkov Jul 03 '14 at 15:11

2 Answers2

2

This issue is not important at all. First of all as mentioned by @CodeCaster it has nothing to do with interfaces and ReSharper will probably do it for all fields.

The supposed value of putting readonly on private fields is to instruct future maintainers who might want to change the value of the field that you did not consider changes to that field when you wrote the class. That means that they have to think about all uses of the field when changing it. This is not that big of a deal in practice and you can do it if you are not bothered typing it and having it in your code. On the other hand if you do not wish to do it for all your code you'd better use readonly only when you specifically thought and decided that this field should not change or something will break. It's a question of defaults.

Stilgar
  • 22,354
  • 14
  • 64
  • 101
0

It's important to recognize two distinct kinds of base class that would have a field that the base class itself never writes outside the constructor:

  1. Classes which represent immutable values. In many cases, either the base fields of these should be marked read-only, or else the base should supply a restricted means for derived classes to write them (certain scenarios may require derived classes to write fields between the time a base-class instance is constructed, and the time it's exposed to the outside world, but if that will be necessary the base classes should be explicitly designed for that.

  2. Abstract "readable" base classes which feature both mutable and immutable derivatives. The base-class fields in this case should definitely not be read-only, since derived classes might legitimately need to write them.

Without knowing which situation applies, it's hard to tell which sort of field is appropriate. If one is attempting to produce the second kind of class, an alternative would be for the abstract class not to have any field, but have its property getters chain to virtual methods. That scenario may be helpful if one ever needs to write a derived class that doesn't hold data directly but instead encapsulates a readable "view" of data stored elsewhere.

supercat
  • 77,689
  • 9
  • 166
  • 211