| Groups | Blog | Home |
c# : C# property usage question
Hi,
I'm new to C#. Most examples about properties I found are sth like the following: class A{ private int property; public int Property { get { return property; } set { property = value; } } } My question is, Can I simply do the following: class A { public int Property; } Then later, if it turns out that I need to do sth when the property is set or get, I change it to class A{ public int Property { get { <do sth>; return ... } set { <do sth>; } } } This way, the code that uses A should still compile. Am I right? This way sounds much simpler to me, you don't have to write those repetitive get&set unless you later find out that you need. Is this the right way of using properties? Am I missing sth here? thanks vh
[quoted text, click to view] "vh" <veryhappyca@yahoo.ca> wrote in message news:e4cxBco2EHA.824@TK2MSFTNGP11.phx.gbl... > Hi, > I'm new to C#. Most examples about properties I found are sth like the > following: > class A{ > private int property; > public int Property { > get { return property; } > set { property = value; } > } > } > > My question is, Can I simply do the following: > class A { > public int Property; > } > > Then later, if it turns out that I need to do sth when the property is set > or get, I change it to > class A{ > public int Property { > get { <do sth>; return ... } > set { <do sth>; } > } > } > This way, the code that uses A should still compile. Am I right? This way > sounds much simpler to me, you don't have to write those repetitive > get&set > unless you later find out that you need. Is this the right way of using > properties? Am I missing sth here? > yes, an 'o', 'm', 'e','i','n', and a 'g'. Anyway, the primary differences are: 1) in already compiled code, changing to a property requires all dependent code to be recompiled. Field to property is a binary breaking change 2) Reflection works differently for fields and properties and therefore will cause code that works against one to break when it is applied against others. It may change serialization or other systems that use reflection. 3) a field may be passed as a ref argument to a method, a property may not. Changing the two will break any code which passes Property by ref(although thats a bad idea over all, IMHO). 4) public fields are considered bad form in libraries, mainly due to #1 and #2 above. If none of these issues apply to your case, you are in the clear. Otherwise, just get used to typing it and\or write a macro to do it for you.
[quoted text, click to view]
Daniel O'Connell [C# MVP] wrote: > > "vh" <veryhappyca@yahoo.ca> wrote in message > news:e4cxBco2EHA.824@TK2MSFTNGP11.phx.gbl... >> Hi, >> I'm new to C#. Most examples about properties I found are sth like the >> following: >> class A{ >> private int property; >> public int Property { >> get { return property; } >> set { property = value; } >> } >> } >> >> My question is, Can I simply do the following: >> class A { >> public int Property; >> } >> >> Then later, if it turns out that I need to do sth when the property is >> set or get, I change it to >> class A{ >> public int Property { >> get { <do sth>; return ... } >> set { <do sth>; } >> } >> } >> This way, the code that uses A should still compile. Am I right? This way >> sounds much simpler to me, you don't have to write those repetitive >> get&set >> unless you later find out that you need. Is this the right way of using >> properties? Am I missing sth here? >> > > yes, an 'o', 'm', 'e','i','n', and a 'g'. ?? [quoted text, click to view] > > Anyway, the primary differences are: > 1) in already compiled code, changing to a property requires all dependent > code to be recompiled. Field to property is a binary breaking change > (more field-to-property points snipped). If I read the OP right, the issue was not starting with a public field and changing it to a property later, but starting with an empty property and adding the "get" and "set" parts later.
Hi vh,
You are right - you *could* do: class A { public int Property; } but this allows anyone to change or read the value - so there would be no point in property accessors! This approach is really looked down apon for a number of reasons principle among them a subject called encapsulation - external classes shouldnt be able to "see" the internals of a class. They should only see what the class chooses to expose. - This prevents the client class from depending on the implementation of the class, which may subsequently change. For example. Imagine you have a class called age. If you let a client class set or get age in any which way it chooses, what happens when you want to restrict the sorts of ages that can be entered. Say you only want numbers between 0 and 120 to be entered? In a set property, you could provide that logic, whereas in a public variable the client classes can do whatever they want. Another example - quite often in larger projects you may not want client code to be able to both set and get particular values. Often you want one or the other. Anyway, there are all sorts of quite technical reasons why you shouldnt do direct access. When you begin to get more confident and want to start taking on larger projects and want to incorporate patterns and best practive examples, you really will want to have learned to do things the "correct" way seeing as everyone else is doing it. Even though at the moment you may not understand all the reasons for having to do things a particular way. One last thing - look into OO in general and more specifically encapsulation. This should help you understand why programmer like to compaetmentalise everything. (Think building blocks) HTH Take care Simon
[quoted text, click to view] "Joachim Pense" <spam-collector@pense-online.de> wrote in message news:cov5jq$2p7$05$2@news.t-online.com... > Joachim Pense wrote: > >> Daniel O'Connell [C# MVP] wrote: >> >>> >>> "vh" <veryhappyca@yahoo.ca> wrote in message >>> news:e4cxBco2EHA.824@TK2MSFTNGP11.phx.gbl... >>>> Hi, >>>> I'm new to C#. Most examples about properties I found are sth like the >>>> following: >>>> class A{ >>>> private int property; >>>> public int Property { >>>> get { return property; } >>>> set { property = value; } >>>> } >>>> } >>>> >>>> My question is, Can I simply do the following: >>>> class A { >>>> public int Property; >>>> } >>>> >>>> Then later, if it turns out that I need to do sth when the property is >>>> set or get, I change it to >>>> class A{ >>>> public int Property { >>>> get { <do sth>; return ... } >>>> set { <do sth>; } >>>> } >>>> } >>>> This way, the code that uses A should still compile. Am I right? This >>>> way sounds much simpler to me, you don't have to write those repetitive >>>> get&set >>>> unless you later find out that you need. Is this the right way of using >>>> properties? Am I missing sth here? >>>> >>> >>> yes, an 'o', 'm', 'e','i','n', and a 'g'. >> >> ?? >> >>> >>> Anyway, the primary differences are: >>> 1) in already compiled code, changing to a property requires all >>> dependent code to be recompiled. Field to property is a binary breaking >>> change >>> >> >> (more field-to-property points snipped). >> >> If I read the OP right, the issue was not starting with a public field >> and >> changing it to a property later, but starting with an empty property and >> adding the "get" and "set" parts later. >> > > Reading the OP again, it turns out that I posted nonsense. Sorry for > wasting > the bandwidths. np. I do find this to be one major missing feature in C#. IMHO they should have added a property keyword and allowed simple public property int Property; but...its not that way and probably never will be.
[quoted text, click to view]
Joachim Pense wrote: > Daniel O'Connell [C# MVP] wrote: > >> >> "vh" <veryhappyca@yahoo.ca> wrote in message >> news:e4cxBco2EHA.824@TK2MSFTNGP11.phx.gbl... >>> Hi, >>> I'm new to C#. Most examples about properties I found are sth like the >>> following: >>> class A{ >>> private int property; >>> public int Property { >>> get { return property; } >>> set { property = value; } >>> } >>> } >>> >>> My question is, Can I simply do the following: >>> class A { >>> public int Property; >>> } >>> >>> Then later, if it turns out that I need to do sth when the property is >>> set or get, I change it to >>> class A{ >>> public int Property { >>> get { <do sth>; return ... } >>> set { <do sth>; } >>> } >>> } >>> This way, the code that uses A should still compile. Am I right? This >>> way sounds much simpler to me, you don't have to write those repetitive >>> get&set >>> unless you later find out that you need. Is this the right way of using >>> properties? Am I missing sth here? >>> >> >> yes, an 'o', 'm', 'e','i','n', and a 'g'. > > ?? > >> >> Anyway, the primary differences are: >> 1) in already compiled code, changing to a property requires all >> dependent code to be recompiled. Field to property is a binary breaking >> change >> > > (more field-to-property points snipped). > > If I read the OP right, the issue was not starting with a public field and > changing it to a property later, but starting with an empty property and > adding the "get" and "set" parts later. > Reading the OP again, it turns out that I posted nonsense. Sorry for wasting the bandwidths.
I think it's an important distinction, becauseit allows the caller to know
whether code is run or not. [quoted text, click to view] "Daniel O'Connell [C# MVP]" wrote:
> > "Joachim Pense" <spam-collector@pense-online.de> wrote in message > news:cov5jq$2p7$05$2@news.t-online.com... > > Joachim Pense wrote: > > > >> Daniel O'Connell [C# MVP] wrote: > >> > >>> > >>> "vh" <veryhappyca@yahoo.ca> wrote in message > >>> news:e4cxBco2EHA.824@TK2MSFTNGP11.phx.gbl... > >>>> Hi, > >>>> I'm new to C#. Most examples about properties I found are sth like the > >>>> following: > >>>> class A{ > >>>> private int property; > >>>> public int Property { > >>>> get { return property; } > >>>> set { property = value; } > >>>> } > >>>> } > >>>> > >>>> My question is, Can I simply do the following: > >>>> class A { > >>>> public int Property; > >>>> } > >>>> > >>>> Then later, if it turns out that I need to do sth when the property is > >>>> set or get, I change it to > >>>> class A{ > >>>> public int Property { > >>>> get { <do sth>; return ... } > >>>> set { <do sth>; } > >>>> } > >>>> } > >>>> This way, the code that uses A should still compile. Am I right? This > >>>> way sounds much simpler to me, you don't have to write those repetitive > >>>> get&set > >>>> unless you later find out that you need. Is this the right way of using > >>>> properties? Am I missing sth here? > >>>> > >>> > >>> yes, an 'o', 'm', 'e','i','n', and a 'g'. > >> > >> ?? > >> > >>> > >>> Anyway, the primary differences are: > >>> 1) in already compiled code, changing to a property requires all > >>> dependent code to be recompiled. Field to property is a binary breaking > >>> change > >>> > >> > >> (more field-to-property points snipped). > >> > >> If I read the OP right, the issue was not starting with a public field > >> and > >> changing it to a property later, but starting with an empty property and > >> adding the "get" and "set" parts later. > >> > > > > Reading the OP again, it turns out that I posted nonsense. Sorry for > > wasting > > the bandwidths. > > np. > > I do find this to be one major missing feature in C#. IMHO they should have > added a property keyword and allowed simple > public property int Property; > > but...its not that way and probably never will be. > >
[quoted text, click to view] "Bonj" <Bonj@discussions.microsoft.com> wrote in message news:7876D1EB-5F21-48AD-B6B1-48A70DDE7A4B@microsoft.com... >I think it's an important distinction, becauseit allows the caller to know > whether code is run or not. Come again? Using a property still doesn't nessecerily look like a property, changing the language to support simple properties wouldn't help here, whatsoever.
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
| home · blog · groups | Questions? Comments? Contact the dn |