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;
}
}
}
Properties in C#
this seems like a useless feature. for instance:
why?
what purpose does this have besides making me type more?
What properties are you talking about? The get_ set_ ones? That's so you can have public variables and not have to write Get()/Set() functions.
Think about this:
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...
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...
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.
i'm trying to figure out the purpose of having properties in C# or any other language.
Properties are inheritable:
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:
/edit]
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]
Advantages over getters and setters:
You have a unified name.
A property isn't necessarily a member-returner.
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:
//Versus
30 less keystroke and easier copy-pasting [smile]
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]
I personally like it for code clarity.
I like more
Here's a sweet example of code clarity--only for numerical values though.
which is the same thing as (but much clearer and shorter than) ...
Darkneon
I like more
Object.Property = something;Object2.Property = Object.Property;VsObject.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
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).
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).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement