1. 老人の話
Delphi VS VC はすでに非常に古いトピックですが、それでもここで話したいと思います。これはすべて私の意見です。同意できない場合は笑ってください。
RAD の利点は、インターフェイスの設計に関して言えば、実際には VC よりも優れていることがわかります。 Delphi では、コントロールを見つけてマウスをクリックし、キャプションを変更するだけで、従来とは異なる透明なボタンを作成したいと考えています。もちろん、これを実行するには少なくとも 10 行のコードが必要です。MFC のアプローチにより、人々は Windows の基本原理を理解できるようになりますが、開発者はコードを書く前に基本原理をすべて理解する必要があります。私にとって、そしてほとんどの人にとって、初心者であることは苦痛です。確かに、開発の期限はいつも厳しく、時間が足りないということはありません。プログラマーが Windows プログラミングのあらゆる側面を知っていることを期待することはできません。ビデオに詳しい人やネットワークに長けている人もいますが、万能で優れた人はいません。すべてが非現実的であるため、カプセル化が非常に重要です。新製品を開発するたびに、透明なボタンや美しいインターフェイスに時間の 30% 以上を費やさなければならないとしたら、私は川に飛び込みます:) インターフェイスの点では、Delphi は確かに MFC よりも優れています。もちろん、MFC が美しいインターフェイスを設計できないという意味ではありませんが、時間がかかりすぎて価値がありません。
RAD は本当にメリットがすべてなのでしょうか?どちらでもない。少なくとも初心者にとってはそうではありません。なぜなら、プログラミングとはただマウスを動かしたり、フレームを引っ張ったりするだけだと人々が誤解するからです。最終的には、Delphi はインターフェイスを書くためのものであり、最下層は何もできないと人々が考えることになります。 MFC プログラマは口を揃えて Delphi プログラマについて、「あなたのプログラムは美しいインターフェイスのほかに、他に何ができるの？」と話しているようです。実際、DDK 以外に Delphi で開発できないものは何ですか? Delphi にない API ヘッダー ファイルはどれですか? Borland は変換していませんが、JEDI は変換しています。JEDI が変換していなくても、C ヘッダー ファイルを提供していただければ、JEDI で変換できます。すべての Delphi プログラマにとって必須のドキュメントです。ヘッダー ファイルが変換されたら、あとは書き込みを開始するだけです。MFC でできることは、Delphi でもできます。ビデオ？ネットワーク？ダイレクト?オーディオ？デルフィにできないことは何ですか?
2. サブプロセス
イベントを書くとき、多くの人はコードがどれだけ長くても、実行する処理の量が多くても、イベント内で実行される限り、結果としてそれを頭の中で書き留めるだけです。コードスニペットが長すぎるため、数か月後に改訂するときに始めることができません。では、コードスニペットを分割してみてはいかがでしょうか?人間の注意力には限界があり、100 行を超えるコードを一度に読むとめまいがするでしょう。Delphi の先輩は、すべてのプロセス (ここでのプロセスには PROcedure と関数を含む) は 25 行を超えてはいけないと教えてくれました。このコードの長さでは頭が混乱するほどではないため、プロセスが何をしているのかを簡単に理解できます。
では、もともとイベントで行われていたものをどのように分解するのでしょうか?多くの方法がありますが、私の経験ではモジュール式です。たとえば、イベント内で実行する処理が多数ある場合、それらは異なるサブプロセスに変換され、その後メインプロセスで呼び出されます。メインプロセスのほとんどはいくつかの判断とループになります。特定の実装プロセスはありません。これにより多くのコード スニペットが作成されますが、集中力は維持されます。
原則: プロセスは 1 つのことだけを実行し、それを適切に実行します。
参考: VCL ソース コード。 VCL ソース コードを見ると、コードが 25 行を超えることはほとんどありません。
3. パラメータ名
初めて SDK を学んだとき、ハンガリー語の表記を見たときにめまいを感じたのを覚えています。多すぎます。思い出せない！だから私はあの発明家が大嫌いです:) ついにデルフィが現れ、足かせの中で踊る日々は終わりました! Delphi では、strDoSometing のような変数名を持つ文字列を定義するのはばかげており、不要です。プロシージャが短く、グローバル変数が表示されない限り、そのような接頭辞は必要ありません。例えば：
プロシージャサブプロ;
変数
i : バイト;
幅、高さ: 整数;
始める
幅 := GetWidth;
高さ := GetHeight;
for i:=0 ～ 9 を実行します
始める
DrawThread := TDrawThread.Create;
DrawThread.Width := 幅;
DrawThread.Height := 高さ;
DrawThread.Start;
終わり;
終わり;
このようなコードセグメントにはコメントがなくても、何をしようとしているのかが簡単にわかると思います。したがって、すべてのプレフィックスとアンダースコアを削除してください。Delphi プログラムではこれらは必要ありません。パラメータ名には動詞と名詞のみが必要です。冗長なものは必要ありません。Pascal の利点は、コードが天国から読み取っているように見えることです。 . 頭の中で考えていることは、コードがどのように見えるかです。エレガントかつシンプル、これらが Pascal の利点です。必ず守ってください。
原則: シンプルさは美しい!
4. サブウィンドウ
多くの人は、次のようなサブ ウィンドウを呼び出すときに、サブ ウィンドウ内のコントロールを直接操作します。
SetAlarmParamDlg.ShowModal = MrOK の場合、
始める
アラームタイム := StrToInt(SetAlarmParamDlg.Edit1.Text);
アラームエリア := SetAlarmParamDlg.SpinEdit1.Value;
終わり;
なんと、もし明日、ユーザーがあなたが使っている Edit や SpinEdit が醜いと思って、それを美しいコントロールに置き換えたら、あなたはどうしますか?サブウィンドウのコードを変更するだけでなく、メインフォームのコードも変更する必要があります。もちろん、1 つまたは 2 つのサブウィンドウを持つプログラムでは問題はありませんが、20 を超えるサブウィンドウを持つプログラムの場合はどうでしょうか。 1日かかりましたが、その理由はコントロールを変更しただけです。別の方法を試してみてはいかがでしょうか?使用するパラメータを表すために属性を使用すると、数え切れないほどのコードを節約できます。
//メインフォーム
SetAlarmParamDlg.ShowModal = MrOK の場合、
始める
アラームタイム := SetAlarmParamDlg.AlarmTimes;
アラームエリア := SetAlarmParamDlg.AlarmArea;
終わり;
// サブフォーム
インタフェース
プライベート
FAlarmTimes : 整数;
FAlarmArea : 整数;
出版された
property AlarmTimes : 整数読み取り FAlarmTimes 書き込み FAlarmTimes;
property AlarmArea : 整数 読み取り FAlarmArea 書き込み FAlarmArea;
実装
...
FAlarmTimes := StrToInt(Edit1.Text);
FAlarmArea := SpinEdit1.Value;
ModalResult := MrOK;
...
この方法を続ける限り、サブウィンドウは独自の処理のみを実行し、インターフェイスが変更されない限り、メイン ウィンドウとサブウィンドウ間の対話は属性を通じて行われます。サブウィンドウはメイン ウィンドウに影響を与えません。サブウィンドウの外観がどのように変更されたり、コントロールがどのように置き換えられたり、コードがどのように変更されたりしても、プログラム全体は同じままであり、インターフェイスのみが変更されます。
原則: サブウィンドウもモジュール化します。クラス間の通信方法は、ウィンドウの通信方法と同じである必要があります。