Comments on: Fields and virtual members

By: Dan Puzey

Dan Puzey — Mon, 16 Nov 2009 19:15:54 +0000

While I agree that you shouldn’t have “behaviour” in a property, it’s not difficult to think of cases where you need logic in a property: I’d expect most setters to have some basic validation in them – checking for null, or negative numbers or whatever. That typically requires a backing field, unless there’s some syntax I haven’t learnt yet (which is entirely possible )

By: Mahesh

Mahesh — Fri, 13 Nov 2009 14:50:13 +0000

Since property is converted into method in IL, there could be slight performance hit as it is method call.

By: bogardj

bogardj — Wed, 11 Nov 2009 13:10:35 +0000

@Ryan

Do you mean manual lazy loading? I haven’t done that kind of code in a long, long time.

By: Ryan R

Ryan R — Tue, 10 Nov 2009 20:55:37 +0000

How about lazy loading? I have yet to see a good way (no reflection) of lazy loading an automatic property.

By: Fizz

Fizz — Tue, 10 Nov 2009 09:38:53 +0000

I want Property scoped values, solves all of these problems

public int MyProperty
{
int myField;
get { return myField; }
set
{
if (!MyFieldValid(value) throw new Exception(“”);
myField = value;
NotifyPropertyChanged(“MyProperty”);
}
}

MS does not think this is usefull

By: Artem Govorov

Artem Govorov — Tue, 10 Nov 2009 05:24:54 +0000

Presentation frameworks (WinForms, WPF) UI elements 2-way data binding heavily depends on read/write properties and INotifyPropertyChanged interface implementation, so property setter is an obvious place to put code raising property changed event. I’m not saying that this is good or bad – it just the way it is and this makes it impossible to use auto properties in these cases.

By: AlexEzh

AlexEzh — Mon, 09 Nov 2009 22:29:23 +0000

I would say differently. It is fine to use fields in the class implementation and expose property accessors as long as accessors are not virtual. If virtual accessor is required, than ideally it should be abstract to avoid unnecessary fields in the class implementation.

By: bogardj

bogardj — Mon, 09 Nov 2009 20:57:39 +0000

@Paco et al

LSP isn’t violated here. Fields are an implementation detail and should never be exposed outside of that class (i.e., instance fields should always be private).

It’s just one of those cases where if a class exposes state, it should be self-consistent and use the property accessors.

By: Christopher Harris

Christopher Harris — Mon, 09 Nov 2009 20:48:30 +0000

@Paco: I have to admit you make a very interesting observation on breaking the LSP. It makes me wonder if this is one of those cases where a new trivial unit test would have been more appropriate to catch the CompareTo bug. (Clean Code: Smell T3: Don’t Skip Trivial Tests)

By: AlexEzh

AlexEzh — Mon, 09 Nov 2009 20:38:34 +0000

Why not set _value to 5 which would keep the existing class logic? I understand that the class is an example, but you are trying to hide the behavior of the base class which is a violation of Liskov substitution principle. Article on Wikipedia has a good example.