properties vs functions

[Kondapanaidu]

Hi,

What is the difference between Properties and functions.


Why dont we go for functions instead of properties.


Regrads

 

[Michael C]

Hi,

What is the difference between Properties and functions.


Why dont we go for functions instead of properties.

Properties is just a cleaner way of doing things. Instead of having, for
example, Start, Stop and IsRunning methods we can just have a Running
property that can be written to or read. A property usuaully indicates there
is little work involved although this is only a general rule.

Michael

 

[Peter Duniho]

What is the difference between Properties and functions.

Define "functions". IMHO, both properties and methods (the labels that .NET
uses) are functions.

Why dont we go for functions instead of properties.

If you mean "why don't we go for methods instead of properties", IMHO it's
all about using the language to more clearly describe what something does.

To me, a property is a way to get or set some state of a class (oddly
enough, this fits very well with how one defines a property ). A method
is a part of a class that actually *does* something. Obviously, you could
use a method to get or set state. You could even use a property to actually
*do* something. But in the latter case, you would always have to return
something or accept a value. One of the things I'm finding is that, because
of the strong emphasis on exception handling in .NET, very few of my methods
ever actually return something and those that do are almost always returning
an object (often newly created).

So in a large majority of cases, another major differentiating factor is
that properties always have data going into or out of the class, while a
method does not return any specific value.

Yet another way to look at it is that properties are often a bi-directional
way to communicate to a class. That is, data can go either direction in a
symmetric way. That's not strictly required, of course, and I do have
plenty of read-only properties (I even made a write-only property once...I'm
still trying to figure out if I like that or not ). Methods may be
bidirectional in some sense, but you have to go to some trouble to make them
symmetrically so, and even if you do they won't have the clean,
easy-to-understand semantics of a property.

IMHO, whether to use a property or a method depends a LOT less on how much
work there is to do than the semantics of the actual function. I can well
imagine some state that requires a significant amount of work to change but
which would still more properly be implemented as a property, at the same
time that I can imagine a method that is relatively simple (maybe only a few
lines of code, even) and yet which would make no sense as a property at all.

Pete

 

[Guest]

What do u meant?
There is no difference, because the properties are the methods that are
generated automatically.

Properties give u high level to control your fields

What is the difference between Properties and functions.

--
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

 

[Kevin Spencer]

Good question. First, properties are actually functions (methods), but a
property may have both a setter and a getter accessor method, which are both
accessed via the Property name. Also, property getters and setters do not
have parameters (except in VB, of course). So, why use a Property instead of
a function?

Well, a property is generally something you treat as if it were a "property"
or "characteristic" or "state" of a class, whereas a method or function is
generally treated as a process, something to do or execute. For example,
System.Windows.Forms.Control has a property called "Height" which is the
height (in pixels) of the Control, a characteristic of the Control. Compare
this to the method OnLoad(EventArgs), which defines a process, something the
Control executes.

Contrast properties with fields in a class. A field is similar to a
variable, but exists at class level. It is a piece of data. A property may
*expose* a field or some data, via its getter and setter accessor methods,
but the methods are processes rather than data. What is the purpose of this
indirection?

There are several purposes. A field can be read to or written from. By
omitting the setter or getter method, a property can be read-only or
write-only. A property may expose a characteristic which is calculated, such
as the Size property of a Control. The Size property is of type
"System.Drawing.Size" and it contains both the Width and Height of the
Control. Rather than storing this data twice, it can be stored as Height and
Width, and exposed as a Size via properties, such as the following:

private int _Height;
private int _Width;
public int Height { get { return _Height; } set { _Height = value; } }
public int Width { get { return _Width; } set { _Width = value; } }
public Size Size
{
get { return new Size(_Width, _Height); }
set
{
_Width = value.Width;
_Height = value.Height;
}
}

There are, as I mentioned, other reasons why properties might be used
instead of fields. The bisc rule of thumb might be expressed as "If it is a
process, expose it as a method; if it is state, expose it as a property".

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

What You Seek Is What You Get.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Properties is just a cleaner way of doing things. Instead of having, for
example, Start, Stop and IsRunning methods we can just have a Running
property that can be written to or read.

Well if you check the framework those especific actions ( Start, Stop ) are
method, not properties.

The theory is that a property return/set part of the data of the instance
like Name, Address, Phone. Whether a method (or function) perform some
actions over the instance that can potentially change its status.

That's why IsRunning is a property , it only return an indication of the
status of the instance. And that is why Start and Stop are method as they
are indication of an action to be performed

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

What is the difference between Properties and functions.

Why dont we go for functions instead of properties.

I assume that you mean properties and methods.

C# uses the syntax:

public class Foobar
{
private int v;
...
public int V
{
get
{
return v;
}
set
{
v = value;
}
}

and

o.V = o.V + 123;

Java uses the syntax:

public class Foobar {
private int v;
...
public int getV() {
return v;
}
public void setV(int v) {
this.v = c;
}
}

and

o.setV(o.getV() + 123);

Both achieves the goal of encapsulating the access
to the private field.

Which is good.

The problem with the Java solution is that to use
reflection you need to rely on the method names starting
with get/is/set and thos enot being used for anything else.

The problem with the C# version is that nothing prevents
a coder from doing something completely different in the
get and set code.

In both cases you depend on the programmer using
the language correctly.

And therefore I do not consider any of the solution
optimal.

But apparently the C# team liked the C# syntax. Or they
had to provide something VB6/COM compatible. I dont know.

And you should *always* use the properties way in C#
even if you think the feature should not have been
in C# in the first place, because whoever reads your
code later will expect it that way.

Arne

 

[Bill Butler]

I assume that you mean properties and methods.

C# uses the syntax:

public class Foobar
{
private int v;
...
public int V
{
get
{
return v;
}
set
{
v = value;
}
}

and

o.V = o.V + 123;

even better
o.V += 123;
it uses the getters/setters under the covers, but otherwise it looks
just like a public variable.

Java uses the syntax:

public class Foobar {
private int v;
...
public int getV() {
return v;
}
public void setV(int v) {
this.v = c;
}
}

and

o.setV(o.getV() + 123);

Yup...Ick..I really wish Java had properties (and a few other C#
goodies)

Both achieves the goal of encapsulating the access
to the private field.

Which is good.

The problem with the Java solution is that to use
reflection you need to rely on the method names starting
with get/is/set and thos enot being used for anything else.

The problem with the C# version is that nothing prevents
a coder from doing something completely different in the
get and set code.

This applies equally to the java case.
I mean there is no reason that you can't do anything you want inside
your getters and setters...other than public ridicule and humiliation
that is. :^)

In both cases you depend on the programmer using
the language correctly.

Isn't that always the case

And therefore I do not consider any of the solution
optimal.

Not sure what you think would be preferable.

But apparently the C# team liked the C# syntax. Or they
had to provide something VB6/COM compatible. I dont know.

And you should *always* use the properties way in C#
even if you think the feature should not have been
in C# in the first place, because whoever reads your
code later will expect it that way.

Also properties are one of the best things since sliced bread.
Of course if they are used in a stupid fashion you still can get a bad
tasting sandwich

Bill

 

[Jon Skeet [C# MVP]]

The problem with the C# version is that nothing prevents
a coder from doing something completely different in the
get and set code.

That's not a problem. That's an advantage. There's nothing to say that
a property should map directly onto a private field. In many cases it
certainly doesn't - consider things like DateTime.Now, for instance.

Likewise, properties can provide validation etc.

Now, you *could* write a C# property called Name which actually
returned an address, but then you could write getName() in Java and
return an address equally - I doubt we'll ever get a programming
language which is able to chastise programmers for writing function
members whose job doesn't match their name.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

This applies equally to the java case.
I mean there is no reason that you can't do anything you want inside
your getters and setters...other than public ridicule and humiliation
that is. :^)

My point.

Isn't that always the case

Not necessarily.

Not sure what you think would be preferable.

Something that semantically limits what those
"whatevers" can do.

But I have not designed the super language yet.

Well - probably never will.

Also properties are one of the best things since sliced bread.
Of course if they are used in a stupid fashion you still can get a bad
tasting sandwich

To me it just adds extra syntax to the language without
really solving the problem.

But I guess that most people have things they like about
a language and things they do not like.

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

That's not a problem. That's an advantage. There's nothing to say that
a property should map directly onto a private field. In many cases it
certainly doesn't - consider things like DateTime.Now, for instance.

Likewise, properties can provide validation etc.

Now, you *could* write a C# property called Name which actually
returned an address, but then you could write getName() in Java and
return an address equally

That is exactly my point.

It is still a problem. For whatever reasons new syntax was
added to the language, which did not deliver any new
semantics.

I don't like that.

- I doubt we'll ever get a programming
language which is able to chastise programmers for writing function
members whose job doesn't match their name.

In general no. For get/set functionality then maybe.

Arne

 

[Jon Skeet [C# MVP]]

That is exactly my point.

It is still a problem. For whatever reasons new syntax was
added to the language, which did not deliver any new
semantics.

I don't like that.

Properties deliver increase readability. They're syntactic sugar, but
then so are a lot of features of C#. The one I love over Java is the
"using" statement - it does nothing you can't do with try/finally, but
it makes life a lot easier.

In general no. For get/set functionality then maybe.

Not without crippling what you're able to *genuinely* do within
properties.