19
private string mWhatever;

private string Whatever
{
    get
    {
        return this.mWhatever;
    }
    set
    {
        this.mWhatever = value;
    }
}

I've seen some people who make properties for every single member, private or not... does this make any sense? I could see it making sense in 1% of the cases at times when you want to control access to the member inside the class containing it because if you didn't use properties for every member it would lead to inconsistencies and checking to see if the member has an access or not (since you have access to both in the scope of the class).

17

Short answer: Yes, when there is a need. Otherwise, use an Auto-Implemented Property getter and setter like private string Whatever { get; set;}

  • It is very handy When you are using a close domain approach
  • It is also handy when a specific logic should be checked when you are setting the value

Here is a full description of when you would be using private setters: C# property usage.

  • It's also really easy to make the property public later on if required. – Tom Pickles Jul 13 '14 at 17:56
  • 4
    What is a close domain approach? – Trisped Jul 23 '14 at 22:13
  • 1
    I was referring to a private setter in a property of the class. It should prevent direct access to set value from the object and facilitate some logic check before setting the value. – EL Yusubov Aug 5 '14 at 14:22
  • having private variables with public setter/getters (even if they're just naive) also has the advantage that if your code is compiled into a library, the signature will remain unchanged if you replace your naive setter/getters with ones that have side-effect etc. but if you use a simple public variable instead, the library signature would change if you changed it to a private w/ non-naive setter/getters. .. which would mean that if your library changed in that way then consumers of your library would need to recompile. – orion elenzil May 17 '18 at 22:38
12

Some good answers here already, but I think most of them miss one point of your question:

I've seen some people who make properties for every single member, private or not... does this make any sense?

I think this is seldom necessary beforehand, for every single member. Start with

 private string Whatever;

When you later come to a point where you need encapsulation or a conditional breakpoint for this specific member, you can still replace it by a property with same name - in most cases without changing the code which uses Whatever. But beware, there are subtle differences, see Brian Rasmussen's answer in this SO post (link also given by Emmad Kareem, +1).

  • +1, also, you are correct, most answers missed the original question points, we are typical IT guys :) – NoChance Aug 15 '12 at 10:13
  • Refactoring a field to a property after-the-fact is a nightmare; requiring you to recompile all of the consumers. Changing an automatic property to contain custom logic is a breeze. If there's even a slight chance of the code seeing refactor, it's going to be a lot less work if you just use properties from the onset. – Dan Mar 16 '16 at 15:09
  • @Dan: in most projects I have seen the effort is quite the same, you have to recompile in both cases. Nevertheless I think you are correct that using properties, especially auto properties, can help to avoid some subtile problems with reflection or the usage of member variables in "out" parameters. – Doc Brown Mar 16 '16 at 17:27
  • @DocBrown In any case, it's definitely not a catch-all statement. There are plenty of reasons to just keep it simple and use a field. If you can predict a refactor though, even the subtle problems are ones worth considering. – Dan Mar 16 '16 at 17:44
7

One of the biggest advantages of this approach is that you get control on when your variables change.

Consider the following.
You are debugging a large project. A certain method throws an exception. You set a breakpoint and you reveal that a certain member variable has wrong value. Say your code relies on this variable very extensively, and you find hundreds write usages (Spaghetti scenario). So you can't figure out which of these usages assigned a bad value.
If the code is multithreaded, debugging may become a real nightmare.

With property, you may set a breakpoint in a setter. Combined with a condition, it may be nailed down in a single run.

VC++ has data breakpoints, but it is only available for unmanaged code.

1

If you don't use a property, your only other option is to use a field to store variable data. Properties and fields have significant differences. Most of these differences are found Fields vs. Properties. I suggest you study the differences then make your choice according to your application needs. However, bear in mind that using fields instead of properties is not the common OO practice because of their nature and shortcoming.

1

Private properties can be very useful to encapsulate the behaviour of things which are internal to your class. Just because they are private doesn't mean that you shouldn't take advantage of the syntactic sugar that properties give you.


The example given is a poor one, however. Boilerplate property getters and setters like this are almost always a bad idea. If you are using C# 3.0 or later then, auto properties are a much better idea:

private string Whatever { get; set; };

This is shorter, cleaner, and much more readable. In fact it is barely longer than just declaring the backing variable.

Most importantly though, auto properties can be converted to full properties at any time without changing the semantics of the rest of the program! Thus if you need to add validation or error handling, you can do so easily.


As it is, I always thought it was a shame that you couldn't have a read only property, to enforce only being able to write to the value in the constructor, (I prefer immutable types) but this was added in C# 6.0 as "Auto-Property Initializers", which allows you to do:

private string Whatever { get; } = ...;

or

private string Whatever { get; };

along with

    Whatever = ...;

in the constructor.

0

It's not absolutely necessary to do this for private properties, but it does allow for modifying how the property gets/sets the underlying value without changing how it is accessed.

For example, modifying how the underlying value is set:

private string Whatever
{
    get
    {
        return this.mWhatever;
    }
    set
    {
        this.mWhatever = string.IsNullOrEmpty(value) ? string.Empty : value;
    }
}
0

Yeah

I personally use this as the caching mechanism, and we might call it property-level caching.

private List<User> users;
private List<User> Users
{
    get
    {
        if(users == null) users = new UserManager().GetUsers();
        return users;
    }
}

Now in other places inside my class, I use Users property instead of users field.

Another feasible situation might be when you want to implement some logic on a field, but in a centralized way in a class. Thus you can both create a GetFoo() method, or a Foo property for foo field.

private string foo;
private string Foo
{
    get
    {
        return "Mr. " + foo;
    }
}
0

Something else to consider:

Actual properties are an implementation detail. One of the goals of OOP is to try and minimize the exposure of implementation details where practical.

The reason for this is if you hide the properties and only expose them through getters and setters, you have far more control. For example, your getter can validate its input and prevent the property being set to an invalid state. If the ability to change the value is time critical, then the setter can protect against this too. The getter, should getting the actual value be expensive for whatever reason, can do lazy initialization and/or caching.

Having getters and setters exposed and the properties hidden means sometimes you don't need a property at all. Your getter can compute the value on invocation, or delegate the task somewhere else, or anything that lets it meet its specification. What's important about your class is the information you can access from it, not how that information is represented internally.

Of course, if there's no negative consequences to anything outside the class being able to access a property directly, then you should just make it public. However in my experience, such cases are relatively few and far between.

0

I know this is an old question and everything @Yusubov said is correct, but with respect to his second bullet point about specific logic in the setter, and since I didn't see anyone specifically mention this, a perfect example would be when your class implements the INotifyPropertyChanged interface.

This is used a ton in WCF and Silverlight which allows you to know when a specific property has changed via the logic in its setter like in the class below:

public class Settings : INotifyPropertyChanged
{
    public Settings() 
    { 
        this.CountryField = String.Empty; 
    }

    private string CountryField;
    public string Country
    {
        get { return this.CountryField; }
        set
        {
            if (Object.ReferenceEquals(this.CountryField, value)) { return; }

            this.CountryField = value;
            this.RaisePropertyChanged("Country");
        } 
    }

    public event PropertyChangedEventHandler PropertyChanged;
    private void RaisePropertyChanged(string propertyName)
    {
        PropertyChangedEventHandler propertyChanged = this.PropertyChanged;

        if (propertyChanged != null)
            propertyChanged(this, new PropertyChangedEventArgs(propertyName));
    }
}

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.