C# – Should Fields or Properties Be Used?

cproperties

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

private string mWhatever;

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

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 don'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).

Best Answer

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.

Related Solutions

Objective-C Properties – Always or Public-Only Under ARC?

Can you provide me with a bit of reasoning for why I should stick to using properties for everything, or confirm my current train of thoughts as to why I should use more ivars and less properties only where needed?

Right now, I think it's fair to say that it's mostly a matter of style. As you say, the memory management benefit of properties is less important with ARC. On the other hand, the "benefits" of going back to direct ivar access aren't very compelling either:

A @property declaration is quite similar to an ivar declaration. Avoiding the @synthesize directive doesn't seem like a big win -- we're not talking about a lot of code.
The foo.something syntax is arguably a lot better than _something. Property access syntax is obviously designed to look like and work like C's dot syntax for accessing members of a structure. Being explicit about which object you're accessing (whether that's self or something else) is helpful. (Some people -- not me! -- advocate self->something for ivar access for this reason.) The leading underscore convention for ivars is fine, but it's not used consistently by all Objective-C code.
Properties seem a better choice for accessing data stored in other objects of the same class (which is allowed under "private" access) and for access by subclasses (like C++'s "protected"). So the 'properties == public' idea is somewhat blurry.
My sense is that properties were intended to simplify memory management and provide some other benefits. As you say, with the memory management benefit decreased, properties seem less compelling.

The path you've chosen -- going back to direct ivar access for internal data -- seems like a very reasonable choice and there's no obvious reason to change your course. But sticking to properties is also quite reasonable -- the drawbacks aren't significant, and there are some nice benefits like KVO compliance and a more consistent member access style.

Properties weren't the last step in the evolution of Objective-C, and I don't expect that ARC will be either. I don't have any specific information, but it seems like a good guess that additional features might be added at some point that make properties either more compelling or less so. We'll have to wait and see what happens.

C# Coding Standards – Correct Usage of Property vs Field vs Function

So, clearly, this is a field. It's a field because it is a private variable I'm keeping inside my class, and to recognize it, I add an underscore as a prefix.

This is not correct. It is not a field; it is a property. And that property is just syntactic sugar for a method, which the compiler creates for you. In this case that method would be IBeneficiary get__latestBeneficiary() => ...

Just because it is private, doesn't make it a field. a field is a variable, not a method.

Or even name it GetLatestBeneficiary, but in both cases this looks and feels like a really simple getter, so I'd rather have a property with a single getter, that does exactly this, like the following. Right?

The code:

IBeneficiary LatestBeneficiary
{
   get
   {
       return new Beneficiary(Iban, Name);
   }
}

is semantically identical to:

IBeneficiary _latestBeneficiary => new Beneficiary(Iban, Name);

The expression body syntax of the second version is just a more compact way of expressing that getter.

I feel like this then should be a function

I would tend to agree. Even though this is a private read-only property, it's still a read-only property (ie, getter). They carry expectation baggage: most developers would expect read-only properties to return the same value each time (especially if the state of the rest of the object hasn't changed). So following the principle of least astonishment, you should avoid using properties in this way.

So make it a method:

IBeneficiary CreateLatestBeneficiary() => new Beneficiary(Iban, Name);

Best Answer

Related Solutions

Objective-C Properties – Always or Public-Only Under ARC?

C# Coding Standards – Correct Usage of Property vs Field vs Function

Related Topic