Règle 1 : Créer une unité pour chaque classe (Une classe, une unité)
Gardez toujours cela à l'esprit : les parties privées (PRivate) et protected (protected) d'une classe sont masquées uniquement des classes et des procédures des autres unités. Par conséquent, si vous souhaitez une encapsulation efficace, vous devez fournir à chaque classe A une unité différente. Pour certaines classes simples, comme celles qui héritent d’autres classes, vous pouvez utiliser une unité partagée. Cependant, le nombre de classes partageant une même unité est limité : ne mettez pas plus de 20 classes complexes dans une unité simple.
Règle 2 : nommer les composants
Il est également important d'utiliser des noms descriptifs pour les composants. La manière la plus courante de nommer est de commencer par une lettre minuscule de la classe, plus la fonction du composant, telle que BtnAdd ou editName.
Règle 3 : Nommer les événements
Il est encore plus important de donner des noms appropriés aux méthodes de gestion des événements. Si vous donnez au composant un nom approprié, le nom par défaut du système ButtonClick deviendra BtnAddClick. Bien que nous puissions deviner la fonction de ce gestionnaire d'événements à partir du nom, je pense que c'est une meilleure façon d'utiliser un nom qui décrit la fonction de la méthode plutôt que d'utiliser le nom attaché par Delphi. Par exemple, l'événement OnClick du bouton BtnAdd peut être nommé AddToList. Cela rendra votre programme plus lisible, en particulier lorsque vous appelez le gestionnaire d'événements dans d'autres méthodes de la classe, et cela aidera les programmeurs à choisir la même méthode pour des événements similaires ou des composants différents.
Règle 4 : Utiliser les méthodes de formulaire
Les formulaires sont des classes, donc le code du formulaire est organisé par méthodes. Vous pouvez ajouter des gestionnaires d'événements à un formulaire. Ces gestionnaires exécutent des fonctions spéciales et peuvent être appelés par d'autres méthodes. En plus des méthodes de gestion des événements, vous pouvez ajouter des méthodes spécialement définies à un formulaire pour effectuer des actions et des méthodes pour accéder à l'état du formulaire. Il est préférable d'ajouter des méthodes publiques (Public) au formulaire pour que d'autres formulaires puissent l'appeler plutôt que pour que d'autres formulaires exploitent directement ses composants.
Règle 5 : Ajouter des constructeurs de formulaire
Le deuxième formulaire créé au moment de l'exécution fournit des constructeurs spéciaux en plus d'un constructeur par défaut (hérité de la classe Tcomponent).
Je vous suggère de surcharger la méthode Create et d'ajouter les paramètres d'initialisation nécessaires. Le code spécifique peut être trouvé dans le code suivant :
Publique
Constructeur Create(Text:string) : réintroduction ; surcharge ;
Constructeur TformDialog.Create(Text:string);
Commencer
Hérité Create(application);
Edit1.Text:=Texte;
Fin;
Règle 6 : évitez les variables globales
Les variables globales (celles définies dans la section interface d'une unité) doivent être évitées. Vous trouverez ci-dessous quelques suggestions sur la façon de procéder.
Si vous devez stocker des données supplémentaires pour un formulaire, vous pouvez ajouter des données privées à la classe du formulaire. Dans ce cas, chaque instance de formulaire aura sa propre copie des données. Vous pouvez utiliser des variables d'unité (variables définies dans la section d'implémentation de l'unité) pour déclarer des données partagées par plusieurs instances d'une classe de formulaire.
Si vous devez partager des données entre différents types de formulaires, vous pouvez les définir dans le formulaire principal pour réaliser le partage, ou utiliser une variable globale, utiliser des méthodes ou des propriétés pour obtenir des données.
Règle 7 : n'utilisez jamais Form1 dans la classe Tform1
Vous devez éviter d'utiliser un nom d'objet spécifique dans les méthodes de la classe. En d'autres termes, vous ne devez pas utiliser Form1 directement dans les méthodes de la classe TForm1. Si vous avez vraiment besoin d'utiliser l'objet courant, vous pouvez utiliser le mot-clé Self.
Règle 11 : exposer les propriétés des composants
Lorsque vous devez accéder à l’état d’un autre formulaire, vous ne devez pas accéder directement à ses composants. Parce que cela combinera le code d’autres formulaires ou d’autres classes avec l’interface utilisateur, et l’interface utilisateur est souvent la partie la plus modifiable d’une application. La meilleure approche consiste à définir une propriété de formulaire pour la propriété de composant à laquelle vous devez accéder. Pour y parvenir, vous pouvez utiliser la méthode Get pour lire l'état du composant et la méthode Set pour définir l'état du composant.
Si vous devez maintenant changer d'interface utilisateur et remplacer un composant existant par un autre composant, il vous suffit alors de modifier la méthode Get et la méthode Set liées aux propriétés de ce composant, sans avoir à rechercher et modifier tous les formulaires qui référencez ce composant et le code source de la classe. Pour les méthodes de mise en œuvre détaillées, veuillez consulter le code ci-dessous :
privé
fonction GetText:String;
procédure SetText(const Value:String);
publique
propriété Texte : Chaîne ;
lire GetText écrire SetText ;
fonction TformDialog.GetText:String;
commencer
Résultat :=Edit1.Text ;
fin;
procédure TformDialog.SetText(const Value:String);
commencer
Edit1.Text;=Valeur;
fin;
Règle 16 : Héritage de la forme visuelle
S’il est appliqué correctement, cela peut être un outil puissant. D’après mon expérience, plus le projet que vous développez est vaste, plus il a de la valeur. Dans un programme complexe, vous pouvez utiliser différentes hiérarchies de formulaires pour gérer le polymorphisme dans un groupe de formulaires liés.
L'héritage visuel des formulaires vous permet de partager certaines actions communes de plusieurs formulaires : vous pouvez utiliser des méthodes partagées, des propriétés communes, voire des gestionnaires d'événements, des composants, des propriétés de composants, des méthodes de gestion des événements de composants, etc.
Pour plus d'informations, veuillez consulter : http://lincosoft.go.nease.net/