0

I tend to use private properties instead of private fields because they can be extended if necessary, so most of my model classes look like this:

public class MyClass
{
    public MyClass(string name)
    {
         this.Name = name;
    }

    private string Name { get; set; }
    private ISomeInterface SomeInterface { get; set; }
    private bool IsSomething { get; set; }

    public void Method(int parameter) { ... }
}

In other words, I usually replace private fields by private properties. Even inside the class context, properties are used, not fields. Most of them are auto-properties. Often I found out that my classes have no private fields at all (well, only the automatic backing fields for automatic properties).

I found this useful if you want to change the behavior (fields don't allow such flexibility).

I would like to know it this is a bad practice.

  • If it is a bad practice: WHY?
  • If it's not: do you think that I should use the "this" keyword inside the class to improve legibility?

Thanks!

SuperJMN
  • 13,110
  • 16
  • 86
  • 185
  • As far as I can tell, if you have a reasonable excuse for doing this, sure, it's acceptable. – Falgantil May 08 '14 at 13:13
  • 1
    Renamed all your instances of "variable" to "field" for correctness. – dav_i May 08 '14 at 13:15
  • It seems acceptable to me, but I'm afraid I'm breaking some rule here. I would like that somebody could tell me if it's going to cause me problems or if this practice is disregarded. – SuperJMN May 08 '14 at 13:16
  • What do you consider 'flexibility'? I consider it bad practice to implement stuff you might never use, but who am I. – Silvermind May 08 '14 at 13:17
  • 1
    There is a very good answer of Eric Lippert: http://stackoverflow.com/a/3310469/3523746. But, I agree with Sergey Berezovskiy, if you need to just just a peace of data, it's better to use fields. But sometimes in cases Lippert showed, it's useful to have properties – Igor Tkachenko May 08 '14 at 13:32

1 Answers1

2

That might be a matter of preference, but I don't like an idea of usage private properties instead of private fields:

  • There is very useful YAGNI principle which states not to do stuff which might be helpful in the future. Usually classes should not be like huge monsters, and you will be able very quickly wrap field into property when you will need it.
  • It's part of internal class implementation which you can change anytime without breaking clients of your class (very different story with public properties and fields - usually its better to use properties, even if you don't need to have some additional logic now).
  • As @dcastro pointed, there might not be any performance hit, but without compiler optimizations private fields have better performance than properties (which are methods).
  • Naming. I like to have private fields named with underscore, e.g. _name which allows me quickly distinguish between private and public members of class.

Sometimes I use private properties when I need some additional actions to be performed when I set some variable, or when value is computed based on other values, or when value is lazy-loaded. But when I do use, then I clearly see that something is happening there. That is very useful. If all fields would be properties, I would not have that hint.

Sergey Berezovskiy
  • 232,247
  • 41
  • 429
  • 459
  • 3
    Regarding your third point: afaik, there's a very high chance calls to auto-implemented properties will be inlined. – dcastro May 08 '14 at 13:17
  • 1
    I don't see how either one is relevant. Whether or not it's part of the internal implementation has nothing to do with whether or not it's a good idea. For the second, YAGNI only goes so far - trivial implementations (such as defaults for parameters, fields vs properties, etc) can go either way. And as @dcastro said for the third. – Bobson May 08 '14 at 13:18
  • @dcastro agree (actually I consider performance only when I have problems with it), but it also thing which worth noting here – Sergey Berezovskiy May 08 '14 at 13:19
  • @Bobson its big difference when you have public property or public field. If you change field to property, then API of class will change. That's why I mentioned importance of *internal* implementation. Also I don't understand your comment about YAGNI – Sergey Berezovskiy May 08 '14 at 13:21
  • 1
    @SergeyBerezovskiy The question is about **private** properties. The public API doesn't change. – SuperJMN May 08 '14 at 13:27
  • 1
    @SergeyBerezovskiy - Yes, when they're public it matters, but we're specifically discussing *private* implementations. It's very true that you can change it without breaking anything, but that doesn't have anything to do with it being a good or bad idea. Likewise, for YAGNI, choosing to implement it as a property *just in case* you need to add more to the getter/setter some day (instead of a field) is so trivial that YAGNI is irrelevant. **Basically, your advice is good, but utterly irrelevant to the point you are trying to make.** – Bobson May 08 '14 at 13:27
  • @SuperJMN yes, that's exactly what I'm talking about. – Sergey Berezovskiy May 08 '14 at 13:27