Get and set properties
-
hai,what is the main difference between "methods" and "get" "set" properties? In properties we can assign and return values , but the same thing is possible in methods also and even calling the properties and methods is also similar.my question is why we go for properties?? thank u:rolleyes:
dot net !!! definetely a revolution
-
hai,what is the main difference between "methods" and "get" "set" properties? In properties we can assign and return values , but the same thing is possible in methods also and even calling the properties and methods is also similar.my question is why we go for properties?? thank u:rolleyes:
dot net !!! definetely a revolution
Hi, you dont need properties, but they make things easier and more readable. which statement do you prefer:
myForm.Width+=100;
myForm.SetWidth(myForm.GetWidth()+100);
:)
Luc Pattyn
try { [Search CP Articles] [Search CP Forums] [Forum Guidelines] [My Articles] } catch { [Google] }
-
hai,what is the main difference between "methods" and "get" "set" properties? In properties we can assign and return values , but the same thing is possible in methods also and even calling the properties and methods is also similar.my question is why we go for properties?? thank u:rolleyes:
dot net !!! definetely a revolution
- Some features of C# rely on properties: i.e. design support and heavy use of attributes - Properties are inlined (if I'm not mistaken) - property link a set and get "method" together. - properties are used i.e. in xml serialization (properties are serialized by default, fields not (and methods of course, too)) - I think it makes code more readable then properties stand for the state of an object where as methods stand for actions on this state.
-^-^-^-^-^- no risk no funk
-
hai,what is the main difference between "methods" and "get" "set" properties? In properties we can assign and return values , but the same thing is possible in methods also and even calling the properties and methods is also similar.my question is why we go for properties?? thank u:rolleyes:
dot net !!! definetely a revolution
Properties and methods are semantically different. The normal behaviour of a property is that it represents a single value in the object. Getting the value should not change the state of the object. Setting the value should not change the state of the object in any other way than is reasonable to expect for the change of that property. A method on the other hand may take any form, contain a simple or complex process, and change the state of the object in any way.
--- single minded; short sighted; long gone;
-
- Some features of C# rely on properties: i.e. design support and heavy use of attributes - Properties are inlined (if I'm not mistaken) - property link a set and get "method" together. - properties are used i.e. in xml serialization (properties are serialized by default, fields not (and methods of course, too)) - I think it makes code more readable then properties stand for the state of an object where as methods stand for actions on this state.
-^-^-^-^-^- no risk no funk
-
- Some features of C# rely on properties: i.e. design support and heavy use of attributes - Properties are inlined (if I'm not mistaken) - property link a set and get "method" together. - properties are used i.e. in xml serialization (properties are serialized by default, fields not (and methods of course, too)) - I think it makes code more readable then properties stand for the state of an object where as methods stand for actions on this state.
-^-^-^-^-^- no risk no funk
Urs Enzler wrote:
Properties are inlined (if I'm not mistaken)
The JIT may choose to inline any method that's short enough. If a property setter or getter method is particularly long, it probably won't be inlined - the fact that it's a property is irrelevant. The CLR doesn't really 'understand' properties or events - the compiler is responsible for compiling a call to the correct underlying functions. In C# they're always called
set_Property,get_Propertyandadd_Event,remove_Eventrespectively (for a property calledPropertyand an event namedEvent). The metadata links them into a single property or event. An standard event written in C# also has a field of the appropriate delegate type which is invisible to the user. It's possible to write aneventwhich has customaddandremovemethods; Windows Forms does this, making use of a list so that for example Control (which has 69 events in .NET 2.0) does not need to have 69 delegate fields unnecessarily bloating the memory footprint of each object. The feature is so useful that the implementation mostly lives inSystem.ComponentModel.Component'sEventsproperty.Stability. What an interesting concept. -- Chris Maunder