Utilisation de cadres en Delphi pour cacher des informations GUI

Question

J'ai appris Delphi ces 3 dernières années, à un niveau de passe-temps/professionnel. Je suis heureux de dire que j'ai maintenant progressé au point que je peux revenir sur mon premier code avec horreur et embarras. Donc, je suis en train de passer en revue certaines de mes premières applications et de les réécrire/refactoriser.

L'une des mauvaises habitudes que j'essaie d'éviter est l'accès aux composants d'un formulaire à partir d'une autre unité. Dans un effort pour faire respecter cela, j'ai expérimenté l'utilisation de cadres comme une méthode de dissimulation de l'information. Ainsi, au lieu d'avoir une forme avec des composants sur, je suis en train de créer un cadre pour contenir tous les éléments de formulaire, puis en plaçant le cadre sur une forme, le déplacement de la déclaration de cadre dans les déclarations privées,

type 
    TMyForm = class(TForm) 
    private 
    MyFrame: TMyFrame; 
    procedure SetTimeDate(const Value: TMyItem); 
    function ReadTimeDate:TMyItem ; 

puis l'enregistrement de la cadre dans la section d'initialisation du formulaire

initialization 
begin 
RegisterClasses([TMyFrame]) 

Je puis déclarer les propriétés dont j'ai besoin dans la partie publique de l'unité de forme, qui a accès au châssis et ses composants. J'utilise également des cadres pour consolider des groupes de composants souvent répétés.

Cela semble fonctionner pour les buts que je veux (en cachant Myframe et ses composants), mais est-ce que quelqu'un d'autre a une quelconque expérience de cette méthode?

Y a-t-il des inconvénients à utiliser des cadres? Est-ce que je profite vraiment de cela? L'utilisation d'images imbriquées dans des cadres pose-t-elle des problèmes? Existe-t-il des guides de bonnes pratiques sur l'utilisation des cadres dans Delphi? Existe-t-il des moyens meilleurs/plus faciles d'obtenir le même effet en ce qui concerne les informations GUI cachées dans Delphi?

HMCG

Answer 1

On dirait que vous avez encore beaucoup de logique dans votre couche d'interface utilisateur. Forms/Panels ne devrait pas avoir autant de propriétés Value (sauf peut-être pour Dialogs).

Si vous voulez plus de structure que de lire sur le modèle MVC.

Après avoir dit tout cela, les cadres peuvent être un bon moyen d'organiser l'interface graphique. Comme avec tout, ne pas abuser. J'aime la trame généralement pour créer des bits réutilisables complexes.

Answer 2

Pour la plupart, je pense qu'ils peuvent être une façon vraiment propre de construire des écrans. Cependant, comme mentionné par Henk Holterman vos écrans et cadres devraient seulement contenir la logique relative au fonctionnement de l'interface utilisateur et être aussi ignorants que possible sur la logique métier.

Un couple de points re cadres et cacher des informations dans l'interface utilisateur:

1. Comme discuté in another question on StackOverflow vous devez être prudent lorsque vous utilisez des gestionnaires d'événements dans votre cadre.
2. Les trames ont encore beaucoup de propriétés publiées et ne résolvent pas vraiment le problème des formes qui peuvent mal manipuler les bits les uns des autres. Même si vous ne le faites pas, si le code le permet, quelqu'un finira par écrire du code qui altère ce qu'il ne devrait pas faire. Je supprime toujours la variable de formulaire globale Delphi sullies le code avec et souvent écrire des objets wrapper ou implémenter des interfaces qui fournissent un accès contrôlé à l'interface utilisateur.

Ainsi, au lieu d'avoir le code comme ceci:

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 ont la méthode de classe ShowClient gérer le bit montré dans le premier li piquer. De cette façon, le code appelant ne reçoit jamais le pointeur de formulaire et ne peut pas toucher les bits qui ne sont pas fournis spécifiquement par la classe wrapper.