CODEWITHSUNDEEP
c#wpf
jharr100
jharr100

Reputation: 1469

When to use the public or private property?

If I have a class like so:

public class MyClass:INotifyPropertyChanged
{
private Visibility isVisible;
private ObservableCollection<string> names;

public Visibility IsVisible
{
get{ return isVisible;}
set { isVisible = value; OnPropertyChanged("IsVisible");}
}

public ObservableCollection<string> Names
{
get { return names;}
set { names = value; OnPropertyChanged("Names");}
}

//ctor
public MyClass(){
     names = new ObservableCollection<string>();
}


//INotifyPropertyChanged implementation
 public event PropertyChangedEventHandler PropertyChanged;
    private void OnPropertyChanged(string propertyName)
    {
        PropertyChangedEventHandler handler = PropertyChanged;

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

}

Before any one beheads me - I have done quite a bit of looking up and have found a mixed bag of answers...

  1. Do I modify the public or private properties/variables for use in my bindings? i.e. I have an issue where adding to names collection will trigger OnPropertyChanged and changing isVisible will NOT trigger OnPropertyChanged. My assumption is that this is because names is an ObservableCollection where as isVisible is not but I am not sure...

  2. If I am supposed to uses the public properties - what is the need for having the private ones?

Upvotes: 0

Views: 352

Answers (2)

User
User

Reputation: 1118

So I think you are confusing Properties and Fields (aka variables).

public class Example()
{

    public int FieldExample;

    private int _propertyExample;

    public int PropertyExample 
    {
        get
        {
            return _propertyExample;
        }
        set
        {
            _propertyExample = value;
        }
    }
}

In simple usage scenarios, the difference between a field and a property isn't obvious. But properties have different plumbing under the hood that allows them to take advantage of reflection and binding. For WPF, this means you've got to have public properties. Best practice for a Public Property is associate it with a private (or protected) field - and that field name is usually either prefixed with an _ and/or starts with lower case character. This is called a "backing field."

The private backing field holds the actual data, the public property is just the means by which other classes can interact with that data. Inside the get and set blocks, you can place any code you want: instead of returning my backing field, I could instead put: return 5;. It's not useful, and it's poor practice, but I can. Generally, the code that resides in your get and set blocks should still set or get the value; although you might validate the input first, and/or format it first. The pattern you are implementing in your sets for WPF raises an event that the property has changed. Other parts of your program are listening for that event so they know to update the UI.

So in your code, if you only change the backing field and don't raise an event that there has been a change, the UI will not update. You might desire this behavior if you are performing a complex action on an object, and want to hold off performing an UI update until a complete batch of items are finished, but that's an optimization and for starters you are probably better off always accessing/setting to the Public Property.

Upvotes: 1

Habib
Habib

Reputation: 223227

You don't need a private property, only a private field would be enough so replace: 

private Visibility isVisible {get; set;}

with 

private Visibility isVisible;

If I am supposed to uses the public properties - what is the need for having the private ones?

You cannot use Auto-properties with INotifyPropertyChanged. That is why you need a backing field for your property IsVisible.

See: An elegant way to implement INotifyPropertyChanged

Upvotes: 4

Related Questions