Best Practice on local use of Private Field x Property

Question

Hi,

When inside a class you have a private fiels and expose that field on a public property, which one should I use from inside the class?

Below you is an example on what I am trying to find out. Should manioulate the Private Field _Counter or the Property Counter?

Public Class Test

Private _Counter As Integer

Public Property Counter() As Integer
    Get
        Return _Counter
    End Get
    Set(ByVal value As Integer)
        _Counter = value
    End Set
End Property

Private Sub Dosomething()

    'What is the best practice?
    'Direct access to private field or property?

    'On SET
    _Counter += 1
    'OR
    Me.Counter += 1

    'On Get
    Console.WriteLine(_Counter)
    Console.WriteLine(Me.Counter)

End Sub

End Class

Thanks in advance for the help. Edu

Answer 1

I prefer to use the property whenever possible. This gives you the flexibility in the future to modify what the property returns/sets without having to go through and find all the locations that were using the private variable.

Answer 2

Use the private field because you are not doing something in specific in the setter.

I would also recommend to remove the property-setter, this way you force the state of the counter to be set by the given method DoSomething()

Answer 3

Depending on the situation, it may be preferable to allow the direct modification of a field on a class only privately, and or through some method which associates semantics with the modification. This way it becomes easier to reason about this class and that particular value, since you can be certain that its modified only in a certain way. Moreover, at some point, an action such as incrementing and int may have additional required consequences at which point it makes more sense to expose access to it through methods.

Answer 4

IMO you should be using the Property accessor whenever possible. This is because you don't have to worry about any internal logic that might be available when you have an a property.

A good example of where this happens is in the code behind in a Linq DataContext.

check this out...

[Column(Storage="_ReviewType", DbType="TinyInt NOT NULL")]
public byte ReviewType
{
    get
    {
        return this._ReviewType;
    }
    set
    {
        if ((this._ReviewType != value))
        {
            this.OnReviewTypeChanging(value);
            this.SendPropertyChanging();
            this._ReviewType = value;
            this.SendPropertyChanged("ReviewType");
            this.OnReviewTypeChanged();
        }
    }
}

Notice all that logic in the 'setter'?

This is why it's important to start getting into the practice of calling your Properties instead of fields, IMO.

Answer 5

I always use the property accessors, because the I am safe in case I add logic in the getter or setter in the future, knowing for sure that no code bypasses it.

Answer 6

If you are worried about the performance overhead of calling property accessors when they just go directly to the field, don't. Most compilers will inline this sort of thing, giving you effectively the same performance. At least, you're pretty unlikely to need the extra nanoseconds of time you might gain by going directly to the field.

It's better to stick with property accessors because a) you can be very consistent in all of your code which makes it more maintainble and b) you get the benefits pointed out by others here.

Also, I don't usually add the Me. (or this.) keywords, unless there's a scope problem (which I try to avoid by choosing my identifiers carefully). I don't get confused by this because my functions and subs are never so long that I'm not sure whether I am working with a local (stack-based) variable or a member of the class. When they get too long to tell easily, I refactor.

Answer 7

In my opinion, using a public accessor internally is over-encapsulation: it blurs the code. With such an approach, otherwise simple operations invoke accessors that may contain more complex logic, so it's harder to analyze the code of the operations.

In my programming experience, I've rarely had a situation when it would help much. Instead, I prefer to access fields directly, and only if it's really needed, to abstract the access by creating a private accessor, which can be used by both the public accessor and other functions. The rationale is that if you need to attach some special logic in the public accessor, chances are that the logic may not be the same for internal access.

Note also that most modern IDEs (like Eclipse) allow to see immediately all references to a private field, and to refactor the code to use a function instead of a direct access.

Answer 8

Thank you all for the answers and suggestions.

After considering all the suggestions here plus other researches it is my impression that for this situation on Private Field versus Assessor it is more of a personal choice. So basically the most important is that no matter what you choose be consistent.

That said; my personal rule is leaning towards this:

1) Access your private fields directly.

2) If accessing accessors use the keyword ME. to improve readability

3) Use the accessor only if it implements vital logic logic that also applies to private access. This way you know that if you are using the accessor it is because there is “something else to it”

4) Avoid using Protected Fields. Derived classes should always use the accessor, never direct access to the field.

Let me know what you think.

SideNote: After this I think we are missing a new scope for the class level fields. A keyword like “Restricted” where this field could only be accessed from its getter/setter. This way you always access directly the private fields, but if you need to make sure certain field can only be accessed by its accessor that you change the Private to Restricted. (how about “Restricted , RestrictedRead and RestrictedWrite”?)

Answer 9

Original poster is EXACTLY correct.

1) Access your private fields directly.

• Makes refactoring easier.

2) If accessing accessors use the keyword ME. to improve readability

• explicitly listing scope requires less thinking by reader

3) Use the accessor only if it implements vital logic logic that also applies to private access. This way you know that if you are using the accessor it is because there is “something else to it”

• this is the only reason to violate rule #1.

4) Avoid using Protected Fields. Derived classes should always use the accessor, never direct access to the field.

Answer 10

Alan says he will use privates unless someone says the iphone only comes in black