0

For proper encapsulation, should I use a private property with a manual getter method like in Java:

public class Foo {
    private int Prop { get; set; }

    public Foo
    {
        Prop = 1;
    }

    public int GetProp()
    {
        return Prop;
    }
}

Or should I simply use a public property?

public class Foo {
    public int Prop { get; private set; }

    public Foo
    {
        Prop = 1;
    }
}
Piorrro33
  • 19
  • 8
  • In the first example, prop would be just a field. A private property doesn't make sense here. Since C# 6, we can write a readonly property the following way: `public int Prop { get; }` – Dennis_E Jan 31 '18 at 14:04
  • 1
    What do you mean, `proper encapsulation`? There is no such thing. What is the context? – Sebastian Zander Jan 31 '18 at 14:07
  • I corrected my GetProp method. What I meant by ``proper encapsulation`` is encapsulation good practices I'd say. – Piorrro33 Jan 31 '18 at 14:09
  • Don't use Java style getters and setters. The correct c# alternative is the property construction. – Nyerguds Jan 31 '18 at 14:40

5 Answers5

3

Properties are the way of creating getters and setters in C#, so there is no reason to create a getter method, like you would in Java.

In other words: You should use the second example.

Eliran Pe'er
  • 2,569
  • 3
  • 22
  • 33
0

Typically the proper way to do this is:

private int prop;

public int Prop
{
   get { return prop; }
   set { prop = value; } //do other stuff within set if needed.
}

This way you have access to everything, but can still do something custom (commonly NotifyPropertyChanged) if needed.

oppassum
  • 1,746
  • 13
  • 22
0

A property is just a syntactic sugar for get_PropertyName and set_PropertyName methods in c#.

public class Foo 
{
    public int Prop { get; private set; }
}

Is equivalent to:

public class Foo 
{
    private int _prop;

    private void set_prop(int value) { _prop = value; }
    public int get_prop() { return _prop; }
}

It's best that you use auto properties when possible and use properties with backing fields when you need to add logic to the getter/setter of individual fields.
If the property is going to be private, as it is in your first example, you should just use a field.

Camilo Terevinto
  • 31,141
  • 6
  • 88
  • 120
0

The point of a Property is usually that you have a get and set function, that can be used mostly like a variable. Your first example is really wierd - why not just make the getter only public? Readonly and Writeonly properties are not a uncommon sight:

//Public property with private get or writeonly
public int Prop { private get; set; }

//Readonyl property
public int Prop { get; private set; }

One important rule regarding the Backing field: It is very important that you do not mix up the Property and it's backing field, especially in class code. If you use Autoimplement Properties, that danger is non-existant. If your code is more complex than that, a common approach is to append a underscore (_) to the backing field name. Prop/prop is too easy to mix up. _Prop and Prop are really hard to mix up ,especialyl for autocompletion features.

Christopher
  • 9,634
  • 2
  • 17
  • 31
0

In general, methods represent actions and properties represent data. While both your examples can be used identically, the 'proper' way of representing state is through properties, and using properties correctly tells consumers of your object that this is representing state, not an action.

You should also consider how things like serialization and intellisense are expecting properties instead of methods.

zola25
  • 1,774
  • 6
  • 24
  • 44