Discussion :

[eponette]

J'ai lu l'article de Neil. Mais il ne répond pas à mes questions.

Je vais essayer d'être clair 8)

J'ai une classe immeuble et une classe appartement. Un immeuble peut contenir 0..* appartements.

Il y a plusieurs méthodes possibles:
- Je mets un TobjectList dans ma classe immeuble qui contient les appartements.
- Je crée une classe AppartList qui contient un TobjectList.
- Je hérite ma classe Appartment de TOBjectList.

Peut-être encore d'autres

Que feriez-vous? Quels sont les avantages et inconvénient de chaque?

Merci D'avance

[Pero]

Perso, je n'utilise aucune de ces solutions

Voici la mienne, qui dans ton cas serait :

1. créer ta classe TAppartement ... normale
2. créer une classe TImmeuble qui hérite de TObjectList comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
  TImmeuble = class(TObjectList)
  private
    function GetItem(Index: Integer): TAppartement;
  public
    function Add(Appartement: TAppartement): Integer;
    property Items[Index: Integer]: TAppartement read GetItem;
  end;
 
implementation
 
function TImmeuble.Add(Appartement: TAppartement): Integer;
begin
  Result := inherited Add(Appartement);
end;
 
function TImmeuble.GetItem(Index: Integer): TAppartement;
begin
  Result := TAppartement(inherited Items[Index]);
end;

De cette façon, les seuls objets que tu puisses ajouter dans ton immeuble sont des appartements.

... et si tu crées une instance de TImmeuble avec le paramètre à True, c'est l'objectlist qui va gérer la mémoire.

... et tu bénéficies évidemment des méthodes de l'objectlist comme clear, sort (que tu dois réimplémenter toi-même), ...

Et voilà.

[e-ric]

Salut

Le problème avec l'héritage est que tu vas récupérer tous les attributs et méthodes de TObjectList. Ce n'est pas forcément souhaitable.

La composition permet de limiter l'interface de ta classe aux attributs et méthodes utiles dans le cadre de ta classe, il faut bien sûr coder les dites méthodes même si elles ne font que couvrir les méthodes de TObjecList.

Ne pas oublier si tu réalises une composition que la destruction d'un appartement entraîne la mise à jour de la liste des appartements de l'immeuble (surcharger la méthode Destroy des Appartements et conserver dans l'Appartement la référence au propriétaire c'est à dire l'immeuble qui le contient).

C'est clair ?

Cdlt

e-ric

[Pero]

Le problème avec l'héritage est que tu vas récupérer tous les attributs et méthodes de TObjectList. Ce n'est pas forcément souhaitable.

La composition permet de limiter l'interface de ta classe aux attributs et méthodes utiles dans le cadre de ta classe, il faut bien sûr coder les dites méthodes même si elles ne font que couvrir les méthodes de TObjecList.

J'imagine que tu parles du principe d'encapsulation. Je ne suis pas sûr qu'encapsuler à outrance soit une bonne solution également. Si la classe t'es destinée, je ne vois pas en quoi cela gêne. Tu l'as faite, donc tu sais comment elle marche (et tu ne perds pas de temps). Si par contre elle est detinée à l'extérieur, alors d'accord avec toi, on ne laisse paraitre que ce qui est nécessaire.

Ne pas oublier si tu réalises une composition que la destruction d'un appartement entraîne la mise à jour de la liste des appartements de l'immeuble (surcharger la méthode Destroy des Appartements et conserver dans l'Appartement la référence au propriétaire c'est à dire l'immeuble qui le contient).

L'ObjectList gère cela tout seul. Il n'est qu'un conteneur à pointeurs, c'est tout. Je ne vois pas pourquoi il faut surcharger le Destroy de l'Appartement. Si tu supprimes un appartement, il est d'office retiré de la liste et sa référence est effacée. Que veut le peuple ?

[DMO]

L'immeuble a ses propriétés propres, et parmis celles-ci peut se trouver une liste d'appartements, qui caractérise au même titre que les autres l'immeuble.

La propriété "ListeAppartements" caractérise l'immeuble comme une éventuelle propriété "NombreEntrées" ou "RevetementFacade", ...
Aussi comme E-ric l'a dit, cela te permets de maitriser l'interface de la classe que tu créeras.
C'est pourquoi je pense qu'il faut effectivement composer avec une liste, et non pas hériter d'une liste.

Bon très bien ton immeuble gère entre autres une liste d'appartements. Maintenant, tu as comme tu l'as suggéré plusieurs types à disposition qui nous permettent de ne pas avoir à réinventer la roue (une des choses que nous apprécions avec Delphi).

Eh bien là je dirai qu'il te faut choisir tes armes, tu fais comme bon te semble, en fonction de ce qu'il y a à faire avec ces appartements et cet immeuble. Tout dépend. Si c'est pour faire un logiciel de batiment ou un jeu de plateformes ca changera surement.

En l'occurence je puis ajouter à tes propositions :
- TOwnedCollection et TCollectionItem, pratique tu ajoutes les appartements en conception si tu veux, mais par contre ca t'oblige à faire hériter tes appartements de TCollectionItem...
- Mieux que TObjectList si tes appartements seront des TComponent, TComponentList. Tu en fais un descendant TAppartementList pour ne pas avoir à transtyper, et hop lorsque tu libères un TAppartement hop il s'enlève de la liste (hyper pratique, à priori c'est la solution que j'emploierais).

[e-ric]

L'ObjectList gère cela tout seul. Il n'est qu'un conteneur à pointeurs, c'est tout. Je ne vois pas pourquoi il faut surcharger le Destroy de l'Appartement. Si tu supprimes un appartement, il est d'office retiré de la liste et sa référence est effacée. Que veut le peuple ?

Simplement en cas de destruction explicite d'un composant de la liste:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
MonImmeuble[0].Free;

en suposant bien sûr la liste non vide.

C'est un problème récurrent avec Delphi car la composition n'existe pas, il faut la simuler.

e-ric

[e-ric]

je veux bien entendu parler de composition d'objets.

e-ric

[Pero]

C'est un problème récurrent avec Delphi car la composition n'existe pas, il faut la simuler

Faux ! Archi faux !

Dans une composition, la destruction du composite entraine la destruction de tous ses composants. Avec une ObjectList, c'est exactement ce qu'il se passe. Tu détruis la liste, tous les objets qui y étaient sont détruits avec. Ce n'est pas pour rien que le paramètre du Create est AOwnsObjects.

[DMO]

TObjectList (...) Si tu supprimes un appartement, il est d'office retiré de la liste et sa référence est effacée.

TObjectList n'implémente pas cela, tu confonds avec TComponentList (qui le fait grâce aux "FreeNotification" des TComponent).

Par contre en effet depuis TObjectList (donc TComponentList en hérite également), les objets peuvent potentiellement être libérés lorsqu'ils sont supprimés de la liste ou si la liste est détruite (OwnsObjects).

[Pero]

TObjectList n'implémente pas cela

Loin de moi l'idée de vouloir contredire à tout prix mais si tu retires un appartement de la liste (voir la méthode Remove), on arrive à une notification dans l'ObjectList qui est la suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
procedure TObjectList.Notify(Ptr: Pointer; Action: TListNotification);
begin
  if OwnsObjects then
    if Action = lnDeleted then
      [b]TObject(Ptr).Free;[/b]
  inherited Notify(Ptr, Action);
end;

Comme tu peux le voir, l'object indiqué est bien libéré. De plus, dans toute la procédure du Remove, on peut remarquer une procedure en assembleur qui décale les références des autres objets dans la liste.

[e-ric]

C'est un problème récurrent avec Delphi car la composition n'existe pas, il faut la simuler

Faux ! Archi faux !

Dans une composition, la destruction du composite entraine la destruction de tous ses composants. Avec une ObjectList, c'est exactement ce qu'il se passe. Tu détruis la liste, tous les objets qui y étaient sont détruits avec. Ce n'est pas pour rien que le paramètre du Create est AOwnsObjects.

T'as pas bien lu ou tu comprends mal ou encore les deux ;-)

Je répète, la composition d'objet n'existe pas dans Delphi, dans le sens où si tu veux qu'un container posséde ses objets, il faut pour en donner l'impression en codant ceci dans le texte de classe de ton composite. Regardes bien le code de la classe TObjectList, tu verras bien.

Effectivement si tu détruis la liste d'objet, elle détruit tous ses composants, c'est codé dans le destructeur de TObjectList. Mais une véritable implémentation de la composition au niveau du langage nous en dispenserait.

En outre, l'instruction que j'ai donné, à savoir :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
MonImmeuble[0].Free;

(Rien ne l'interdit dans le langage - sémantique de référence).
détruit individuellement un élément de la liste et non pas la liste, mais la liste n'est pas avertie de cette destruction. C'est bien dommage !

Encore une objection ??

La solution de DMO est intéressante mais elle nécessite la dérivation de deux classes. C'est un choix.

e-ric

[Pero]

La propriété "ListeAppartements" caractérise l'immeuble comme une éventuelle propriété "NombreEntrées" ou "RevetementFacade", ...
C'est pourquoi je pense qu'il faut effectivement composer avec une liste, et non pas hériter d'une liste.

Il est vrai que si mon immeuble est composé d'autre chose que d'appartements, avec ma méthode je suis mal. Dans ce cas vaut mieux faire comme tu le dis, composer avec une liste - une TAppartementList héritée de TObjectList -

En l'occurence je puis ajouter à tes propositions :
- TOwnedCollection et TCollectionItem, pratique tu ajoutes les appartements en conception si tu veux, mais par contre ca t'oblige à faire hériter tes appartements de TCollectionItem...

Si tu es en conception ... mouais ...

- Mieux que TObjectList si tes appartements seront des TComponent, TComponentList. Tu en fais un descendant TAppartementList pour ne pas avoir à transtyper, et hop lorsque tu libères un TAppartement hop il s'enlève de la liste (hyper pratique, à priori c'est la solution que j'emploierais).

Le TComponent n'est pas fait pour cela

[e-ric]

TObjectList n'implémente pas cela

Loin de moi l'idée de vouloir contredire à tout prix mais si tu retires un appartement de la liste (voir la méthode Remove), on arrive à une notification dans l'ObjectList qui est la suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
procedure TObjectList.Notify(Ptr: Pointer; Action: TListNotification);
begin
  if OwnsObjects then
    if Action = lnDeleted then
      [b]TObject(Ptr).Free;[/b]
  inherited Notify(Ptr, Action);
end;

Comme tu peux le voir, l'object indiqué est bien libéré. De plus, dans toute la procédure du Remove, on peut remarquer une procedure en assembleur qui décale les références des autres objets dans la liste.

Ok si tu passes par Remove (je n'ai soutenu le contraire) mais dans mon instruction avec Free, t'es bien dans l'embarras puisque l'appel de méthode est fait depuis le composant et non pas depuis le composite.

e-ric

[e-ric]

j'espère que notre joute amuse un peu Eponette ;-)

e-ric

[Pero]

Je répète, la composition d'objet n'existe pas dans Delphi, dans le sens où si tu veux qu'un container posséde ses objets, il faut pour en donner l'impression en codant ceci dans le texte de classe de ton composite. Regardes bien le code de la classe TObjectList, tu verras bien.

Effectivement si tu détruis la liste d'objet, elle détruit tous ses composants, c'est codé dans le destructeur de TObjectList. Mais une véritable implémentation de la composition au niveau du langage nous en dispenserait.

Je ne suis pas d'accord avec toi 8) Quand tu fais ObjectList.Add(blabla) , l'ObjectList maintient une liste en interne, preuve que c'est elle qui possède les éléments ajoutés.

Je ne comprends pas où tu veux en venir. Tu dis à une liste : "Je te donne cet objet (Add). Tu en es responsable (AOwnsObjects = True). Si tu meurs, mon objet mourra avec toi (dans le Destroy)" ... Je ne vois pas ce qu'il faut de plus pour te prouver qu'il s'agit bien d'une composition, et sans en donner "l'impression" comme tu dis.

En outre, l'instruction que j'ai donné, à savoir :

MonImmeuble[0].Free;

(Rien ne l'interdit dans le langage - sémantique de référence).
détruit individuellement un élément de la liste et non pas la liste, mais la liste n'est pas avertie de cette destruction. C'est bien dommage !

D'accord avec toi Mais ... comme je l'ai dit, si il s'agit d'une classe interne, tu dois savoir comment on s'en sert. Si c'est pour l'extérieur, alors d'accord, tu encapsules un peu mieux.



Et c'est en "joutant" que l'on devient fort On a toujours à apprendre des autres. Comme dirait l'autre : "La connaissance s'accroit quand on la partage"


Si cela ne vous dérange pas, je remets mon cheval à l'écurie jusque demain

[DMO]

Pero, pour répondre à tes doutes au sujet de ce que j'ai avancé, je soulèverai simplement la forte imprécision de ta remarque :

Si tu supprimes un appartement, il est d'office retiré de la liste et sa référence est effacée.

Lorsque avec "Si tu supprimes", j'entendais "Appartement1.Free", tu voulais dire ListeAppartement.Delete(indice). Bon soit. Fort heureusement je crois qu'E-ric a bien expliqué la différence.

Si TImmeuble et TAppartement sont des TComponent, il est fort judicieux d'utiliser TComponentList. Eponette aura compris qu'alors avec un simple Appartement1.Free, la liste sera notifiée sans aucun appel explicite, et elle retirera d'elle même la référence. C'est un comportement que j'estime être très pratique.

Le tout est que nous ayons apporté des propositions claires au problème posé. Je ne réponds pas aux "...mouais..." et autres "" stériles, mais j'espère simplement que parmis toutes les idées proposées Eponette trouvera des bases de sa solution.

[e-ric]

Si la composition était réelle, le codage du destructeur ne serait pas nécessaire.

Savoir comment fonctionne un objet, ce n'est pas toujours facile (quand on a pas les sources) et quand on est le créateur de la classe, il faut s'efforcer de ne pas faire trop d'hypothèses sur la discipline des programmeurs qui vont s'en servir. Mais je reconnais que ce n'est pas toujours simple.

Ces petites nuances peuvent parfois introduire des bugs très subtiles.

L'ObjectList maintient une liste de références d'objet en interne pas une liste d'objet ce n'est pas tout à fait la même chose.

See You Soon and good night

e-ric

[Pero]

Je ne réponds pas aux "...mouais..." et autres stériles

Le ... mouais ... signifiait "à la limite". Moi je ne le ferais pas. Je ne vois pas ce qu'il y a de mal.

Pour ce qui est du TComponent, je dois avouer que c'est certainement une piste à creuser. J'ai été un peu vite dans ma réponse. La faute à mon fidèle destrier certainement.

Il est vrai que nous sommes nombreux à avoir le réflexe "composant = palette" ... mea culpa.

[eponette]

Merci pour cette superbe dissertation sur le sujet...

Mais je suis confus 8)

Mais si j'ai bien compris , une proposition est de faire une classe
TImmeuble = class(TComponent)
et une classe
TAppartement = class(TComponent)

Dans TImmeuble, je mets un TComponentList qui contiendra mes Tappartement.

Maintenant, j'ajoute une difficulté

Je veux visualiser cela dans un TreeView (mes Immeubles avec leurs appartements (qui eux-mêmes auront leurs pièces)).

[DMO]

Oui c'est une des voies proposées en effet.
Tu l'as visiblement bien comprise. Si tu la suis, et pour répondre à ta question, je te suggèrerai l'utilisation de composants graphiques virtuels.

Tu as à ta disposition le TGridView, le TVirtualTreeView, etc... Ce dernier ferait bien l'affaire par exemple.

[Edit]
Si tu optes pour le TVirtualTreeView, juste une petite suggestion : j'ai tendance perso à ajouter à TVirtualNode un "DataObject: TObject" (juste avant la note) car je n'aime pas trop travailler avec les record : je préfère les classes.
[/Edit]

Le principe est de ne pas dupliquer les données entre ta gestion en mémoire avec les TImmeuble et les TAppartement et leur affichage (ce serait d'ailleurs assez chiant de faire correspondre tout ca).
Tu peux même éventuellement regarder du côté des datasets virtuels (mais l'affichage en TreeView est alors plus compliqué à moins de posséder un TDBTreeView, mais je n'en connais pas).

Bon dev' !