 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Warren Sirota
Guest
|
 Posted: Thu Sep 01, 2005 5:53 pm Post subject: referring to fields vs. properties |
 |
|
I guess this is a pretty naive (and not terribly important) question,
but it comes up again and again for me, so I thought I'd ask for feedback:
When you have a property that just consists of a getter and setter for a
private field, how do you refer to the property *within* the class? Say
the property is called Goo, with field FGoo. Within the class, would you
(a) *never* user FGoo except in the getter/setter (unless there was a
logical reason that you had to bypass these, which there sometimes might
be), (b) *always* use FGoo (except where you wanted to take advantage of
logic - e.g., side effects - in the setter) and leave the public
property name to the class' clients, or (c) mix the two in some way.
Is there a systematic way that y'all handle this? thanks.
Warren Sirota
|
|
| Back to top |
|
 |
Iman L Crawford
Guest
|
| Posted: Thu Sep 01, 2005 6:07 pm Post subject: Re: referring to fields vs. properties |
|
|
Warren Sirota <wsirota (AT) wsdesigns (DOT) com> wrote in news:43173fbf$1
@newsgroups.borland.com:
| Quote: | (c) mix the two in some way.
|
I've tried both a and b, but always end up doing c.
--
Iman
|
|
| Back to top |
|
|
Joanna Carter (TeamB)
Guest
|
| Posted: Thu Sep 01, 2005 6:14 pm Post subject: Re: referring to fields vs. properties |
|
|
"Iman L Crawford" <ilcrawford.at.hotmail.dot.com> a écrit dans le message de
news: Xns96C4857DE4116ilcrwfrd (AT) 207 (DOT) 105.83.66...
| Quote: | (c) mix the two in some way.
I've tried both a and b, but always end up doing c.
|
Ditto here :-)
Joanna
--
Joanna Carter (TeamB)
Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
|
|
| Back to top |
|
|
Carl Caulkett
Guest
|
| Posted: Thu Sep 01, 2005 7:07 pm Post subject: Re: referring to fields vs. properties |
|
|
Warren Sirota wrote:
| Quote: | I guess this is a pretty naive (and not terribly important) question,
but it comes up again and again for me, so I thought I'd ask for
feedback:
When you have a property that just consists of a getter and setter
for a private field, how do you refer to the property within the
class? Say the property is called Goo, with field FGoo. Within the
class, would you (a) never user FGoo except in the getter/setter
(unless there was a logical reason that you had to bypass these,
which there sometimes might be), (b) always use FGoo (except where
you wanted to take advantage of logic - e.g., side effects - in the
setter) and leave the public property name to the class' clients, or
(c) mix the two in some way.
Is there a systematic way that y'all handle this? thanks.
Warren Sirota
|
In Delphi, my approach is that public properties are exclusively for
the
use of the class' clients, so I generally use a mixture of manipulating
FGoo directly, or calling the Get or Set method.
In past threads on this subject, others have disgreed with this
approach very vehemently <g>
--
Carl
|
|
| Back to top |
|
|
Charles McAllister
Guest
|
| Posted: Thu Sep 01, 2005 7:21 pm Post subject: Re: referring to fields vs. properties |
|
|
Warren Sirota wrote:
| Quote: | I guess this is a pretty naive (and not terribly important) question,
but it comes up again and again for me, so I thought I'd ask for feedback:
When you have a property that just consists of a getter and setter for a
private field, how do you refer to the property *within* the class? Say
the property is called Goo, with field FGoo. Within the class, would you
(a) *never* user FGoo except in the getter/setter (unless there was a
logical reason that you had to bypass these, which there sometimes might
be), (b) *always* use FGoo (except where you wanted to take advantage of
logic - e.g., side effects - in the setter) and leave the public
property name to the class' clients, or (c) mix the two in some way.
Is there a systematic way that y'all handle this? thanks.
Warren Sirota
|
I use (b) -- if I can remember to do it.
Here are two reasons:
1. Someone reading your code will have a better chance of understanding exactly how it works.
2. If you go back to read some old code, and you see a place where a property is being used, it
becomes much clearer that a side effect is intended.
|
|
| Back to top |
|
|
Lee_Nover
Guest
|
| Posted: Thu Sep 01, 2005 7:42 pm Post subject: Re: referring to fields vs. properties |
|
|
b) for plain properties
a) for list properties (GetItem(Index) instead of FItems[Index]) and fordelegated props like Count where GetCount is FItems.Count
|
|
| Back to top |
|
|
Bob Dawson
Guest
|
| Posted: Thu Sep 01, 2005 7:43 pm Post subject: Re: referring to fields vs. properties |
|
|
"Warren Sirota" wrote
| Quote: | called Goo, with field FGoo. Within the class, would you
(b) *always* use FGoo (except where you wanted to take
advantage of logic - e.g., side effects - in the setter)
|
Inside an object is not the place to practice information hiding.
bobD
|
|
| Back to top |
|
|
Jim Cooper
Guest
|
| Posted: Thu Sep 01, 2005 10:42 pm Post subject: Re: referring to fields vs. properties |
|
|
Generally speaking I only ever use FGoo in places where there is a
reason not to use Goo. Obviously this includes the getter and setter
methods, and frequently the constructor if default values are being set,
and possibly the destructor if action is required there.
Otherwise I believe you should always use the property as a first
choice. The advantages of using a property as opposed to a field apply
just as well within a class as from outside it. I also use protected
properties for that reason (and once or twice even private properties,
when I've needed sone sort of extra logic).
I disagree with Bob when he says information hiding has no place within
a class. It most certainly does (I bet he calls methods internal to the
class <g>). A simple example is restricting the range of values a
property may have. You almost certainly want that validation done
whenever the property is set, no matter where that might be.
Cheers,
Jim Cooper
__________________________________________
Jim Cooper [email]jcooper (AT) tabdee (DOT) ltd.uk[/email]
Tabdee Ltd http://www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
__________________________________________
|
|
| Back to top |
|
|
Jan Nordén [Borland]
Guest
|
| Posted: Fri Sep 02, 2005 8:14 am Post subject: Re: referring to fields vs. properties |
|
|
Warren Sirota wrote:
| Quote: | I guess this is a pretty naive (and not terribly important) question,
but it comes up again and again for me, so I thought I'd ask for
feedback:
When you have a property that just consists of a getter and setter
for a private field, how do you refer to the property within the
class? Say the property is called Goo, with field FGoo. Within the
class, would you (a) never user FGoo except in the getter/setter
(unless there was a logical reason that you had to bypass these,
which there sometimes might be), (b) always use FGoo (except where
you wanted to take advantage of logic - e.g., side effects - in the
setter) and leave the public property name to the class' clients, or
(c) mix the two in some way.
Is there a systematic way that y'all handle this? thanks.
Warren Sirota
|
I always assume that the property is the abstract state, and FXX
(potentially part of) the concrete state.
I.e. that both the setter and the getter can have side effects, and
that other methods may do other things to it, as long as the abstract
state is not changed.
Thus, I use the property when I want the abstraction represented by it,
and Fxx only when I really must get involved with internal aspects of
how it is represented.
In most cases, that means only touching Fxx in getter, setter,
constructor, destructor. However if it is a lazy-create you will fairly
often have code like:
if Assigned(Fxx) then
DoSomethinig(xx);
--
Jan Nordén
Senior Software Architect
MDA products group
|
|
| Back to top |
|
|
Peter Morris [Droopy eyes
Guest
|
|
| Back to top |
|
|
Bob Dawson
Guest
|
| Posted: Fri Sep 02, 2005 1:44 pm Post subject: Re: referring to fields vs. properties |
|
|
"Jim Cooper" wrote
| Quote: |
I disagree with Bob when he says information hiding has no
place within a class. It most certainly does (I bet he calls
methods internal to the class <g>).
|
Certainly--those methods are not hidden within the class <g>. But more to
your point: I call the method as a deliberate choice--not by convention if
simply citing the field would do.
Let's get more specific about the whys.
Given:
private
FFoo : integer;
FBar : integer;
...
protected
procedure CaseInPoint;
public
property Foo read FFoo write FFoo;
property Bar read GetBar write SetBar;
end;
procedure TThoughtExperiment.CaseInPoint;
begin
if FFoo > 5 then
TakeSomeParameterizedAction(Bar);
end;
Now under my conventions (default call is to Field) we know that
touching FFoo is a simple act that absolutely will not change object
state. It need not be further examined.
touching Bar is problematic--it may have a side effect; it may not
actually return FBar directly; it may even change our object state--but
whatever it does, that additional logic has been invoked _purposely_ by this
procedure. Anyone looking at revising the procedure can see at a glance
exactly what's simple, and exactly what requires additional investigation to
make sure we understand what we have. Best not be changing anything until we
know what GetBar does.
Under your conventions
touching FFoo is ill-formed and should be changed to Foo. Now we have
if Foo > 5 then
TakeSomeParameterizedAction(Bar);
Now we have two touches that look exactly alike, but one has additional
logic and the other doesn't; it's no longer possible to tell--just by
looking at the code--whether there's anything additional going on or not,
and we have to do a lot of checking and wondering, if Foo translates to read
FFoo, why the original programmer didn't just say that to start with. He was
following an 'obscurity by convention' process.
Notice nowhere above have I said that I always use fields directly when
getters/setters have been defined. If we have a private property like
function TThoughtExperiment.GetFoo : integer;
begin
if (FFoo = 0) then
InitializeFoo(FFoo);
Result := FFoo;
end;
then _most_ internal requirements for FFoo may end up being satisfied by
accessing the property rather than the field. Whole classes of internal
state aspects--lazy-load items, internal classes, initialized variables,
etc., are often going to be supported by internal properties that never get
bypassed.
But the point is that such cases are deliberate choices--I'm not going to
trigger a complex initialization process just by rote if the fact that FFoo
isn't initialized can tell me everything I need to know. I'm not going to
force a later programmer to go off examining the GetBar procedure if it
really doesn't make any difference. And I'm not going to leave any doubt in
the code as to whether the logic of getters/setters was invoked
intentionally. If it's called, there was a reason, not a convention.
bobD
|
|
| Back to top |
|
|
Warren Sirota
Guest
|
| Posted: Fri Sep 02, 2005 2:38 pm Post subject: Re: referring to fields vs. properties |
|
|
It's interesting to see how many points of view there are on this. My
practice (which is naive, since I'm a traditional programmer gradually
being "refactored" into an OO one, rather than someone who has had
systematic training of any kind) has been most like Bob's - when I look
back two months later and see a reference to FGoo, I know nothing else
is going on. So that usage communicates something to me. But, the
pitfall is that I sometimes (not frequently) miss invoking a side-effect
that I needed.
I'm becoming more convinced that the most consistent and safe approach
would be more like (a) - to only reference the fields directly in
getters (with lazy initialization, if appropriate, in the getter),
setters, constructors and destructor, unless a specific bypassing of the
side effects is intended.
Of course, then there's a fair amount of code that I already have that
doesn't follow that convention, but c'est la vie, I guess.
Warren
|
|
| Back to top |
|
|
Bob Dawson
Guest
|
| Posted: Fri Sep 02, 2005 2:56 pm Post subject: Re: referring to fields vs. properties |
|
|
"Warren Sirota" wrote
| Quote: | pitfall is that I sometimes (not frequently) miss invoking a
side-effect that I needed.
|
Unfortunately, I know of no conventions that prevent error.
| Quote: | would be more like (a) - to only reference the fields directly
in getters (with lazy initialization, if appropriate, in the getter),
|
In my thinking it comes down to this:
If there is a getter/setter and it does something, then you either want that
to happen or not. That being the case, your convention is never going to
matter--you do what you need to do for that specific case to work.
The only time a convention comes into play is where it doesn't otherwise
matter: those cases like
property Foo read FFoo write FFoo;
in which there either is no getter/setter at all, or else the activity of
those methods is inconsequential with respect to internal use.
That is to say: the convention governs how we should read/write FFoo when
the calls "FFoo" and "Foo" are functionally identical.
My spidey sense says to use the field as a matter of clarity and simplicity.
bobD
|
|
| Back to top |
|
|
Heiko Behrens
Guest
|
| Posted: Fri Sep 02, 2005 3:01 pm Post subject: Re: referring to fields vs. properties |
|
|
Warren Sirota wrote:
| Quote: | I'm becoming more convinced that the most consistent and safe approach
would be more like (a) - to only reference the fields directly in
getters (with lazy initialization, if appropriate, in the getter),
setters, constructors and destructor, unless a specific bypassing of the
side effects is intended.
|
I agree to a certain degree *g* or want to provide a common example of a
'specific bypass'. Per convention an object's state is in a consistent
state before (precondition) and after (postcondition) every operation
applied on it (invariant). Whenever a client uses an object it can be
sure to look at an object with a valid state. Naively implemented
methods would also rely on that precondition.
Since getters/setters are plain methods the usage of properties can be
reduced to methods calls in the end. Therefore, whenever you call a
property from inside a method you call a method. Since object's state
doesn't need to be valid inside a method and the usage of properties
from inside a method might invoke other methods with certain assumptions
about object's state your overall implementation could end up in a
scenario where logic is developed against false assumptions.
I am aware of the fact that this is not limited to properties but is a
general problem when using (public) operations while executing/being
inside a method. It should give you a hint that one cannot use
properties without any knowledge of their precondition and
postcondition. You simply *have to know* what happens inside this
operation or at least, what the effects are. Information hiding can only
be used in a limited way.
In general, I prefer constructs that find a happy medium between their
granularity and its flexibility. Doing so leads you to classes where you
can instantly get an overview of the class you are working on and
understand its restrictions. Whenever you allow /abstract properties/
(or template methods) be sure to document their restrictions and reduce
their side effects.
Regards,
Heiko Behrens
|
|
| Back to top |
|
|
krisztian pinter
Guest
|
| Posted: Fri Sep 02, 2005 3:18 pm Post subject: Re: referring to fields vs. properties |
|
|
On Thu, 1 Sep 2005 14:43:29 -0500, Bob Dawson <bdawson (AT) idtdna (DOT) com> wrote:
| Quote: | Inside an object is not the place to practice information hiding.
|
surely not. although it is a place to practice another principle:
centralized decisions. for example, it you decide to change your
implementation of your storage to an array from a TList, all
direct accesses should be rewritten from FThing.Count to
Length(FThing). so the change will effect many methods of the
class. if you use the properties, you can change the underlying
implementation at the declaration, and the getter/setter methods.
you gain much advance in maintenability.
of course i didn't say you must use the properties. i just wanted
to add another point, that should be taken into consideration.
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
