Après avoir lu "Créer du code bien conçu (basé sur Delphi/VCL)" que j'ai écrit la dernière fois, de nombreux amis m'ont dit que je sentais que je pouvais accepter les points de vue qu'il contenait, mais cela semblait trop simple et pas assez spécifique ; certains amis ont également exprimé des doutes à ce sujet. Un petit exemple de quelques objections. D'où cet article.
La dernière fois, l'exemple que j'ai donné était le suivant : Supposons que vous souhaitiez obtenir une liste de chaînes quelque part, puis l'afficher dans une TListBox. Le code que je recommande est :
ObjetXXX := TObjectXXX.Create;
ListBox1.Items := ObjectXXX.GetStringList;
ObjetXXX.Free ;
En effet, j'avoue qu'à en juger par ces trois seules lignes de code, il semble être suspecté d'"abus d'objet". L'exemple est peut-être trop simple, donnant l'impression que TObjectXXX n'a qu'une seule fonction membre publique, GetStringList. Si cela est vrai, il s'agit en réalité d'un "abus d'objet". Une classe est une abstraction d'un objet et un objet est composé d'un ensemble d'états et d'opérations (c'est-à-dire des données et des opérations sur les données). Par conséquent, un objet sans état n’est pas un objet ! La conception d’une classe sans données privées membres est une conception ratée (il ne s’agit pas d’une classe, mais d’une interface).
D'accord, laissez-moi vous donner un exemple détaillé pour illustrer comment séparer le code d'interface et le code de fonction.
Supposons que je veuille créer un simple logiciel de gestion de carnet d'adresses personnel. Évidemment, l'ensemble du logiciel est divisé en deux parties : une partie est orientée utilisateur, ce qu'on appelle la partie interface. Je peux fournir quatre boutons (respectivement "ajouter"). , " "Supprimer", "Modifier", "Rechercher") et une zone d'édition (affichant les informations du carnet d'adresses et acceptant les entrées de l'utilisateur) sont utilisées pour interagir avec l'utilisateur ; l'autre partie est fonctionnelle, c'est-à-dire l'opération d'accès du carnet d'adresses dans le logiciel.
Il existe donc une classe TAddrBook, qui est une abstraction de la partie fonctionnelle.
TAddrBook = classe
Privé
//Quelques membres privés
publique
constructeur Créer ;
destructeur Détruire ; remplacer ;
GetCount : entier ;
FindRecord(strString) : entier ;
GetRecord(nIndex:Integer) : Chaîne ;
SetRecord(nIndex:integer; strRec:String) : Booléen ;
AddRecord(strRec:String) : booléen ;
DelRecord(nIndex) : booléen ;
//Autres fonctions membres partagées
fin;
La raison pour laquelle les membres privés ne peuvent pas être déterminés dépend principalement de la mise en œuvre de cette classe.
De cette manière, la logique des opérations d'accès au carnet d'adresses peut être encapsulée. Le code dans la partie interface n’impliquera pas ces logiques d’accès. Le code de la pièce de l'interface est le suivant :
var
Formulaire1 : TForm1 ;
Livre d'adresses : TAddrBook ;
nCurRec : entier ;
mise en œuvre
procédure TForm1.FormCreate(Expéditeur : TObject);
commencer
AddrBook := TAddrBook.Create;
nCurRec := AddrBook.GetCount;
fin;
procédure TForm1.FormClose(Expéditeur : TObject ; var Action : TCloseAction) ;
commencer
AddrBook.Gratuit ;
fin;
//Ajouter un bouton
procédure TForm1.Button1Click(Expéditeur : TObject);
commencer
sinon AddrBook.AddRecord(memo1.Text) alors
ShowMessage("erreur");
fin;
//Bouton Supprimer
procédure TForm1.Button2Click(Expéditeur : TObject);
commencer
sinon AddrBook.DelRecord(nCurRec) alors
ShowMessage("erreur");
fin;
//bouton modifier
procédure TForm1.Button3Click(Expéditeur : TObject);
commencer
sinon AddrBook.SetRecord(nCurRec, memo1.Text) alors
ShowMessage("erreur");
fin;
// Bouton Rechercher
procédure TForm1.Button4Click(Expéditeur : TObject);
commencer
memo1.Text := AddrBook.GetRecord(AddrBook.FindRecord(memo1.Text));
fin;
Le code de la partie interface ci-dessus n'implique aucune logique d'accès. Le code de chaque module est simple, facile à comprendre et à maintenir. En fait, le code d'interface ne sait pas si le carnet d'adresses est enregistré dans une base de données ou dans un fichier texte. Si une base de données est utilisée, si la base de données est accessible via ODBC, ADO ou BDE, le code d'interface ne le sait pas. En fait, ces logiques d'accès dépendent de l'implémentation de la classe TAddrBook. L'implémentation de la classe TAddrBook peut être placée dans un fichier .pas séparé. Toute modification apportée à l'implémentation de la classe TAddrBook n'affectera pas la partie interface. Lors de la maintenance du code, il est sage de limiter les modifications à un seul module.
Nicrosoft([email protected]) le 2001.7.14