 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Tom de Neef
Guest
|
 Posted: Thu Jan 19, 2006 9:43 am Post subject: Deriving a class for a tree |
 |
|
I have a tree, with nodes as in
type
Tnode = class
generic variables
generic methods
father,mother : Tnode;
end;
In reality father and mother are in a list of Tnode's.
For specialized calculations I want to add variables to the nodes, so
ideally I would declare
type
TspecialNode = class(Tnode)
nr : integer; // specialized var
end;
But then of course, father and mother should also be descended to
TspecialNode types. For example, if you want to number nodes as powers of
two in the nr field
procedure number(nr : integer; node : TspecialNode);
begin
node.nr:=nr;
if father <> NIL then number(nr*2,node.father);
if mother <> NIL then number(nr*2+1,node.mother)
end;
This fails, because father and mother are not of type TspecialNode (and will
thus not have a field for nr).
In the past I have solved this by putting all special fields in the base
class, avoiding the need for a derived node class. But it is against my
sense of neatness since all vars for all the specialized calculations end up
in Tnode.
Have I missed something ?
Tom
|
|
| Back to top |
|
 |
alanglloyd@aol.com
Guest
|
| Posted: Thu Jan 19, 2006 10:35 am Post subject: Re: Deriving a class for a tree |
|
|
This is a copy of a note I got from somewhere on the net and put in my
"things which might be useful but not easy to find out" list. It could
be useful to you - I never had occasion to use it <g>.
Adding Extra Properties to TreeView Nodes
unit mytreeview;
interface
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms,
Dialogs,
ComCtrls, CommCtrl;
type
TMyTreeNode = class(TTreeNode)
private
fDataString: String; // the extra property
public
constructor Create(AOwner: TTreeNodes);
property DataString: string read fDataString write fDataString;
end;
TMyTreeview = class(TTreeView)
public
function CreateNode: TTreeNode; override;
end;
procedure Register;
implementation
function TMyTreeView.CreateNode: TTreeNode;
begin
Result := TMyTreeNode.Create(Items);
end;
constructor TMyTreeNode.Create(AOwner: TTreeNodes);
begin
inherited Create(AOwner);
fDataString := '';
end;
procedure Register;
{put this on the component palette}
begin
RegisterComponents('Samples', [TMyTreeView]);
end;
end.
Alan Lloyd.
|
|
| Back to top |
|
|
Maarten Wiltink
Guest
|
| Posted: Thu Jan 19, 2006 12:56 pm Post subject: Re: Deriving a class for a tree |
|
|
"Tom de Neef" <tdeneef (AT) qolor (DOT) nl> wrote
| Quote: | I have a tree, with nodes as in
type
Tnode = class
generic variables
generic methods
father,mother : Tnode;
|
???? This is a most unusual tree.
| Quote: | end;
In reality father and mother are in a list of Tnode's.
For specialized calculations I want to add variables to the nodes, so
ideally I would declare
type
TspecialNode = class(Tnode)
nr : integer; // specialized var
end;
But then of course, father and mother should also be descended to
TspecialNode types.
|
Make them properties, and you can just reintroduce the same property
with the new type.
[...]
| Quote: | Have I missed something ?
|
Yes. The switch to real OO. (-:
The classical ADT approach equates a tree with the root node and, by
implication, all its children. In an OO solution, the tree is an object
and its nodes are dependent objects - not necessarily hidden from view,
but that's possible, too. Then all access has to go through the tree
object, which is all very trim and proper.
And as Alan has pointed out, the tree can know what type of nodes it
expects. TCollection does this as well. Don't forget to make
TNode.Create virtual, or you can't write TTree.AddNode.
Groetjes,
Maarten Wiltink
|
|
| Back to top |
|
|
Tom de Neef
Guest
|
| Posted: Thu Jan 19, 2006 2:51 pm Post subject: Re: Deriving a class for a tree |
|
|
"Maarten Wiltink" <maarten (AT) kittensandcats (DOT) net> schreef in bericht
news:43cf8c8e$0$11068$e4fe514c (AT) news (DOT) xs4all.nl...
| Quote: | "Tom de Neef" <tdeneef (AT) qolor (DOT) nl> wrote in message
news:43cf5f60$0$11073$e4fe514c (AT) news (DOT) xs4all.nl...
I have a tree, with nodes as in
type
Tnode = class
generic variables
generic methods
father,mother : Tnode;
???? This is a most unusual tree.
|
It's called a pedigree or ancestor tree (in genealogical research). There
are also descendant trees. But they are more complex since you can have many
partners and many children.
| Quote: |
end;
In reality father and mother are in a list of Tnode's.
For specialized calculations I want to add variables to the nodes, so
ideally I would declare
type
TspecialNode = class(Tnode)
nr : integer; // specialized var
end;
But then of course, father and mother should also be descended to
TspecialNode types.
Make them properties, and you can just reintroduce the same property
with the new type.
[...]
Have I missed something ?
Yes. The switch to real OO. (-:
The classical ADT approach equates a tree with the root node and, by
implication, all its children. In an OO solution, the tree is an object
and its nodes are dependent objects - not necessarily hidden from view,
but that's possible, too. Then all access has to go through the tree
object, which is all very trim and proper.
And as Alan has pointed out, the tree can know what type of nodes it
expects. TCollection does this as well. Don't forget to make
TNode.Create virtual, or you can't write TTree.AddNode.
|
The properties trick does it. Thanks a lot.
The introduction of the tree as a container is nice but less essential. But
it simplifies destruction, so I'll buy that as well.
Tom
|
|
| Back to top |
|
|
Hans-Peter Diettrich
Guest
|
| Posted: Thu Jan 19, 2006 8:14 pm Post subject: Re: Deriving a class for a tree |
|
|
Maarten Wiltink schrieb:
| Quote: | I have a tree, with nodes as in
type
Tnode = class
generic variables
generic methods
father,mother : Tnode;
???? This is a most unusual tree.
|
Indeed, looks more like a graph?
| Quote: | Make them properties, and you can just reintroduce the same property
with the new type.
|
Properties per se are not virtual! Virtual properties require virtual
get/set methods in the base class, then derived classes can include
according fields and override the get/set methods accordingly.
DoDi
|
|
| Back to top |
|
|
Maarten Wiltink
Guest
|
| Posted: Fri Jan 20, 2006 9:25 am Post subject: Re: Deriving a class for a tree |
|
|
"Hans-Peter Diettrich" <DrDiettrich (AT) nowhere (DOT) nix> wrote
| Quote: | Maarten Wiltink schrieb:
[...]
Make them properties, and you can just reintroduce the same property
with the new type.
Properties per se are not virtual! Virtual properties require virtual
get/set methods in the base class, then derived classes can include
according fields and override the get/set methods accordingly.
|
In any case, you can't change the type of anything while overriding it.
New fields aren't necessary _here_. Assuming virtual accessors:
function TSpecialNode.GetFather: TSpecialNode;
begin
Result:=inherited GetFather as TSpecialNode;
end;
procedure TSpecialNode.SetFather(const Value: TSpecialNode);
begin
inherited SetFather(Value);
end;
In my code, property accessors are all static (so null objects return
a default value or lose the update, and don't crash) and delegate to a
virtual second-stage accessor, which changes the pattern correspondingly.
Groetjes,
Maarten Wiltink
|
|
| Back to top |
|
|
Hans-Peter Diettrich
Guest
|
| Posted: Fri Jan 20, 2006 8:24 pm Post subject: Re: Deriving a class for a tree |
|
|
Maarten Wiltink schrieb:
| Quote: | In my code, property accessors are all static (so null objects return
a default value or lose the update, and don't crash) and delegate to a
virtual second-stage accessor, which changes the pattern correspondingly.
|
Sorry, I don't understand that :-(
What are null objects (Nil?)?
Why a two-stage access, when a single virtual method would be sufficient?
DoDi
|
|
| Back to top |
|
|
Maarten Wiltink
Guest
|
| Posted: Mon Jan 23, 2006 12:29 pm Post subject: Re: Deriving a class for a tree |
|
|
"Hans-Peter Diettrich" <DrDiettrich (AT) nowhere (DOT) nix> wrote
| Quote: | Maarten Wiltink schrieb:
In my code, property accessors are all static (so null objects
return a default value or lose the update, and don't crash) and
delegate to a virtual second-stage accessor, which changes the
pattern correspondingly.
What are null objects (Nil?)?
|
Nil, yes. (Not _empty_, which may be different, but null. Not there.
No reference. Nobody home.)
| Quote: | Why a two-stage access, when a single virtual method would be
sufficient?
|
Because it isn't sufficient to me. If I declare a classtype variable,
I can evaluate a property on that variable and the compiler will
substitute a method call. I do not want that method to be virtual.
If Self equals nil, calling a virtual method will crash. Calling a
static method allows me to test Assigned(Self) first, and return a
default value instead of calling the virtual method. The virtual
method is always there, even if it just returns a field value.
It's how I use properties. There is an object with a Dirty flag. If
there is no object, it will report not being Dirty.
Groetjes,
Maarten Wiltink
|
|
| 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
