CODEWITHSUNDEEP
c#oopencapsulation
Jose Lopez Garcia
Jose Lopez Garcia

Reputation: 982

Defining both Private Field and Property vs just Property

Following OOP's best practices, is it better to have this code:

class Car {

    private Driv driver;

    public Driv Driver {

        get { return driver; }

        set { driver = value; }
    }

}

Or this one?

class Car
{
    public Driv Driver { get; set; }
}

While the second version is shorter, I feel like I'm breaking the main premise of the Encapsulation concept:

EVERY class should keep its privates to itself.

Hope the answer is not too trivial.

Upvotes: 4

Views: 1469

Answers (4)

Sus Among Us
Sus Among Us

Reputation: 103

C#'s properties are simply syntactic representations of some underlying methods and variables. Essentially, the compiler turns: 

public int Height { get; set; }

into: 

private int height;

public int getHeight() {return height;}

public int setHeight(int h) {height = h;}

So, no you are not defying OOP encapsulation, but instead syntactically simplifying it. You could also do something like public int Height {get;} which is a nice way to create an immutable class member. It simply creates the property without a set method, so only the class itself can alter it.

Now, you only need to use properties with backing fields if you wish to do additional tasks when getting or setting a variable, such as raise an event, or update another variable. The compiler would turn:

private int height;

public int Height { get {return height;} set {height = value; OnHeightChanged();} }

into:

private int height;

public int getHeight() {return height;}

public int setHeight(int value) {height = value; OnHeightChanged();}

Hope this helps!

Upvotes: 0

Aydin
Aydin

Reputation: 15284

Your first example is what's called a Property with a backing field

The second is called an Automatic property.

The purpose of a property with a backing field is so that you can control access to your private properties.

So... If for instance you want to, make a calculation before returning the value of your private field, you could do it in the one with the backing field.

Or lets say you have a car object with 10,000 miles on the clock... you would probably want to only increment its value using the Drive method, and hide the setter of the Property with the backing field

void Main()
{
    var car = new Car();
    car.Drive();
    Console.WriteLine (car.Miles);
}

public class Car
{
    private int miles;

    public Car()
    {
        miles = 10000;
    }


    public int Miles 
    {
        get
        {   
            return this.miles;
        }
    }

    public void Drive()
    {
        this.miles += 100;
    }
}

Upvotes: 4

John Koerner
John Koerner

Reputation: 38079

You are not breaking encapsulation with the second approach. The second approach is syntactic sugar to make property definition less verbose. The benefit of this approach is that in the future if you need to modify the getter or the setter, you are setup to do so and will not break the API contract.

Upvotes: 2

ProgrammingDude
ProgrammingDude

Reputation: 597

There really is no difference. If no private variable is created by the user then the code will be generated automatically for the private field. However, if the user wishes to do additional logic in the getter or setter of the property then declaring a private field is necessary.

Upvotes: 4

Related Questions