using ancestor properties with inherited keyword instead of get and set. Advisable?
Greg Lorriman
using ancestor properties with inherited keyword instead of overriding get and set. Is this a good idea?
Are there pitfalls? Am I storing up derivation problems and side effects?
I've discovered, though the manuals don't document this clearly, that you can read and write to
ancestor properties, thereby indirectly accessing private fields while being able to change the specifiers
of the new class in order to intercept use of the properties for ones own purposes. See example below.
I need to do this in order to derive a class from TstringList in which a user change to the duplicates
property is significant and needs immediate attention. The origional is implemented as direct read and
write specifiers to a private field. Which isn't much good if my class needs immediate notification of a
change. But the manuals seem to have nothing to say on this point with, of course, no guidance for
newbies like me.
Is this a straightforward feature and an accepted method of doing things?
thanks guys.
type Tclass1 = class
public
fcount : integer;
property value : integer read Fcount write Fcount;
end;
type Tclass2 = class(Tclass1)
public
function getFcount:integer;
procedure setFcount(i : integer);
property value : integer read Fcount write SetFcount;
end;
implementation
tclass2.setFcount(i : integer);
begin
inherited value:=i;
end;
function Tclass2.getFcount : integer;
begin
result:=inherited value;
end;
--
Greg Lorriman co. inc. & sons Ltd
Robert Lee
Greg Lorriman wrote:
> using ancestor properties with inherited keyword instead of overriding get and set. Is this a good idea?
> Are there pitfalls? Am I storing up derivation problems and side effects?
>
> I've discovered, though the manuals don't document this clearly, that you can read and write to
> ancestor properties, thereby indirectly accessing private fields while being able to change the specifiers
> of the new class in order to intercept use of the properties for ones own purposes. See example below.
>
> Is this a straightforward feature and an accepted method of doing things?
>
What you've done is acceptable and is the only course of action if the property doesn't have virtual accessor
methods that you can override. However, properties are NOT virtual. That is, if your derived class is
typecast to its ancestor and value is accessed it will use the ancestor's value property and not the derived
one. If you want true polymorphic behavior you have to use virtual accessor methods which can be overridden.
Bob Lee
Greg Lorriman
In article: <34A696A0...@nwu.edu> Robert Lee <rh...@nwu.edu> writes:
>
> Greg Lorriman wrote:
>
> > using ancestor properties with inherited keyword instead of overriding get and set. Is this a good
idea?
> > Are there pitfalls? Am I storing up derivation problems and side effects?
>
> What you've done is acceptable and is the only course of action if the property doesn't have virtual
accessor
> methods that you can override. However, properties are NOT virtual. That is, if your derived class is
> typecast to its ancestor and value is accessed it will use the ancestor's value property and not the
derived
> one. If you want true polymorphic behavior you have to use virtual accessor methods which can be
overridden.
>
and thereby we can conclude that borland have not designed TstringList with inheritence in mind.
Hi Bob,
Thanks for the answer. Just what I was looking for.
I hadn't considered the possibility that properties might be non-virtual and that certainly complicates
matters. It seems to me, due to the above, that all write specifiers should be virtual procedures and that
making them direct is very bad manners. Even read specifiers..... And having no support for virtual
properties seems to be anti-OOP.
Do you know of any good material that discuss's these issues and related OOP issues? I don't know
where to look, and the books I've purchased in the past have, invariably, been crud.
Having taken a good look at the Tstringlist source code it seems, for various reasons, that borland
were a bit sloppy about it's structure in respect of using it as a base class. The problems invlolved in
inheriting form Tstringlist has certainly taught me a great deal about how to put together an OOP object
properly. For example WHY couldn't they have had two, or perhaps 4, protected virtual functions
through which all other routines did their work. Instead of having to overrride every single public and
protected function (or procedure) I could have done it through these two alone. What a bore.
Or at least they could have had the public functions only referring to protected fucntions. Instead the
public functions frequently refer to private functions and fields forcing yours truly to override the
misbehaving function.
The irony is that if only I could override a couple of the private functions, I would have my soloution to
avoiding overriding everything else. This seems very anti-inheritance.
Having said that, having the source code of your ancestor classes was never assumed to be part of
OO programming.
And having said all that, I haven't found any decent material on the practicalities of OOP and sorting all
this out is, to some extent, doing the job.
One can conclude that routing as many public and protected functions through a few general purpose
protected virtual functions aids considerably in the cause of inheritence and that if the language
supports properties then they should use virtual read and write specifier functions/procedures and
never do anything directly as it defeats the point behind inheritenance and poly-morphism.
Do you have any other tips to class construction? What policys and guidlines do you use when putting
together classes?
And finally, am I right in thinking that this is not documented, except by implication? It seems an outrage
to me.
And thanks for the reply, most appreciated.
Yours
Greg
Robert Lee
Greg Lorriman wrote:
While using virtual accessor methods is generally a good idea, there is one reason not to use them.
Performance. This is rarely a concern in your average program, but locking out the possibility of direct
access is needlessly limiting. However, I agree that there are several places in the VCL that I've wished I
could override a function but couldn't because it wasn't virtual. Borland seems to have focused Delphi
primarily towards what might be described as "users" (developers who are content to use the supplied components
as is), instead of "programmers" (developers who wish the extend them).
In their defense, as you may well discover, creating a get/set routine for every stinking little parameter gets
to be irritating. Programmer irritation isn't supposed determine system requirements, but it does.
As for virtual properties... Well the problem is that properties aren't exactly "real." A property acts, more
or less, like a macro (or inline function) evaluated at compile time. Functionally implementing a virtual
property would require that the read and write clauses be turned into virtual functions containing nothing more
than the call to the variable or accessor method by the compiler. This is exactly the same effect as making
the accessor methods virtual in the first place, except that an extra function call would have been added.
I don't know whether it's documented or not. It's not documented in an obvious way. Again Borland has focused
the Help docs towards "users" not programmers, and virtual anything just makes their brains hurt.
I've used very few outside books on programming/OOP/Delphi. Most of the platform specific ones are 95%
re-iteration of what comes with the platform in the first place, and my programming/OOP knowledge is largely
home grown. There is one book that I do highly recommend. It's called "Code Complete" by Steve McConnell (I
think; the books at home at the moment), Microsoft Press, and is as much about programming philosophy as it is
about coding.
Finally, object oriented programming is, first and foremost, a way of thinking about a computing problem. The
OOP features of a language are just fluff to make it easier to implement. In my opinion, the key to grasping
the thought process is to anthropormorphize your data. Each data structure is a little creature, each data
structure type is a species. Properties are the characteristics the creatures, methods are your means giving
them commands, and events are a way in which they can talk back to you or other creatures. It sounds silly,
but it's the strongest metaphor I know for OOP.
Bob Lee
Rick Peterson
The best book that I have found on this subject is by Danny Thorpe:
Developing Delphi Components...remember if you make a method virtual...it is
now forever linked into your code whenever someone touches your object...You
are bypassing the smart linker...
You must really decide whether to make them virtual or not...does it really
add functionality to your object or are you just acting like a pack
rat...and thinking...hmmm somewhere down the line I might need to override
this property, probably not...but maybe...
Rick Peterson
Greg Lorriman wrote in message <254192...@lorriman.demon.co.uk>...