(Fortsetzung vom ersten Artikel)
Unter Beibehaltung des objektorientierten Denkens scheint dieses Thema etwas umfangreich zu sein. Was ich hier gerade gesagt und erwähnt habe, sind eigentlich nur einige kleinere Probleme, die beim Codieren beachtet werden sollten. Daher ist es möglicherweise angemessener, den Begriff „durchgehend“ in „im Hinterkopf behalten“ zu ändern.
Einige Kommentare zu einigen Funktionen von Delphi:
Ich frage mich, ob Ihnen aufgefallen ist, dass alle in einem Delphi-Formular platzierten Komponenten (einschließlich Steuerelemente) für andere Formulare sichtbar sind. Genauer gesagt sind diese Komponenten der Inhalt des öffentlichen Teils des Formulars. Einerseits ist dieses Ergebnis gut, da andere Klassen aufgrund seiner Flexibilität problemlos auf diese Komponenten im Formular verweisen, ihre Eigenschaften festlegen, ihre Methoden, Ereignisse usw. ausführen können, andererseits sind auch die Mängel offensichtlich . Ja, das führt zum Verlust der Kapselung von Form. Meiner Meinung nach sollten diese auf dem Formular platzierten Komponenten, soweit es die Absicht des Benutzers betrifft, als private Eigenschaften des Formulars vorhanden sein und für andere Klassen oder andere Formulare nicht sichtbar sein. Auch wenn Sie darauf zugreifen müssen, sollten Sie indirekt über eine Reihe von Eigenschaftsmethoden zugreifen, die von Form bereitgestellt werden.
Geben Sie ein Beispiel, um allen ein gewisses Wahrnehmungsverständnis zu vermitteln:
PROzedur TForm1.Button1Click(Sender: TObject);
beginnen
Form2.Edit1.Text := 'abc'; // <-- Ich bin mit der Schreibweise dieses Satzes nicht einverstanden.
Ende;
Viele Menschen haben beim Schreiben eines solchen Codes möglicherweise nicht das Konzept der Kapselung im Kopf, aber nachdem Sie diesen Artikel gelesen haben, werden Sie so etwas nie wieder tun (bitte ändern Sie Ihre Vorgehensweise!). Meiner Meinung nach ist TForm1 TForm1 und TForm2 ist TForm2. Sie alle existieren, um bestimmte spezifische Funktionen zu erreichen, sodass sie einige Schnittstellen zur Außenwelt bereitstellen (einige Attribute, Methoden und Ereignisse. Streng genommen sind Ereignisse auch Attribute. ). ihre versprochenen Funktionen erreichen. Was die spezifische Implementierung dieser Schnittstellen angeht, sollten sie selbst gepflegt werden. Es besteht keine Notwendigkeit oder Möglichkeit für ein Eingreifen der Außenwelt. Diese Idee entspricht praktischen Anwendungen, also der Frage, ob From1 direkt auf Form2.Edit1 zugreifen muss. Ich persönlich bevorzuge die folgende Implementierung:
//Das Folgende ist Teil des Inhalts von TForm1 in Unit1
procedure TForm1.Button1Click(Sender: TObject);
beginnen
TForm2(FAnotherForm).EditText := 'abc'; // <-- Diese Implementierung verkörpert die Idee der Kapselung
Ende;
//Das Folgende ist die Definition von TForm2 in Unit2
Typ
TForm2 = Klasse(TForm)
Edit1: TEdit;
Privat
Funktion GetEditText: string;
procedure SetEditText(const Value: string);
öffentlich
Eigenschaft EditText: String read GetEditText write SetEditText;
// <-- Meine empfohlene Verwendung;
Ende;
…
Funktion TForm2.GetEditText: string;
beginnen
Ergebnis := Edit1.Text;
Ende;
procedure TForm2.SetEditText(const Value: string);
beginnen
wenn Wert <> EditText dann
Edit1.Text := Wert;
Ende;
FAnotherForm ist hier eine private Eigenschaft von TForm1, die ein Zeiger auf eine Instanz von TForm2 ist (diese Verwendung wurde im ersten Artikel hervorgehoben). Der Zugriff auf die EditText-Eigenschaft von TForm2 anstelle des rücksichtslosen direkten Zugriffs auf Edit1.Text von TForm2 verkörpert eine Idee, nämlich die Idee der Arbeitsteilung und Zusammenarbeit, also die Idee der Unabhängigkeit, also die Idee von Kapselung.
(Unvollendet, Fortsetzung folgt)
Weitere Artikel