CODEWITHSUNDEEP
c#oop
Alex Bunn
Alex Bunn

Reputation: 390

OOP - private field or private property setter in regards to DDD

A discussion came up in the office today whether or not it is a OOP convention to use this:

private string myField;

public string MyProperty {
    get { return myField; }
}

public MyClass(string field) {
    myField = field;
}

Over this:

public string MyProperty {
    get;
    private set;
}

public MyClass(string field) {
    MyProperty = field;
}

During Domain Driven Development.

A lot of the DDD examples we've looked at have the code laid out using the 1st approach above, but never the second. I know several people in our office (myself included) have a personal preference to the 2nd approach for various reasons, while others prefer the 1st, or don't care either which way which approach gets used.

Currently, our code is mixed between the 2 different approaches with some classes using approach #1, others use #2, and others use a combination of both (one property might have public get/private set while another only has a public get that returns a private field).

Basically, we're wondering what approach is best fit for DDD OOP best practices and the reasons why as we're due for a code spring clean, and tidying up the domain internals is one of the items on the list.

Upvotes: 3

Views: 1930

Answers (3)

David Masters
David Masters

Reputation: 8295

I would say there is technically no difference between the two when using non-collection types.

But consider the following collection property:

public class Order
{
    private readonly List<OrderLine> _orderLines;

    public IEnumerable<OrderLine> OrderLines 
    {
        get { return _orderLines.AsReadonly(); }
    }

    public void RemoveOrderLine(Guid orderLineId)
    {
        //Remove logic
    }    
}

Inside the class I can use the full functionality of the List object, but only expose a readonly version over an IEnumerable interface. This means I can properly protect any invariants that involve the collection via public methods. I don't think this is easily achievable with the new short hand getters & setters. With this in mind, I'd prefer to have all my properties look/work in the same way rather than having some properties use short hand whilst some having proper backing fields.

Upvotes: 3

adeel41
adeel41

Reputation: 3321

if you are talking about OOP then they both are same but just two different ways to get the same result which is your property can only be editable from your class. So it doesn't matter how you do it.

I think it depends how you are persisting your entities, Therefore we use properties and make their setters protected, so that ORM can use proxies classes to read and write data while in our code we cannot set those properties publicly, and instead use some methods on the entities which then set the properties.

conclusion? they both are same, use what your ORM supports or handle proxies.

Upvotes: 1

Carbine
Carbine

Reputation: 7903

I am no expert in DDD but I can comment on OOP. The choice of using a private field or a private set is only a personal/team coding preference. Its like choosing between spaces/tabs for alignments. It has nothing to do with OOP best practices.

public string MyProperty { get;private set;} still is going to create a private field internally and generate a GetProperty and SetProperty methods around it in the IL. So essentially both the IL are going to be more or less same and does not have any value over OOP best practices. Personally I prefer Option 2 because sometimes people will use the property and field interchangeably within a class and might lead to inconsistent practice. Unless you need a private field explicitly an Auto property is the way to go.

Upvotes: 5

Related Questions