Intégrer la pensée orientée objet tout au long - Parler du développement Delphi (Partie 2)

(Suite du premier article)

En gardant la pensée orientée objet tout au long, ce sujet semble un peu vaste. Ce que je viens de dire et de mentionner ici ne sont en fait que quelques problèmes mineurs auxquels il convient de prêter attention lors du codage. Par conséquent, il serait peut-être plus approprié de remplacer le terme « tout au long » par « garder à l’esprit ».

Quelques commentaires sur certaines fonctionnalités de Delphi :

Je me demande si vous avez remarqué que tous les composants (y compris les contrôles) placés dans un formulaire Delphi sont visibles par les autres formulaires. Pour être précis, ces composants sont le contenu de la partie publique du formulaire. D'un côté, ce résultat est bon, du fait de sa flexibilité, d'autres classes peuvent facilement référencer ces composants sur le Formulaire, définir leurs propriétés, exécuter leurs méthodes, événements, etc. mais d'un autre côté, ses défauts sont également évidents ; . Oui, cela entraîne la perte de l'encapsulation de Form. À mon avis, ces composants placés sur le formulaire, en ce qui concerne l'intention de l'utilisateur, devraient exister en tant que propriétés privées du formulaire et ne devraient pas être visibles par d'autres classes ou d'autres formulaires. Même si vous devez y accéder, vous devez y accéder indirectement via une série de méthodes de propriété fournies par Form.

Donnez un exemple pour donner à chacun une certaine compréhension perceptuelle :

PRécédure TForm1.Button1Click(Expéditeur : TObject);

commencer

Form2.Edit1.Text := 'abc'; // <-- Je ne suis pas d'accord avec la façon dont cette phrase est écrite.

fin;

Beaucoup de gens n'ont peut-être pas le concept d'encapsulation en tête lorsqu'ils écrivent un tel code, mais après avoir lu cet article, vous ne ferez plus jamais une telle chose (s'il vous plaît, changez vos habitudes !). À mon avis, TForm1 est TForm1 et TForm2 est TForm2. Ils existent tous pour réaliser certaines fonctions spécifiques, ils fournissent donc des interfaces avec le monde extérieur (certains attributs, méthodes et événements. À proprement parler, les événements sont également des attributs. ) atteindre leurs fonctions promises. Quant à la mise en œuvre spécifique de ces interfaces, elles doivent être entretenues par elles-mêmes. Il n'y a aucun besoin ni moyen d'intervention du monde extérieur. Cette idée correspond à des applications pratiques, c'est-à-dire à la question de savoir si Form2.Edit1 doit être directement accessible par From1. Personnellement, je préfère la mise en œuvre suivante :

//Ce qui suit fait partie du contenu de TForm1 dans Unit1

procédure TForm1.Button1Click(Expéditeur : TObject);

commencer

TForm2(FAnotherForm).EditText := 'abc'; // <-- Cette implémentation incarne l'idée d'encapsulation

fin;

//Ce qui suit est la définition de TForm2 dans Unit2

taper

TForm2 = classe(TForm)

Edit1 : TEdit ;

privé

fonction GetEditText : chaîne ;

procédure SetEditText (valeur const : chaîne );

publique

propriété EditText : chaîne lue GetEditText écriture SetEditText ;

// <-- Mon utilisation recommandée ;

fin;

…

fonction TForm2.GetEditText : chaîne ;

commencer

résultat := Edit1.Text;

fin;

procédure TForm2.SetEditText(const Value: string);

commencer

si Valeur <> EditText alors

Edit1.Text := Valeur ;

fin;

FAnotherForm est ici une propriété privée de TForm1, qui est un pointeur vers une instance de TForm2 (cette utilisation a été soulignée dans le premier article). Accéder à la propriété EditText de TForm2 au lieu d'accéder directement et imprudemment à Edit1.Text de TForm2 incarne une idée, c'est-à-dire l'idée de division du travail et de collaboration, c'est-à-dire l'idée d'indépendance, c'est-à-dire l'idée de encapsulation.

(Inachevé, à suivre)

Plus d'articles