1. Das Gerede eines alten Mannes
Delphi VS VC ist bereits ein sehr altes Thema, aber ich möchte hier immer noch darüber sprechen. Wenn Sie nicht einverstanden sind, lachen Sie bitte.
Die Vorteile von RAD liegen auf der Hand. Was das Schnittstellendesign angeht, ist Delphi tatsächlich besser als VC. Ich möchte eine unkonventionelle transparente Schaltfläche schreiben. In Delphi muss ich nur ein Steuerelement finden, mit der Maus klicken und die Beschriftung ändern. Es sind mindestens 10 Zeilen Code erforderlich, um dies zu erreichen. Der Ansatz von MFC ermöglicht es den Menschen, die zugrunde liegenden Prinzipien von Windows zu verstehen, aber die Kapselung von OOP spiegelt nicht alle zugrunde liegenden Prinzipien wider, bevor sie Code schreiben können Für mich und die meisten ist es eine Qual, Anfänger zu sein, weil es keinen Grund dafür gibt Ja, Entwicklungsfristen sind immer knapp und die Zeit reicht nie aus. Manche Leute wissen viel über Videos und manche sind gut im Networking, aber niemand ist ein Allrounder an allem ist unrealistisch, daher ist die Kapselung sehr wichtig. Wenn ich jedes Mal, wenn ich ein neues Produkt entwickle, 30 % oder mehr meiner Zeit mit einer transparenten Schaltfläche oder einer schönen Benutzeroberfläche verbringen muss, dann springe ich in den Fluss :) Delphi ist in der Tat besser als MFC, was die Benutzeroberfläche angeht! Das bedeutet natürlich nicht, dass MFC keine schönen Schnittstellen entwerfen kann, aber es dauert einfach zu lange und lohnt sich nicht.
Geht es bei RAD wirklich nur um Vorteile? Weder. Zumindest nicht für Anfänger, denn es führt dazu, dass die Leute falsch verstehen, dass es beim Programmieren nur darum geht, die Maus zu bewegen und den Rahmen zu ziehen. Das Endergebnis ist, dass die Leute denken, dass Delphi nur zum Schreiben von Schnittstellen da ist und die unterste Ebene nichts kann. Es scheint, dass alle MFC-Programmierer über Delphi-Programmierer sprechen: „Was kann Ihr Programm außer einer schönen Benutzeroberfläche noch?“ Falsch! Was kann außer DDK in Delphi nicht entwickelt werden? Welche API-Header-Datei hat Delphi nicht? Borland hat nicht konvertiert, aber JEDI hat es konvertiert, aber wenn Sie es selbst tun, kann ich es mit den kurzen Konvertierungsanweisungen versehen Die Dokumentation sollte für jeden Delphi-Programmierer ein Muss sein. Sobald die Header-Dateien konvertiert sind, müssen Sie nur noch mit dem Schreiben beginnen. Was MFC kann, kann auch Delphi! Video? Netzwerk? DirectX? Audio? Was kann Delphi nicht?
2. Unterprozess
Beim Schreiben eines Ereignisses beginnen viele Leute einfach damit, es zu schreiben. Egal wie lang der Code ist oder wie viele Dinge getan werden, solange es in einem Ereignis erledigt wird, schreiben sie es einfach in ihrem Kopf auf Sie haben keine Möglichkeit, einige Monate später mit der Überarbeitung zu beginnen, da der Codeausschnitt zu lang ist. Warum also nicht die Codeschnipsel auseinanderbrechen? Die menschliche Aufmerksamkeit ist begrenzt und Ihnen wird schwindelig, wenn Sie mehr als 100 Zeilen Code auf einmal lesen. Delphi-Senioren haben mir eines gesagt: Alle Prozesse (der Prozess umfasst hier PROzedur und Funktion) sollten 25 Zeilen nicht überschreiten! Da Ihnen diese Codelänge nicht den Kopf verdreht, können Sie leicht verstehen, was der Prozess tut.
Wie zerlegt man also die Dinge, die ursprünglich bei einer Veranstaltung getan wurden? Es gibt viele Methoden, meine Erfahrung ist modular. Wenn beispielsweise in einem Ereignis viele verschiedene Dinge zu tun sind, werden die verschiedenen Dinge in verschiedene Unterprozesse umgewandelt und dann im Hauptprozess aufgerufen. Bei den meisten Hauptprozessen handelt es sich um einige Beurteilungen und Schleifen, und das wird auch der Fall sein Kein spezifischer Implementierungsprozess. Dadurch werden viele Codeschnipsel erstellt, aber Sie bleiben im Fokus!
Prinzip: Ein Prozess macht nur eine Sache, und zwar gut.
Referenz: VCL-Quellcode. Wenn man sich den VCL-Quellcode ansieht, sind es selten mehr als 25 Codezeilen!
3. Parametername
Ich erinnere mich, als ich das SDK zum ersten Mal lernte, wurde mir schwindelig, als ich die ungarische Notation sah, das war zu viel! Ich kann mich nicht daran erinnern! Also ich hasse diesen Erfinder :) Endlich erscheint Delphi und die Tage des Tanzens in Fesseln sind vorbei! In Delphi ist das Definieren einer Zeichenfolge mit einem Variablennamen wie strDoSometing lächerlich und unnötig. Solange Ihre Prozedur kurz ist und keine globalen Variablen auftreten, benötigen Sie kein solches Präfix. Zum Beispiel:
Verfahren SubPro;
var
ich: Byte;
Breite, Höhe: Ganzzahl;
beginnen
Breite := GetWidth;
Höhe := GetHeight;
für i:=0 bis 9 do
beginnen
DrawThread := TDrawThread.Create;
DrawThread.Width := Breite;
DrawThread.Height := Höhe;
DrawThread.Start;
Ende;
Ende;
Ich denke, auch wenn ein solches Codesegment keine Kommentare enthält, ist es leicht zu erkennen, was es zu tun versucht. Bitte entfernen Sie daher alle Präfixe und Unterstriche, Delphi-Programme benötigen diese nicht! Unsere Parameternamen brauchen nur Verb + Substantiv. Wir wollen keine überflüssigen Dinge. Der Vorteil von Pascal ist, dass er aus dem Himmel spricht . In Ihrem Kopf denken Sie, wie der Code aussieht. Elegant und schlicht, das sind die Vorteile von Pascal, bitte bleiben Sie dabei!
Prinzip: Einfachheit ist schön!
4. Unterfenster
Viele Leute bedienen beim Aufrufen eines Unterfensters direkt die Steuerelemente im Unterfenster, wie zum Beispiel:
wenn SetAlarmParamDlg.ShowModal = MrOK dann
beginnen
AlarmTimes := StrToInt(SetAlarmParamDlg.Edit1.Text);
AlarmArea := SetAlarmParamDlg.SpinEdit1.Value;
Ende;
Oh mein Gott, wenn die Benutzer morgen denken, dass das von Ihnen verwendete Edit oder SpinEdit hässlich aussieht und es durch ein schönes Steuerelement ersetzen, was werden Sie dann tun? Sie müssen nicht nur den Code des Unterfensters ändern, sondern auch den Code des Hauptformulars. Natürlich bereitet Ihnen ein Programm mit einem oder zwei Unterfenstern keine Schmerzen. Was ist, wenn es sich um ein Programm mit mehr als zwanzig Unterfenstern handelt? Es hat einen Tag gedauert, aber der Grund war nur der Austausch einer Steuerung! Warum nicht eine andere Methode ausprobieren? Wenn Sie Attribute verwenden, um die Parameter darzustellen, die Sie verwenden möchten, sparen Sie unzählige Codes.
//Hauptformular
wenn SetAlarmParamDlg.ShowModal = MrOK dann
beginnen
AlarmTimes := SetAlarmParamDlg.AlarmTimes;
AlarmArea := SetAlarmParamDlg.AlarmArea;
Ende;
// Unterformular
Schnittstelle
Privat
FAlarmTimes: Ganzzahl;
FAlarmArea: Ganzzahl;
veröffentlicht
Eigenschaft AlarmTimes: Ganzzahl FAlarmTimes lesen FAlarmTimes schreiben;
Eigenschaft AlarmArea: Ganzzahl FAlarmArea lesen FAlarmArea schreiben;
Durchführung
...
FAlarmTimes := StrToInt(Edit1.Text);
FAlarmArea := SpinEdit1.Value;
ModalResult := MrOK;
...
Solange Sie auf diese Weise beharren, werden Sie große Vorteile feststellen. Ein Unterfenster erledigt nur seine eigene Sache, und die Interaktion zwischen dem Hauptfenster und ihm erfolgt über Attribute. Solange die Schnittstelle unverändert bleibt Unabhängig davon, wie sich das Erscheinungsbild des Unterfensters ändert, wie die Steuerelemente ersetzt werden oder wie der Code geändert wird, bleibt das gesamte Programm gleich, nur die Benutzeroberfläche hat sich geändert.
Prinzip: Modularisieren Sie Ihre Unterfenster. Die Art und Weise, wie Windows kommuniziert, sollte auch zwischen Klassen kommunizieren.