well, in read-only variables you don't need to specify the Set part at all... another thing I was about also was that specifying logic inside the property is not a really good practice (it is always better to create some private method and call it from inside, it saves time and it is better for reusability as well).
And the exact thing I wanted to hear was this: "In general, I find it good practice to use Get Properties (where they exist) as a default". Yes, you find it a good practice, but it is not general good practice, you should NOT say anyone that he SHOULD use it. It is also the reason why this thread started... Bunch of programmers who uses this practice told him that he SHOULD do it their way and he got confused... It is your good practice, it is not my good practice, but I am not going to force you to do it my way ;-) Sorry if I do look like being upset, the reason is that I am upset, I have to attend LiveMeeting which is 2 hours in length and sound doesn't work as it should... 2009/12/17 Jamie Fraser <[email protected]> > > > Yes, of course if property has some logic which checks the set value or >> count the get value from something then yes, you should use the property, >> but why to use it when it contains only eg get {return this.value} ? and one >> more thing about your message: >> > > In general, I find it good practice to use Get Properties (where they > exist) as a default. They might only say > > return _abc; > > but then they might say > > if(x || y) { _abc = _service.Refresh(); } else { _abc = service.Load(_id); > } > return _abc; > > And they also might *change* from example 1 to example 2. If you > consistently use the Get Property, if the logic changes, your code will > still work. Remember - another developer might change the logic contained in > the property but NOT check the the rest of the code for where it is used. > > So, elsewhere in the class, if you say > > int a = _abc; > > Then your code breaks. > > But if you say > > int a = PropertyABC; > > Then your code continues working. It is a safety net - win/win, if you > will. If the property only returns _abc, then the compiler will inline this > to int a = _abc anyway, so there is no performance hit. > > > >> -If the property is read-only, then there is a reason for this (i.e. logic >> already exists internally to set the value of the underlying field) >> and that logic is? Sorry, but I don't quite understand that, coding >> classes always means to create some its own logic and how does look a logic >> to set the variable? Maybe this.variable = value? Oh no, sry, you can't, you >> must use property for this... but property is read-only? Damn, so there >> already MUST be some logic that sets it... >> --that was test of some irony, don't get it personally ;-) >> >> > I don't really get what you mean here. > > In the case of a read-only variable, you want to prevent *external* classes > from changing the value of the field. Therefore, you do something like > > public string Name > { > get > { > return _name; > } > private set > { > _name = value; > } > } > > And you use the property as normal. >
