Utilisation de cadres en Delphi pour masquer les informations de l'interface utilisateur

Question

J'ai appris Delphi au cours des 3 dernières années, à un niveau de passe-temps / professionnel. Je suis heureux de dire que j'ai maintenant progressé au point de pouvoir regarder en arrière mon code du début avec horreur et gêne. Je suis donc en train de passer en revue certaines de mes premières applications et de les réécrire/les refactoriser.

Une des mauvaises habitudes que j'essaie d'abandonner est d'accéder à des composants sur une forme depuis une autre unité. Dans un effort pour imposer cela, j'ai expérimenté l'utilisation de cadres comme méthode de dissimulation d'informations. Donc au lieu d'avoir une forme avec des composants dessus, je crée un cadre pour contenir tous les composants de la forme, puis place le cadre sur une forme, déplace la déclaration du cadre dans les déclarations privées,

type
  TMyForm = class(TForm)
   private
    MyFrame: TMyFrame;
    procédure SetTimeDate(const Value: TMyItem);
    fonction ReadTimeDate:TMyItem ;

ensuite enregistre le cadre dans la section d'initialisation de la forme

initialization 
begin
RegisterClasses([TMyFrame])

Je déclare ensuite les propriétés dont j'ai besoin dans la section publique de l'unité de forme, qui a accès au cadre et à ses composants.

  public
    propriété TimeDate: TMyItem  lire ReadTimeDate  écrire SetTimeDate;

J'utilise également des cadres pour consolider des groupes de composants souvent répétés.

Cela semble fonctionner pour les objectifs que je veux atteindre (cacher Myframe et ses composants), mais est-ce que quelqu'un d'autre a de l'expérience avec cette méthode?

Y a-t-il des inconvénients à utiliser des cadres? Est-ce que j'obtiens réellement un avantage en faisant cela? Y a-t-il des problèmes à utiliser des cadres imbriqués dans des cadres? Y a-t-il des guides de bonnes pratiques pour utiliser des cadres en Delphi? Y a-t-il de meilleures/façons plus faciles d'atteindre le même effet en ce qui concerne la dissimulation d'informations GUI en Delphi?

HMcG

Answer 1

Il semble que vous ayez toujours beaucoup de logique dans votre couche UI. Les formulaires / panneaux ne devraient pas avoir autant de propriétés de valeur (sauf peut-être pour les boîtes de dialogue).

Si vous voulez plus de structure, renseignez-vous sur le modèle MVC.

Cela dit, les cadres peuvent être un bon moyen d'organiser l'interface graphique. Comme pour tout, ne pas en abuser.

Answer 2

J'aime généralement les frames pour créer des éléments réutilisables complexes. Pour la plupart, je pense qu'ils peuvent être un moyen vraiment propre de construire des écrans. Cependant, comme mentionné par Henk Holterman, vos écrans et frames ne devraient contenir que la logique liée au fonctionnement de l'interface utilisateur et être aussi ignorants que possible de la logique métier.

Quelques points concernant les frames et la dissimulation d'informations dans l'interface utilisateur :

1. Comme discuté dans une autre question sur StackOverflow, vous devez faire attention lorsque vous utilisez des gestionnaires d'événements dans votre frame.
2. Les frames ont encore de nombreuses propriétés publiées et ne résolvent pas vraiment le problème des formulaires pouvant interférer de manière inappropriée avec les éléments des autres. Même si vous ne le faites pas, si le code le permet, quelqu'un finira par écrire du code qui s'y introduira là où il ne le devrait pas. Je supprime toujours la variable de formulaire globale que Delphi salit le code avec et j'écris souvent des objets d'encapsulation ou implémente des interfaces qui fournissent un accès contrôlé à l'interface utilisateur.

Alors au lieu d'avoir du code comme celui-ci :

ClientForm := TClientViewForm.Create(Self);
try
  ClientForm.Client := MyClient;
  ClientForm.ShowModal;
finally
  ClientForm.Free;
end;

Je force généralement les gens à écrire quelque chose du genre :

ClientViewer := TClientViewer.Create(MyClient);
try
  ClientViewer.Show;
finally
  ClientViewer.Free;
end;

ou même

TClientViewer.ShowClient(MyClient);

et faire en sorte que la méthode de classe ShowClient gère l'élément montré dans le premier listing. De cette manière, le code appelant ne reçoit jamais le pointeur de formulaire et ne peut pas toucher à des éléments qui ne sont pas spécifiquement fournis par la classe d'encapsulation.