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

De nombreuses personnes en Chine considèrent Delphi comme leur outil de développement préféré. La raison est bien sûr parce que Delphi offre aux développeurs de nombreuses fonctionnalités : développement orienté objet, conception d'interface visuelle, composants riches et portabilité multiplateforme (nouvelles fonctionnalités de Delphi6).

Mais pour les débutants, la pensée orientée objet n’est peut-être pas le sentiment le plus important que Delphi leur apporte. La conception de l'interface visuelle et les composants disponibles riches et diversifiés laissent l'impression la plus profonde et la plus inoubliable. La conséquence grave de cela est que les débutants se concentrent souvent pendant longtemps uniquement sur l'utilisation des composants VCL existants fournis par Delphi, tout en négligeant de réfléchir à l'impact de la pensée orientée objet sur l'ensemble de Delphi. La signification contenue dans l'architecture des composants système.

Le morceau de code suivant contient l'une des erreurs les plus courantes que commettent souvent les débutants. Bien que cette erreur ne soit pas une erreur grammaticale, elle révèle que la pensée orientée objet de l'utilisateur doit être renforcée :

var

Formulaire1 : TForm1 ;

mise en œuvre

{$R *.dfm}

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

commencer

ShowMessage(Form1.Caption); // <-- Il y a quelques problèmes avec l'utilisation de Form1 ici.

fin;

À première vue, il ne semble y avoir aucun problème avec ce type de code. Cependant, l'apparition de Form1 ici est quelque peu déraisonnable. Évidemment, le code ici est écrit pour implémenter la méthode ButtonClick de TForm1, et Form1, en tant qu'instance de la classe TForm1, est en fait écrit dans l'implémentation de la classe. N'y a-t-il pas une certaine confusion conceptuelle ? Il doit être modifié pour se conformer ? à la pensée orientée objet C'est également très simple et peut s'écrire de deux manières :

1. ShowMessage(Self.Caption); // <-- Cette façon d'écrire est très claire. Les informations à afficher sont la légende de l'instance actuelle de la classe.

2. ShowMessage(Caption); // <-- La méthode d'écriture ici est la même que ci-dessus, mais le mot-clé Self est omis ;

Les trois contenus fondamentaux de la pensée orientée objet sont l’encapsulation, l’héritage et le polymorphisme. Le problème exposé par l’exemple ci-dessus est le problème de l’encapsulation. Des exemples similaires incluent :

var

Formulaire1 : TForm1 ;

...

var

Formulaire2 : TForm2 ;

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

commencer

Form2.Show; // <-- En tant que variable globale, l'utilisation de Form2 ici prête également à confusion.

fin;

L'exemple ci-dessus peut être plus général. Dans la plupart des cas, dans un projet, TForm1 et TForm2 ne peuvent avoir qu'une seule instance chacun, donc un tel code peut être considéré comme passable. Mais au sens strict, il ne répond pas aux exigences de l’encapsulation. Reportez-vous au code suivant :

taper

TForm1 = classe(TForm)

Bouton1 : TButton ;

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

privé

{Déclarations privées}

FSuivant : TForm ;

publique

{Déclarations publiques}

propriété NextForm : TForm lit FNext écrit FNext ;

fin;

var

Formulaire1 : TForm1 ;

mise en œuvre

utilise Unit2 ;

{$R *.dfm}

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

commencer

si attribué (FNext) alors

TForm2(FNext).Afficher;

fin;

fin.

//Voici le contenu du fichier projet :

programme Projet1 ;

utilise

Formulaires,

Unit1 dans 'Unit1.pas' {Form1},

Unit2 dans 'Unit2.pas' {Form2} ;

{$R *.res}

commencer

application.Initialiser ;

Application.CreateForm(TForm1, Form1);

Application.CreateForm(TForm2, Form2);

Form1.NextForm := Form2; // <-- Ajoutez cette phrase pour que le code réponde à peine aux exigences de l'encapsulation

Application.Exécuter ;

fin.

Passez le pointeur Form2 vers Form1 comme attribut de Form1 De cette façon, Form1 respecte le principe d'encapsulation lors de l'appel ! Bien entendu, ces codes ne servent qu'à refléter l'idée de l'encapsulation. Dans la pratique, vous pouvez décider si vous souhaitez vraiment la mettre en œuvre de manière aussi approfondie en fonction de vos habitudes personnelles. Mais ce genre de pensée devrait s'enraciner dans l'esprit... (Inachevé, à suivre).

Plus d'articles