Related
I have a base class Base which needs to create instances of another type TRequired, however, only derived classes from Base know how to construct those.
Is it bad style to use an abstract property as factory method? e.g.
protected abstract TRequired NewTRequired { get; }
Should I use a method for some reason? Is there a guide why I should/shouldn't use a property here?
You should definitely use a method because accessing this member does something. Calling a method is a good way to let the code speak for itself in that regard.
Or, if you prefer another perspective: two subsequent accesses of the member will return different results. A good rule of thumb is to use a method whenever this is the case, in order to not violate the principle of least astonishment.
This looks like it's reading the result of a variable, even though if you know that NewTRequired is a property (as opposed to a field) you also know that in reality it's running arbitrary code:
var prototype = Factory.NewTRequired;
I have deliberately put the result into a variable called prototype in order to better show that even an informed reader of this code can be easily thrown off: it would not be unreasonable to see this and think "right, so NewTRequired is the prototype object for X". That reader would certainly be astonished by the result of code like this:
var eq = object.ReferenceEquals(prototype, Factory.NewTRequired);
Contrast this with a factory method. Now this code might give off a slight smell:
// hmmm... are we actually using this as a prototype?
// because it sure looks like an instance created just for the occasion.
var prototype = Factory.NewTRequired();
And this code will never astonish you:
// obviously should be false, the code screams "I am creating new instances!"
var eq = object.ReferenceEquals(Factory.NewTRequired(), Factory.NewTRequired());
A famous example of where this rule really should have been followed but was not is the DateTime.Now property.
I would recommend a method instead:
protected abstract TRequired CreateRequired();
Creation implies "work" occurring. This is a better fit for a method vs. a property, as a property getter implies something that will typically be returned quickly without executing much code.
Even your question title "property as factory method" implies that a factory method should be a method.
Properties are designed for things that "look like" fields, such as the location of an object.
A property that returns a new instance every time you get it is very poor design.
You should use a method instead.
Is it advisable to prefix an "Is" or a "Has" when creating a method that returns a Boolean. My feeling is that this practice is more suited to defining property names.
Say, we have a method like the following has some logic:
bool IsActivePage()
{
// Some logic to determine if the page is active...
}
Would it be more preferable to rename the method to GetActivePageStatus and then create a boolean property IsActivePage that returns the result of that method.
What is the .NET standard? All opinions will be appreciated?
The Framework Design Guidelines state that you should "give methods names that are verbs or verb phrases" since "typically methods act on data". Properties, on the other hand, should be named "using a noun, noun phrase, or an adjective" and "you can also prefix Boolean properties with Is, Can, or Has, but only where it adds value".
In this case, you are using a method rather than a property, probably since it is either expensive or has some side effects. I suggest you choose the name that provides the most clarity of what the returned value represents. The important part is that you're being consistent and that you're not confusing other developers with your convention.
I would be using
bool IsActivePage
{
get
{
// some logic
}
}
if the method has no side effects and is inexpensive.
I see no need to have both a method and a property for the same thing.
I vote for your solution: so YES, for methods , I personally think, it's better to have Get..Bla(), cause method intuitively, at least for me, is, not only something that returns a value to me, but also performs some calculations or calls other methods inside it, properties instead, just return value.
"Get" word, to me personally, seems DO SOMETHIGN+RETURN,
instead "Is" : check if this exists.
I think both are defensible. The key is really to think about how standardized a convention like this should be. In general, you should either decide at your team or company level about how to handle cases like this, and then be consistent after that. As long as code you and your company produce is clear to everyone involved, that's what matters.
I would say yes. All methods should start with an action verb to indicate that they do something. Is and Has are more suited for properties.
First, coding conventions are vitally important in any shared development project, or any project you expect to live beyond the first time you ship the code or set it down for a week.
That said, there are a number of .Net coding standards available on the Internet (Google is still your friend) and you should adhere to those documents as best you can. One exception is in a mixed language environment where different languages have different style conventions and you want to create a more common style that covers all of those languages. In that case, you should create a style document and publish it.
Would it be more preferable to rename
the method to GetActivePageStatus and
then create a boolean property
IsActivePage that returns the result
of that method.
I would probably not go this route. IMO either
a) the logic is very simple, and you can just put it in the property getter
b) the logic is not very simple, you want to put it in a method BUT NOT hide it inside a property where an unexpecting caller may incur unneeded overhead by using it inappropriately (ie not caching the value if there is significant overhead in calculating it)
This question already has answers here:
Exposing Member Objects As Properties or Methods in .NET
(7 answers)
Closed 9 years ago.
Which one is better to use when it come to return value for example
public int EmployeeAge
{
get{return intEmployeeAge};
}
And
public int EmployeeAge()
{
return intEmployeeAge;
}
Which one is better and why? And what is best programming practice to use when we have secnario like above ?
Properties are a useful way of expressing a feature of an object, allowing get/set in a common way that can be used by APIs like data-binding, reflection and serialization. So for simple values of the object, properties are handy. Properties can't take arguments, should not have significant side-effects*, and should return quickly and repeatably. Also, there is no such thing as an "extension property" (to mirror an extension method) nor a generic property.
(*=lazy loading etc isn't uncommon, however)
Methods (C# doesn't have functions) are better for expressing things that either change the state, or which have an expectation of taking some time and not necessarily being reproducible. They don't tend to work in binding / serialization etc.
Note that properties are actually just a special way of writing methods. There is little functional difference. It is all about expressing intent. The one thing you don't want to expose, however, is fields (the actual intEmployeeAge instance variable).
So I would have:
public int EmployeeAge { get{return intEmployeeAge}; }
or just (if on the Employee object):
public int Age { get{return intEmployeeAge}; }
Of course... then the question becomes "in what unit?" I assume that is years?
If all you need to do is return a value, use a property.
If you need to do something before returning a value, use a function.
Properties holds object data
Functions defines object behavior
Take a look at -> Property Usage Guidelines
Which one is better and why? And what is best programming practice to use when we have
secnario like above ?
I write in C# however I prefer to use Get/Set functions, for me it's just better way to express what I can get from object and how I can change it's state (and this methods are grouped by alphabet in Intelisense which is also nice). However, if team prefers other conventions it's not a problem but when I work on my own projects it's just easier to read API.
e.g
Obejct1 o = new Object1();
o.P1;
o.P2;
o.P3;
from looking to API you can't say what you change in a public API or what it a read only property, unless you use IDE that shows you a small icon showing actually what you can do.
Object1 o = new Object1();
o.GetP1();
o.SetP2();
o.SetP3();
One can easily find from API how data can be changed by type's clients.
A method returns values after work is completed and a value is the result of the work being done. I don't think this is what you are doing.
A property (accessor) is meant for returning variables, which seems to be what you're trying to achieve:
As per MSDN:
The accessor of a property contains
the executable statements associated
with getting (reading or computing) or
setting (writing) the property. The
accessor declarations can contain a
get accessor, a set accessor, or both.
The declarations take the following
forms:
public int EmployeeAge
{
get;
set;
}
Have a look here, as it gives a very good description on the uses of these.
Property is a way explore the internal data element of a class in a simple manner. We can implement a properties with the type-safe get and set method.Property is implicitly called using calling convention.Property works on compile and runtime.
Method is a block of code that contain a series of statements.Method is explicitly called.
Methods works on runtime.
I'm a little late to this party, but I'll just mention another surprising difference between a property and a parameterless "get" method. As #MarcGravell notes, lazy loading is a common pattern when using properties, but beware of the Heisenberg Watch Window gotcha!
I think this has a lot to do with the culture you are programming in. As I see it, the C# / .NET culture would prefer to use a property for this case.
My advice: Try to be consistent with the main libraries you are using.
BUT: Be wary of using properties (or functions that serve the same purpose, as in your example above), as they are often a sign of bad design. You want to tell your objects to do stuff, as opposed to asking them for information. Don't be religious about this, though, just be aware of this as a code smell.
This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
Properties vs Methods
In method you can type some code and in properties too. For example I have a property Name. When class name changes I would like to get some data from database and change state of my object. I can add this code to set part of my property. Other solution is to change set part to private and add method called SetName and in this method add my code.
So what is the difference? When is the point when it's not good to put some code to getter / setter and when to create own method that is used to change my property and other parts of my class?
Here is a good set of guidelines for when to use properties vs methods from Bill Wagner (fixed link)
Use a Property when all these are true:
The getters should be simple and thus unlikely to throw exceptions. Note that this implies no network (or database) access. Either might fail, and therefore would throw an exception.
They should not have dependencies on each other. Note that this would include setting one property and having it affect another. (For example, setting the FirstName property would affect a read-only FullName property that composed the first name + last name properties implies such a dependency )
They should be settable in any order
The getter does not have an observable side effect Note this guideline doesn't preclude some forms of lazy evaluation in a property.
The method must always return immediately. (Note that this precludes a property that makes a database access call, web service call, or other similar operation).
Use a method if the member returns an array.
Repeated calls to the getter (without intervening code) should return the same value.
Repeated calls to the setter (with the same value) should yield no difference from a single call.
The get should not return a reference to internal data structures (See item 23). A method could return a deep copy, and could avoid this issue.
Given a property like this
private string _name;
public string Name { get { return _name; } set { _name = value; } }
it is possible to write the following two methods:
public string get_Name() { return _name; }
public void set_Name(string value) { _name = value; }
which act identically. And in fact, this is exactly what the compiler does for you when you create a property.
Generally speaking, I steer away from properties when the code within them starts to feel "expensive", if that makes any sense. I want properties to feel like fields (with controlled side effects that happen at specific times), so they should be lightweight.
A property is nothing but some syntactic sugar.
In some cases, it is better to define a property instead of a method because it is clearer / more readable.
Design guidelines state that, when the functionality you're implementing is expensive, a method should be preferred over a property.
in fact, a property is implemented as one or two methods; depending whether your property has a setter or not. The property is translated into a get_xxx and a set_xxx method.
Coming to think of it, Properties are more than just syntactic sugar. They are the public face of your member data to you member code.
Thus, giving you a clean layer for retrieval or input of a single aspect of you member data from you code.
A DTO for example is nothing but a bunch of well written properties, cleaving data and behavior efficiently.
Without a DTO would you imagine tightly coupling your DataGrid or Dropdown to complex business logic method?
Put it simply, Methods are actually doing the work...Properties either instigate action or get the status.
Though, you can use method code inside your properties ...it is not what they are meant for. Even, if you have to you are better of making a clean call to another method inside the property instead of actually writing you code in it. HTH!
Whenever I've come across the need to put code in a getter/setter I put the code in a private method and call that method from within the getter/setter. That way the code is available in a method call should I need it elsewhere. Not sure if this is the answer you were seeking but it is just a methodology I use.
There is basically no difference (except for the reserved identifier "value" in a setter).
Getters and setters get internally translated into standard methods such that the runtime has no idea whether some getter or setter is associated with a certain property. The term syntactic sugar is often used for convenience constructs like these.
However, there is an important software engineering benefit: your code tends to be easier to understand if you restrict yourself to use getters and setters with get and set semantics. I.e. do only the steps necessary to provide the respective property.
A common use case for doing a bit of extra work is for instance the setting or getting of a property which is not directly backed by a member field. For example, you've got a class that contains say a value that represents a distance. Your class could provide two Properties: Kilometers and Miles with respective setters and getters. Then you would do simple conversions in one pair and save yourself to store the value twice.
As a general rule of thumb, you should not put any code in a getter that has side effects. Also, the only side effect that code in a setter should have is the change of state in the object the setter refers to.
Essentially a property is a couple of methods - getProperty and setProperty. It is only the convention / simplification of the thing.
It is assumed that property getter has no side effects (well - they might have certain side effect, like lazy loading).
This probably isn't the most important difference, but one of the differences is that the debugger can be configured to step over properties (assuming their code is trivial).
In his excellent book, CLR Via C#, Jeffrey Richter said that he doesn't like properties, and recommends not to use them. He gave some reason, but I don't really understand. Can anyone explain to me why I should or should not use properties?
In C# 3.0, with automatic properties, does this change?
As a reference, I added Jeffrey Richter's opinions:
• A property may be read-only or write-only; field access is always readable and writable.
If you define a property, it is best to offer both get and set accessor methods.
• A property method may throw an exception; field access never throws an exception.
• A property cannot be passed as an out or ref parameter to a method; a field can. For
example, the following code will not compile:
using System;
public sealed class SomeType
{
private static String Name
{
get { return null; }
set {}
}
static void MethodWithOutParam(out String n) { n = null; }
public static void Main()
{
// For the line of code below, the C# compiler emits the following:
// error CS0206: A property or indexer may not
// be passed as an out or ref parameter
MethodWithOutParam(out Name);
}
}
• A property method can take a long time to execute; field access always completes immediately.
A common reason to use properties is to perform thread synchronization, which
can stop the thread forever, and therefore, a property should not be used if thread synchronization
is required. In that situation, a method is preferred. Also, if your class can be
accessed remotely (for example, your class is derived from System.MashalByRefObject),
calling the property method will be very slow, and therefore, a method is preferred to a
property. In my opinion, classes derived from MarshalByRefObject should never use
properties.
• If called multiple times in a row, a property method may return a different value each
time; a field returns the same value each time. The System.DateTime class has a readonly
Now property that returns the current date and time. Each time you query this
property, it will return a different value. This is a mistake, and Microsoft wishes that they
could fix the class by making Now a method instead of a property.
• A property method may cause observable side effects; field access never does. In other
words, a user of a type should be able to set various properties defined by a type in any
order he or she chooses without noticing any different behavior in the type.
• A property method may require additional memory or return a reference to something
that is not actually part of the object's state, so modifying the returned object has no
effect on the original object; querying a field always returns a reference to an object that
is guaranteed to be part of the original object's state. Working with a property that
returns a copy can be very confusing to developers, and this characteristic is frequently
not documented.
Jeff's reason for disliking properties is because they look like fields - so developers who don't understand the difference will treat them as if they're fields, assuming that they'll be cheap to execute etc.
Personally I disagree with him on this particular point - I find properties make the client code much simpler to read than the equivalent method calls. I agree that developers need to know that properties are basically methods in disguise - but I think that educating developers about that is better than making code harder to read using methods. (In particular, having seen Java code with several getters and setters being called in the same statement, I know that the equivalent C# code would be a lot simpler to read. The Law of Demeter is all very well in theory, but sometimes foo.Name.Length really is the right thing to use...)
(And no, automatically implemented properties don't really change any of this.)
This is slightly like the arguments against using extension methods - I can understand the reasoning, but the practical benefit (when used sparingly) outweighs the downside in my view.
Well, lets take his arguments one by one:
A property may be read-only or
write-only; field access is always
readable and writable.
This is a win for properties, since you have more fine-grained control of access.
A property method may throw an
exception; field access never throws
an exception.
While this is mostly true, you can very well call a method on a not initialized object field, and have an exception thrown.
• A property cannot be passed as an
out or ref parameter to a method; a
field can.
Fair.
• A property method can take a long
time to execute; field access always
completes immediately.
It can also take very little time.
• If called multiple times in a row, a
property method may return a different
value each time; a field returns the
same value each time.
Not true. How do you know the field's value has not changed (possibly by another thread)?
The System.DateTime class has a
readonly Now property that returns the
current date and time. Each time you
query this property, it will return a
different value. This is a mistake,
and Microsoft wishes that they could
fix the class by making Now a method
instead of a property.
If it is a mistake it's a minor one.
• A property method may cause
observable side effects; field access
never does. In other words, a user of
a type should be able to set various
properties defined by a type in any
order he or she chooses without
noticing any different behavior in the
type.
Fair.
• A property method may require
additional memory or return a
reference to something that is not
actually part of the object's state,
so modifying the returned object has
no effect on the original object;
querying a field always returns a
reference to an object that is
guaranteed to be part of the original
object's state. Working with a
property that returns a copy can be
very confusing to developers, and this
characteristic is frequently not
documented.
Most of the protestations could be said for Java's getters and setters too --and we had them for quite a while without such problems in practice.
I think most of the problems could be solved by better syntax highlighting (i.e differentiating properties from fields) so the programmer knows what to expect.
I haven't read the book, and you haven't quoted the part of it you don't understand, so I'll have to guess.
Some people dislike properties because they can make your code do surprising things.
If I type Foo.Bar, people reading it will normally expect that this is simply accessing a member field of the Foo class. It's a cheap, almost free, operation, and it's deterministic. I can call it over and over, and get the same result every time.
Instead, with properties, it might actually be a function call. It might be an infinite loop. It might open a database connection. It might return different values every time I access it.
It is a similar argument to why Linus hates C++. Your code can act surprising to the reader. He hates operator overloading: a + b doesn't necessarily mean simple addition. It may mean some hugely complicated operation, just like C# properties. It may have side effects. It may do anything.
Honestly, I think this is a weak argument. Both languages are full of things like this. (Should we avoid operator overloading in C# as well? After all, the same argument can be used there)
Properties allow abstraction. We can pretend that something is a regular field, and use it as if it was one, and not have to worry about what goes on behind the scenes.
That's usually considered a good thing, but it obviously relies on the programmer writing meaningful abstractions. Your properties should behave like fields. They shouldn't have side effects, they shouldn't perform expensive or unsafe operations. We want to be able to think of them as fields.
However, I have another reason to find them less than perfect. They can not be passed by reference to other functions.
Fields can be passed as ref, allowing a called function to access it directly. Functions can be passed as delegates, allowing a called function to access it directly.
Properties... can't.
That sucks.
But that doesn't mean properties are evil or shouldn't be used. For many purposes, they're great.
Back in 2009, this advice merely seemed like bellyaching of the Who Moved My Cheese variety. Today, it's almost laughably obsolete.
One very important point that many answers seem to tiptoe around but don't quite address head on is that these purported "dangers" of properties are an intentional part of the framework design!
Yes, properties can:
Specify different access modifiers for the getter and setter. This is an advantage over fields. A common pattern is to have a public getter and a protected or internal setter, a very useful inheritance technique which isn't achievable by fields alone.
Throw an exception. To date, this remains one of the most effective methods of validation, especially when working with UI frameworks that involve data-binding concepts. It's much more difficult to ensure that an object remains in a valid state when working with fields.
Take a long time to execute. The valid comparison here is with methods, which take equally long - not fields. No basis is given for the statement "a method is preferred" other than one author's personal preference.
Return different values from its getter on subsequent executions. This almost seems like a joke in such close proximity to the point extolling the virtues of ref/out parameters with fields, whose value of a field after a ref/out call is pretty much guaranteed to be different from its previous value, and unpredictably so.
If we're talking about the specific (and practically academic) case of single-threaded access with no afferent couplings, it's fairly well understood that it's just bad property design to have visible-state-changing side-effects, and maybe my memory is fading, but I just can't seem to recall any examples of folks using DateTime.Now and expecting the same value to come out every time. At least not any instances where they wouldn't have screwed it up just as badly with a hypothetical DateTime.Now().
Cause observable side effects - which is of course precisely the reason properties were invented as a language feature in the first place. Microsoft's own Property Design guidelines indicate that setter order shouldn't matter, as to do otherwise would imply temporal coupling. Certainly, you can't achieve temporal coupling with fields alone, but that's only because you can't cause any meaningful behaviour at all to happen with fields alone, until some method is executed.
Property accessors can actually help prevent certain types of temporal coupling by forcing the object into a valid state before any action is taken - for example, if a class has a StartDate and an EndDate, then setting the EndDate before the StartDate could force the StartDate back as well. This is true even in multi-threaded or asynchronous environments, including the obvious example of an event-driven user interface.
Other things that properties can do which fields can't include:
Lazy loading, one of the most effective ways of preventing initialization-order errors.
Change Notifications, which are pretty much the entire basis for the MVVM architecture.
Inheritance, for example defining an abstract Type or Name so derived classes can provide interesting but nevertheless constant metadata about themselves.
Interception, thanks to the above.
Indexers, which everyone who has ever had to work with COM interop and the inevitable spew of Item(i) calls will recognize as a wonderful thing.
Work with PropertyDescriptor which is essential for creating designers and for XAML frameworks in general.
Richter is clearly a prolific author and knows a lot about the CLR and C#, but I have to say, it seems like when he originally wrote this advice (I'm not sure if it's in his more recent revisions - I sincerely hope not) that he just didn't want to let go of old habits and was having trouble accepting the conventions of C# (vs. C++, for example).
What I mean by this is, his "properties considered harmful" argument essentially boils down to a single statement: Properties look like fields, but they might not act like fields. And the problem with the statement is, it isn't true, or at best it's highly misleading. Properties don't look like fields - at least, they aren't supposed to look like fields.
There are two very strong coding conventions in C# with similar conventions shared by other CLR languages, and FXCop will scream at you if you don't follow them:
Fields should always be private, never public.
Fields should be declared in camelCase. Properties are PascalCase.
Thus, there is no ambiguity over whether Foo.Bar = 42 is a property accessor or a field accessor. It's a property accessor and should be treated like any other method - it might be slow, it might throw an exception, etc. That's the nature of Abstraction - it's entirely up to the discretion of the declaring class how to react. Class designers should apply the principle of least surprise but callers should not assume anything about a property except that it does what it says on the tin. That's on purpose.
The alternative to properties is getter/setter methods everywhere. That's the Java approach, and it's been controversial since the beginning. It's fine if that's your bag, but it's just not how we roll in the .NET camp. We try, at least within the confines of a statically-typed system, to avoid what Fowler calls Syntactic Noise. We don't want extra parentheses, extra get/set warts, or extra method signatures - not if we can avoid them without any loss of clarity.
Say whatever you like, but foo.Bar.Baz = quux.Answers[42] is always going to be a lot easier to read than foo.getBar().setBaz(quux.getAnswers().getItem(42)). And when you're reading thousands of lines of this a day, it makes a difference.
(And if your natural response to the above paragraph is to say, "sure it's hard to read, but it would be easier if you split it up in multiple lines", then I'm sorry to say that you have completely missed the point.)
I don't see any reasons why you shouldn't use Properties in general.
Automatic properties in C# 3+ only simplify syntax a bit (a la syntatic sugar).
It's just one person's opinion. I've read quite a few c# books and I've yet to see anyone else saying "don't use properties".
I personally think properties are one of the best things about c#. They allow you to expose state via whatever mechanism you like. You can lazily instantiate the first time something is used and you can do validation on setting a value etc. When using and writing them, I just think of properties as setters and getters which a much nicer syntax.
As for the caveats with properties, there are a couple. One is probably a misuse of properties, the other can be subtle.
Firstly, properties are types of methods. It can be surprising if you place complicated logic in a property because most users of a class will expect the property to be fairly lightweight.
E.g.
public class WorkerUsingMethod
{
// Explicitly obvious that calculation is being done here
public int CalculateResult()
{
return ExpensiveLongRunningCalculation();
}
}
public class WorkerUsingProperty
{
// Not at all obvious. Looks like it may just be returning a cached result.
public int Result
{
get { return ExpensiveLongRunningCalculation(); }
}
}
I find that using methods for these cases helps to make a distinction.
Secondly, and more importantly, properties can have side-effects if you evaluate them while debugging.
Say you have some property like this:
public int Result
{
get
{
m_numberQueries++;
return m_result;
}
}
Now suppose you have an exception that occurs when too many queries are made. Guess what happens when you start debugging and rollover the property in the debugger? Bad things. Avoid doing this! Looking at the property changes the state of the program.
These are the only caveats I have. I think the benefits of properties far outweigh the problems.
That reason must have been given within a very specific context. It's usually the other way round - it is recomended to use properties as they give you a level of abstraction enabling you to change behaviour of a class without affecting its clients...
I can't help picking on the details of Jeffrey Richter's opinions:
A property may be read-only or write-only; field access is always readable and writable.
Wrong: Fields can marked read-only so only the object's constructor can write to them.
A property method may throw an exception; field access never throws an exception.
Wrong: The implementation of a class can change the access modifier of a field from public to private. Attempts to read private fields at runtime will always result in an exception.
I don't agree with Jeffrey Richter, but I can guess why he doesn't like properties (I haven't read his book).
Even though, properties are just like methods (implementation-wise), as a user of a class, I expect that its properties behave "more or less" like a public field, e.g:
there's no time-consuming operation going on inside the property getter/setter
the property getter has no side effects (calling it multiple times, does not change the result)
Unfortunately, I have seen properties which did not behave that way. But the problem are not the properties themselves, but the people who implemented them. So it just requires some education.
The argument assumes that properties are bad because they look like fields, but can do surprising actions. This assumption is invalidated by .NET programmers' expectactions:
Properties don't look like fields. Fields look like properties.
• A property method may throw an exception; field access never throws an exception.
So, a field is like a property that is guaranteed to never throw an exception.
• A property cannot be passed as an out or ref parameter to a method; a field can.
So, a field is like a property, but it has additional capabilities: passing to a ref/out accepting methods.
• A property method can take a long time to execute; field access always completes immediately. [...]
So, a field is like a fast property.
• If called multiple times in a row, a property method may return a different value each time; a field returns the same value each time. The System.DateTime class has a readonly Now property that returns the current date and time.
So, a field is like a property that is guaranteed to return the same value unless the field was set to a different value.
• A property method may cause observable side effects; field access never does.
Again, a field is a property that is guaranteed to not do that.
• A property method may require additional memory or return a reference to something that is not actually part of the object's state, so modifying the returned object has no effect on the original object; querying a field always returns a reference to an object that is guaranteed to be part of the original object's state. Working with a property that returns a copy can be very confusing to developers, and this characteristic is frequently not documented.
This one may be surprising, but not because it's a property that does this. Rather, it's that barely anyone returns mutable copies in properties, so that 0.1% case is surprising.
There is a time when I consider not using properties, and that is in writing .Net Compact Framework code. The CF JIT compiler does not perform the same optimisation as the desktop JIT compiler and does not optimise simple property accessors, so in this case adding a simple property causes a small amount of code bloat over using a public field. Usually this wouldn't be an issue, but almost always in the Compact Framework world you are up against tight memory constraints, so even tiny savings like this do count.
You shouldn't avoid using them but you should use them with qualification and care, for the reasons given by other contributors.
I once saw a property called something like Customers that internally opened an out-of-process call to a database and read the customer list. The client code had a 'for (int i to Customers.Count)' which was causing a separate call to the database on each iteration and for the access of the selected Customer. That's an egregious example that demonstrates the principle of keeping the property very light - rarely more than a internal field access.
One argument FOR using properties is that they allow you to validate the value being set. Another is that the value of of the property may be a derived value, not a single field, like TotalValue = amount * quantity.
Personally I only use properties when creating simple get / set methods. I stray away from it when coming to complicated data structures.
I haven't read his book but I agree with him.
It's quite a contradiction on the usual paradigm.
They look like a field but had many sideeffects. Exceptions, performance, sideeffects, read/write access difference, etc.
If you care about readability and reliability i think you'd care about this as well.
In my experience i never gained anything from properties and only felt like using them when i was lazy.
But many times i encountered people using properties as if they were fields inadvertently creating all sort of issues.
Ive worked professionally on many languages for quite a time and never needed them, not even once.
Of course other people might find them useful and that's fine too.
Depends on your user case and what you value.
I personally believe they are just 'features ' that you can choose to use or not.
Invoking methods instead of properties greatly reduces the readability of the invoking code. In J#, for example, using ADO.NET was a nightmare because Java doesn't support properties and indexers (which are essentially properties with arguments). The resulting code was extremely ugly, with empty parentheses method calls all over the place.
The support for properties and indexers is one of the basic advantages of C# over Java.