0

If a class (or a structure) has a field and we replace it with an auto property of the same type, will client code always stay the same, taking into account that we don't use reflection or any other type of direct or indirect meta-programming? For example

int Integer;

public void Test() {
  Console.WriteLine(Integer);
}

If I change int Integer to int Integer { get; set; }, the code that uses it stays unchanged. Is there any case when I need to change calling code?

The same question about readonly fields and get-only properties.

EDIT: I clarified my question. Also, taking into account existing answers, instead of auto property, question will be about ref property:

Is it possible to replace this

int Integer;

with

int _integer;
ref int Integer => ref _integer

Without any changes of calling code?

Alex Butenko
  • 3,664
  • 3
  • 35
  • 54
  • 1
    You can't pass a property as `ref`. – SLaks Jan 28 '19 at 02:39
  • @SLaks: True. I forgot about this. Though, starting from c# 7 you can pass a ref property as ref, but it would be a bit different case – Alex Butenko Jan 28 '19 at 02:55
  • There question is very light on details, i mean `Comparing class or structure fields and auto properties (or readonly fields and get-only auto properties)` what are we comparing? them all together, classes vs structs, fields vs properties, what you can do with them, all the above? Are you looking for compile time constraints, runtime constraints? i have a feeling this question is "should i use a struct or a class" however its hard to tell what information you actually want – TheGeneral Jan 28 '19 at 03:28
  • @TheGeneral: I want to find a case when I need to change client source code if I replace a field with a property or opposite. I want to know how safe this replacement is. – Alex Butenko Jan 28 '19 at 06:16
  • This might be useful: https://stackoverflow.com/questions/653536/difference-between-property-and-field-in-c-sharp-3-0 – Brian Rasmussen Jan 28 '19 at 08:30

1 Answers1

1

I want to find a case when I need to change client source code if I replace a field with a property or opposite. I want to know how safe this replacement is

Fields (C# Programming Guide)

Generally, you should use fields only for variables that have private or protected accessibility. Data that your class exposes to client code should be provided through methods, properties and indexers. By using these constructs for indirect access to internal fields, you can guard against invalid input values. A private field that stores the data exposed by a public property is called a backing store or backing field.

So there you have the official word on field and property usage

I mean, if we replace a field with auto property or opposite, do we need to change client code in some cases

Yes, you are likely to break things in the following cases,

  1. If you are exposing fields that are being passed by ref

  2. If this class is being inherited and in cases where fields or properties are getting re-implemented or overridden

  3. A derived classes implement Interfaces that require properties etc.

  4. Also there could be cases where they are used in Expressions and it expects field or a property (I think).

In short, if large code bases relied on fields/properties and you change them this is likely to cause breakable changes for any of the above.

Though in summary, if you lived by the Microsoft recommendations above, you should have less of a problem, and if you do it points to the fact this should probably be refactored as a new version anyway (with breakable changes, and more expected usage).

halfer
  • 19,824
  • 17
  • 99
  • 186
TheGeneral
  • 79,002
  • 9
  • 103
  • 141
  • So, except for the first case, which is covered already in C# 7 and last case which is more like reflection, it is safe to change from field to property at least? – Alex Butenko Jan 28 '19 at 07:06
  • @AlexButenko depending on how big the code base is, you maybe be able to get away with it, if your classes a sealed or unlikely to be overriden, then you are safer, if your fields are unlikely to be used in expression or reflection then its even safer. In regaurds to the first point, it will still break even in C#7, though it will be a very trivial fix. In your situation i would just do it anyway, fields rarely should be exposed – TheGeneral Jan 28 '19 at 07:14
  • This is not about existing code base, it 's theoretical question. I am writing a tool, which for some purpose may replace field with properties (or ref properties). So I am thinking if code will still behave exactly the same way or not (if there is no reflection). If there is any case where it behaves differently or does not work, then this is not such good idea. – Alex Butenko Jan 28 '19 at 07:28