On Thu, Dec 17, 2009 at 11:38 AM, Processor Devil <[email protected] > wrote:
> 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). > How do you set the property then? By accessing the field directly? I don't like that. If you get using a property, you should set using a property. And there is NOTHING wrong with having some logic within the property - take a look through the source code of any major Open Source project and see how they do it. > 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. >> > >
