Properties and Methods

Question

I'm new to the .NET world having come from C++ and I'm trying to better understand properties. I noticed in the .NET framework Microsoft uses properties all over the place. Is there an advantage for using properties rather than creating get/set methods? Is there a general guideline (as well as naming convention) for when one should use properties?

Answer 1

properties are get/set methods

Answer 2

It is pure syntactic sugar. On the back end, it is compiled into plain get and set methods.

Use it because of convention, and that it looks nicer.

Some guidelines are that when it has a high risk of throwing Exceptions or going wrong, don't use properties but explicit getters/setters. But generally even then they are used.

Answer 3

Consider reading Choosing Between Properties and Methods. It has a lot of information on .NET design guidelines.

Answer 4

The compiler actually emits get_MyProperty and set_MyProperty methods for each property you define.

Answer 5

Properties are get/set methods; simply, it formalises them into a single concept (for read and write), allowing (for example) metadata against the property, rather than individual members. For example:

[XmlAttribute("foo")]
public string Name {get;set;}

This is a get/set pair of methods, but the additional metadata applies to both. It also, IMO, simply makes it easier to use:

someObj.Name = "Fred"; // clearly a "set"
DateTime dob = someObj.DateOfBirth; // clearly a "get"

We haven't duplicated the fact that we're doing a get/set.

Another nice thing is that it allows simple two-way data-binding against the property ("Name" above), without relying on any magic patterns (except those guaranteed by the compiler).

Answer 6

There is an entire book dedicated to answering these sorts of questions: Framework Design Guidelines from Addison-Wesley. See section 5.1.3 for advice on when to choose a property vs a method.

Much of the content of this book is available on MSDN as well, but I find it handy to have it on my desk.

Answer 7

Properties are set and get methods as people around here have explained, but the idea of having them is making those methods the only ones playing with the private values (for instance, to handle validations).

The whole other logic should be done against the properties, but it's always easier mentally to work with something you can handle as a value on the left and right side of operations (properties) and not having to even think it is a method.

I personally think that's the main idea behind properties.

Answer 8

I always think that properties are the nouns of a class, where as methods are the verbs...

Answer 9

Properties simply save you some time from writing the boilerplate that goes along with get/set methods.

That being said, a lot of .NET stuff handles properties differently- for example, a Grid will automatically display properties but won't display a function that does the equivalent.

This is handy, because you can make get/set methods for things that you don't want displayed, and properties for those you do want displayed.

Answer 10

Although it is not a hard and fast rule and, as others have pointed out, Properties are implemented as Get/Set pairs 'behind the scenes' - typically Properties surface encapsulated/protected state data whereas Methods (aka Procedures or Functions) do work and yield the result of that work.

As such Methods will take often arguments that they might merely consume but also may return in an altered state or may produce a new object or value as a result of the work done.

Generally speaking - if you need a way of controlling access to data or state then Properties allow the implementation that access in a defined, validatable and optimised way (allowing access restriction, range & error-checking, creation of backing-store on demand and a way of avoiding redundant setting calls).

In contrast, methods transform state and give rise to new values internally and externally without necessarily repeatable results.

Certainly if you find yourself writing procedural or transformative code in a property, you are probably really writing a method.

Answer 11

Also note that properties are available via reflection. While methods are, too, properties represent "something interesting" about the object. If you are trying to display a grid of properties of an object-- say, something like the Visual Studio form designer-- then you can use reflection to query the properties of a class, iterate through each property, and interrogate the object for its value.

Answer 12

First of all, the naming convention is: use PascalCase for the property name, just like with methods. Also, properties should not contain very complex operations. These should be done kept in methods.

In OOP, you would describe an object as having attributes and functionality. You do that when designing a class. Consider designing a car. Examples for functionality could be the ability to move somewhere or activate the wipers. Within your class, these would be methods. An attribute would be the number of passengers within the car at a given moment. Without properties, you would have two ways to implement the attribute:

Make a variable public:

// class Car
public int passengerCount = 4;

// calling code
int count = myCar.passengerCount;

This has several problems. First of all, it is not really an attribute of the vehicle. You have to update the value from inside the Car class to have it represent the vehicles true state. Second, the variable is public and could also be written to.

The second variant is one widley used, e. g. in Java, where you do not have properties like in c#:

Use a method to encapsulate the value and maybe perform a few operations first.

// class Car
public int GetPassengerCount()
{
   // perform some operation
   int result = CountAllPassengers();

   // return the result
   return result;
}

// calling code
int count = myCar.GetPassengerCount();

This way you manage to get around the problems with a public variable. By asking for the number of passengers, you can be sure to get the most recent result since you recount before answering. Also, you cannot change the value since the method does not allow it. The problem is, though, that you actually wanted the amount of passengers to be an attribute, not a function of your car.

The second approach is not necessarily wrong, it just does not read quite right. That's why some languages include ways of making attributes look like variables, even though they work like methods behind the scenes. Actionscript for example also includes syntax to define methods that will be accessed in a variable-style from within the calling code.

Keep in mind that this also brings responsibility. The calling user will expect it to behave like an attribute, not a function. so if just asking a car how many passengers it has takes 20 seconds to load, then you probably should pack that in a real method, since the caller will expect functions to take longer than accessing an attribute.

EDIT: I almost forgot to mention this: The ability to actually perform certain checks before letting a variable be set. By just using a public variable, you could basically write anything into it. The setter method or property give you a chance to check it before actually saving it.

Answer 13

Think of it this way, Properties encapsulate your fields (commoningly marked private) while at the same time provides your fellow developers to either set or get the field value. You can even perform routine validation in the property's set method should you desire.