Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
private string mWhatever;

private string Whatever
{
    get
    {
        return this.mWhatever;
    }
    set
    {
        this.mWhatever = value;
    }
}

I've seen some people who make properties for every single member, private or not... does this make any sense? I could see it making sense in 1% of the cases at times when you want to control access to the member inside the class containing it because if you didn't use properties for every member it would lead to inconsistencies and checking to see if the member has an access or not (since you have access to both in the scope of the class).

share|improve this question
add comment

8 Answers

up vote 12 down vote accepted

Short answer: Yes, when there is a need. Otherwise, use an Auto-Implemented Property getter and setter like private string Whatever { get; set;}

  • It is very handy When you are using a close domain approach
  • It is also handy when a specific logic should be checked when you are setting the value

Here is a full description of when you would be using private setters: C# property usage.

share|improve this answer
    
It's also really easy to make the property public later on if required. –  Tom Pickles 44 mins ago
add comment

Some good answers here already, but I think most of them miss one point of your question:

I've seen some people who make properties for every single member, private or not... does this make any sense?

I think this is seldom necessary beforehand, for every single member. Start with

 private string Whatever;

When you later come to a point where you need encapsulation or a conditional breakpoint for this specific member, you can still replace it by a property with same name - in most cases without changing the code which uses Whatever. But beware, there are subtle differences, see Brian Rasmussen's answer in this SO post (link also given by Emmad Kareem, +1).

share|improve this answer
    
+1, also, you are correct, most answers missed the original question points, we are typical IT guys :) –  Emmad Kareem Aug 15 '12 at 10:13
add comment

One of the biggest advantages of this approach is that you get control on when your variables change.

Consider the following.
You are debugging a large project. A certain method throws an exception. You set a breakpoint and you reveal that a certain member variable has wrong value. Say your code relies on this variable very extensively, and you find hundreds write usages (Spaghetti scenario). So you can't figure out which of these usages assigned a bad value.
If the code is multithreaded, debugging may become a real nightmare.

With property, you may set a breakpoint in a setter. Combined with a condition, it may be nailed down in a single run.

VC++ has data breakpoints, but it is only available for unmanaged code.

share|improve this answer
add comment

If you don't use a property, your only other option is to use a field to store variable data. Properties and fields have significant differences. Most of these differences are found Fields vs. Properties. I suggest you study the differences then make your choice according to your application needs. However, bear in mind that using fields instead of properties is not the common OO practice because of their nature and shortcoming.

share|improve this answer
add comment

Private properties can be very useful to encapsulate the behaviour of things which are internal to your class. Just because they are private doesn't mean that you shouldn't take advantage of the syntactic sugar that properties give you.

The example given however is a poor one. Boilerplate property getters and setters like this are almost always a bad idea. If you are using C# 3.0 or later then, auto properties are a much better idea:

private string Whatever { get; set }

This is shorter, cleaner and much more readable. In fact it is barely longer than just declaring the backing variable.

Most importantly though, auto propertues can be converted to full properties at any time without changing the semantics of the rest of the program! Thus if you need to add validation or error handling, you can do so easily.

As it is, I always thought it was a shame that you couldn't do

private readonly string Whatever { get; set }

or

private string Whatever { get; readonly set }

To enforce only being able to write to the value in the constructor, but then I prefer immutable types.

share|improve this answer
    
+1 for auto-properties –  Scott Whitlock Aug 15 '12 at 21:05
add comment

It's not absolutely necessary to do this for private properties, but it does allow for modifying how the property gets/sets the underlying value without changing how it is accessed.

For example, modifying how the underlying value is set:

private string Whatever
{
    get
    {
        return this.mWhatever;
    }
    set
    {
        this.mWhatever = string.IsNullOrEmpty(value) ? string.Empty : value;
    }
}
share|improve this answer
add comment

Yeah

I personally use this as the caching mechanism, and we might call it property-level caching.

private List<User> users;
private List<User> Users
{
    get
    {
        if(users == null) users = new UserManager().GetUsers();
        return users;
    }
}

Now in other places inside my class, I use Users property instead of users field.

Another feasible situation might be when you want to implement some logic on a field, but in a centralized way in a class. Thus you can both create a GetFoo() method, or a Foo property for foo field.

private string foo;
private string Foo
{
    get
    {
        return "Mr. " + foo;
    }
}
share|improve this answer
add comment

Something else to consider:

Actual properties are an implementation detail. One of the goals of OOP is to try and minimize the exposure of implementation details where practical.

The reason for this is if you hide the properties and only expose them through getters and setters, you have far more control. For example, your getter can validate its input and prevent the property being set to an invalid state. If the ability to change the value is time critical, then the setter can protect against this too. The getter, should getting the actual value be expensive for whatever reason, can do lazy initialization and/or caching.

Having getters and setters exposed and the properties hidden means sometimes you don't need a property at all. Your getter can compute the value on invocation, or delegate the task somewhere else, or anything that lets it meet its specification. What's important about your class is the information you can access from it, not how that information is represented internally.

Of course, if there's no negative consequences to anything outside the class being able to access a property directly, then you should just make it public. However in my experience, such cases are relatively few and far between.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.