Sign in to follow this  

Properties in C#

This topic is 4380 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

this seems like a useless feature. for instance:
public class GraphNode<T> : Node<T>
{
    private List<int> costs;

    public GraphNode() : base() { }
    public GraphNode(T value) : base(value) { }
    public GraphNode(T value, NodeList<T> neighbors) : base(value, neighbors) { }

    new public NodeList<T> Neighbors
    {
        get
        {
            if (base.Neighbors == null)
                base.Neighbors = new NodeList<T>();

            return base.Neighbors;
        }            
    }

    public List<int> Costs
    {
        get
        {
            if (costs == null)
                costs = new List<int>();

            return costs;
        }
    }
}



why? what purpose does this have besides making me type more?

Share this post


Link to post
Share on other sites
Think about this:

public const List<int> Costs
{
get
{
return costs;
}
}



Just exposing the member variable won’t let you control how its used.
Also, your get executed code when the list was null which is another thing a simple public member variable can’t do.

Hope this is what you were asking about...

Share this post


Link to post
Share on other sites
i'm new to the .NET universe, so forgive my ignorance. in my example, the Costs properties seems to make the private variable do two things: turn it into a public variable and give me a get "function". now why this is more preferable to me just writing my own get function is alluding me.

i'm trying to figure out the purpose of having properties in C# or any other language.

Share this post


Link to post
Share on other sites
Properties are inheritable:

using System;
using System.Collections.Generic;
using System.Text;

abstract class i {
abstract public int foo { get; set; }
};

class a:i{
public override int foo {
get {
return (42);
}
set { }
}
}

class b : i {
public override int foo {
get {
return (6);
}
set { }
}
}


class Program {
static void Main(string[] args) {
a A = new a();
b B = new b();
i I;

I = A;
Console.WriteLine("{0}\n", I.foo);
I = B;
Console.WriteLine("{0}\n", I.foo);
}
}




Not that individual get... set... couldn't do the same, but then they wouldn't be grouped and they wouldn't be able to be dropped as an inplace replacement of a variable of the same name.

[edit:

for example:


class foo{
public int bar;
}

//

foo_var.bar=stuff;

// Now you might want to add the get/set functionality:
class foo{
// version 2.0
private int priv_bar;
public int bar{
get{
return(priv_bar);
}
set{
if(value<0){
priv_bar=0;
}else{
priv_bar=value;
}
}
}
};

// Code everywhere else in the app does not need changed!
foo_var=stuff;


/edit]

Share this post


Link to post
Share on other sites
Advantages over getters and setters:

You have a unified name.

instanceA.foo = instanceB.foo = instanceC.foo;


A property isn't necessarily a member-returner.

public bool Valid {
get {
return someCondition;
}
}


Of course, properties are not an incredibly awesome feature. They're just nice to have, like operator overloading or the -> dereference in C++. I'm also not sure why you say they incur more typing. There's less typing with properties:


public Type Property {
get { return property; }
set { property = value; }
}


//Versus

public:
int getProperty() { return property; }
void setProperty(const Type &value) { property = value; }


30 less keystroke and easier copy-pasting [smile]

Share this post


Link to post
Share on other sites
I personally like it for code clarity.

I like more

Object.Property = something;
Object2.Property = Object.Property;

Vs

Object.SetProperty(Something);
Object2.SetProperty(Object.GetProperty());


Here's a sweet example of code clarity--only for numerical values though.

Object.Property++;

which is the same thing as (but much clearer and shorter than) ...

Object.SetProperty(Object.GetProperty() + 1);


Darkneon

Share this post


Link to post
Share on other sites
The really cool thing with properties is not the setters/getters; it's that you can use the runtime reflection to tell properties apart from member functions. When you open the Property Inspector window in the IDE designer, and click on a component (like a button, list box, or whatever), the properties you see are the ones declared as public properties. In fact, when you write your own class, your properties will show up there as well.

Similarly, Events are useful because you know what their semantics are, and you can find them on the Events property page (again using runtime reflection).

Yes, you can emulate all of these functions in C++ with getters and setters, but it actually is a lot more typing in the end (once you count all the runtime reflection support).

Share this post


Link to post
Share on other sites

This topic is 4380 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this