| View previous topic :: View next topic |
| Author |
Message |
Rick
Guest
|
 Posted: Mon Oct 06, 2003 3:01 am Post subject: property names and their corresponding private variables |
 |
|
I am conflicted on which variable name I should use in a class that has
properties.
Assume I hava a class with the following:
private
FBankBalance: currency;
public
property BankBalance: currency read FBankBalance;
Within my class methods should I refer to the class member using its
property name (BankBalance) or use its private name (FBankBalance). I know
that both will give me what I want but will using one over the other offfer
more advantages (such as future code maintenance)?
Any thoughts?
Rick
|
|
| Back to top |
|
 |
Jim Cooper
Guest
|
| Posted: Mon Oct 06, 2003 7:39 am Post subject: Re: property names and their corresponding private variables |
|
|
| Quote: | Within my class methods should I refer to the class member using its
property name (BankBalance) or use its private name (FBankBalance).
|
Use the property name. If you ever do change the implementation, you
will normally want the geter/setter methods to be called. Obviously from
within the getter/setter methods you use the private name <vbg> and if
you initialise property values in constructors you often use private
names there too (ditto for destructors).
Cheers,
Jim Cooper
____________________________________________
Jim Cooper [email]jcooper (AT) tabdee (DOT) ltd.uk[/email]
Tabdee Ltd http://www.tabdee.ltd.uk
TurboSync - Connecting Delphi with your Palm
____________________________________________
|
|
| Back to top |
|
|
Franz-Leo Chomse
Guest
|
| Posted: Mon Oct 06, 2003 9:47 am Post subject: Re: property names and their corresponding private variables |
|
|
| Quote: | Within my class methods should I refer to the class member using its
property name (BankBalance) or use its private name (FBankBalance). I know
that both will give me what I want but will using one over the other offfer
more advantages (such as future code maintenance)?
|
It depends whether you want to access the raw data or the logical
version. One of the major tasks of access methods is to map between
these two representations. If there is any chance that dependent data
exists (which is normally updated by the setter methods) use the
property name.
Thus the general rule is. As long as you don't trigger an endless loop
use the property.
Regards from Germany
Franz-Leo
|
|
| Back to top |
|
|
Wayne Niddery [TeamB]
Guest
|
| Posted: Mon Oct 06, 2003 8:45 pm Post subject: Re: property names and their corresponding private variables |
|
|
Rick wrote:
| Quote: | I am conflicted on which variable name I should use in a class that
has properties.
Within my class methods should I refer to the class member using its
property name (BankBalance) or use its private name (FBankBalance).
I know that both will give me what I want but will using one over
the other offfer more advantages (such as future code maintenance)?
|
Neither is always right or wrong, it depends on various possible things. It
can be argued that properties are primarily for the *consumers* of a class,
not the class itself - i.e. properties represent the class' public
interface.
For example it's common to have read-only properties, but the class itself
certainly needs to be able to set the value for that property, so in that
case there's no choice but to access the internal field. Initialization in a
constructor will generally use the internal fields as well.
In the case of code that executes in response to external code accessing
methods or properties, often you will want to use your own properties
instead of the internal fields in order to ensure that any deliberate
side-effects execute properly.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: http://www.logicfundamentals.com/RADBooks.html
"It is error alone which needs the support of government. Truth can
stand by itself." - Thomas Jefferson
|
|
| Back to top |
|
|
John Elrick
Guest
|
| Posted: Tue Oct 07, 2003 2:33 pm Post subject: Re: property names and their corresponding private variables |
|
|
"Rick" <rick (AT) starvio (DOT) com> wrote
| Quote: | I am conflicted on which variable name I should use in a class that has
properties.
Assume I hava a class with the following:
private
FBankBalance: currency;
public
property BankBalance: currency read FBankBalance;
Within my class methods should I refer to the class member using its
property name (BankBalance) or use its private name (FBankBalance). I
know
that both will give me what I want but will using one over the other
offfer
more advantages (such as future code maintenance)?
|
Tough call...probably the property. Although there doesn't appear to be any
downside to using the variable. Fowler would probably say "use the field
until you need to use the property and then refactor."
John
|
|
| Back to top |
|
|
Bob Dawson
Guest
|
| Posted: Tue Oct 07, 2003 4:01 pm Post subject: Re: property names and their corresponding private variables |
|
|
"Rick" wrote
YAPOV-- internally, cite the field or the Get/Set routine directly, as
required--never cite the property. Clarity is the criterion.
| Quote: | private
FBankBalance: currency;
public
property BankBalance: currency read FBankBalance;
|
In this case I'd use the variable, because
if FBankBalance > 0
is explicit that no access code is being run, whereas
if BankBalance > 0
leaves you guessing--is there a getter?
Similarly for properties with get/set methods, it seems less ambiguous to me
to call the get/set methods directly rather than the property alias:
if GetCount > MaxCount
if FCount > MaxCount
are both obvious about what's happening, whereas
if Count > MaxCount
requires me to investigate further whether I have access code running or
not.
Within an object I want the code to be as clear as possible about what's
happening.
bobD
|
|
| Back to top |
|
|
John Elrick
Guest
|
| Posted: Tue Oct 07, 2003 5:23 pm Post subject: Re: property names and their corresponding private variables |
|
|
"Bob Dawson" <bdawson (AT) idtdna (DOT) com> wrote
| Quote: | "Rick" wrote
YAPOV-- internally, cite the field or the Get/Set routine directly, as
required--never cite the property. Clarity is the criterion.
|
A Google on YAPOV turned up "Do you mean Yakov" and nothing dealing with
programming.
| Quote: |
private
FBankBalance: currency;
public
property BankBalance: currency read FBankBalance;
In this case I'd use the variable, because
if FBankBalance > 0
is explicit that no access code is being run, whereas
if BankBalance > 0
leaves you guessing--is there a getter?
Similarly for properties with get/set methods, it seems less ambiguous to
me
to call the get/set methods directly rather than the property alias:
if GetCount > MaxCount
if FCount > MaxCount
are both obvious about what's happening, whereas
if Count > MaxCount
requires me to investigate further whether I have access code running or
not.
Within an object I want the code to be as clear as possible about what's
happening.
|
Logical argument.
John
|
|
| Back to top |
|
|
Bob Dawson
Guest
|
| Posted: Tue Oct 07, 2003 6:19 pm Post subject: Re: property names and their corresponding private variables |
|
|
"John Elrick" <jelrick (AT) adelphia (DOT) net> wrote
| Quote: |
A Google on YAPOV turned up "Do you mean Yakov" and nothing dealing with
|
Sorry. Yet Another Point Of View (by analogy to YACC and other YA's). I just
noticed that the forum regulars seemed to be splitting on this issue; Jim,
Franz-Leo and you leaning toward using the property to varying degrees,
while I tend to agree with Wayne's hypothetical "It can be argued that
properties are primarily for the *consumers* of a class"
In addition to readability, I'd argue that coding to the field/getter makes
updating easier as well. If I start with
property MyProp read FProp;
and need to change to
property MyProp read GetProp;
then a simple search for FProp will bring me to each reference, and I can
decide explicitly whether to substitute GetProp. But if I had cited MyProp
to start with, then all using routines will change behaviour without my
attention, and without version control diffs being stored. That's
polymorphism gone wrong.
bobD
|
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
