Re: How to emluate "properties" in Java?
Peter Duniho wrote:
markspace wrote:
[ SNIP ]
The best thing I've seen so far was the abbreviated syntax for
declaring getters and setters.
Ironically, that's the least useful aspect of properties in C#. It's
helpful in defining simple classes, especially immutable data
containers. But most non-trivial classes will have additional logic,
especially in the setter. And of course, the abbreviated syntax is not
useful if one needs to provide any specific implementation.
Pete
That abbreviated syntax, which for you is the least useful aspect of
properties in C#, may well be the most useful aspect of properties for
most C# programmers. I doubt very much that the majority of C# writers
are doing anything but jamming in those { get; set; } pairs for each
field they want to expose.
Even MS in its API doesn't claim more for properties than:
"Properties are members that provide a flexible mechanism to read,
write, or compute the values of private fields. Properties can be used
as if they are public data members, but they are actually special
methods called accessors. This enables data to be accessed easily and
still helps promote the safety and flexibility of methods."
There really isn't anything deeper going on here.
My opinion is that C# properties would have more of the usefulness that
you impart to them, apart from the easier syntax (which as I've stated
is what I think most C# programmers get out of properties), if the
properties did *not* access other member fields. To me the following
snippet (I borrowed it because a lot of people use it) shows off
properties (and of this specific form I've seen very few examples):
class Accounting
{
public double Price { get; set; }
public int Quantity { get; set; }
public double Total
{
get { return Price * Quantity; }
}
}
and this (which I've seen many examples of) does not:
class Accounting
{
private double price;
private int quantity;
public double Price
{
get { return price; }
set { price = value; }
}
public int Quantity
{
get { return quantity; }
set { quantity = value; }
}
public double Total
{
get { return price * quantity; }
}
}
The second example to me is no different than Java accessors: entirely
up to the programmer what they access with these methods. Using the
classic form, with backing fields, has no real extra value at all. IMO.
I'm also of two minds about the property Total in this example. I
suppose if one were making a declaration about object state, and held
that the derived read-only value Total is as much a primary component of
Accounting object state as Price or Quantity, I could live with it.
Myself though I'd keep Total a method, and drop the property syntax.
AHS