//<Delphi 5 開発者ガイド> より
1.2 デルフィとは何ですか?
「Delphi の何が優れているのですか?」「なぜ他のプログラミング ツールよりも Delphi を好むのですか?」などの質問がよくあります。長年にわたって、私たちはこのような質問に対して、長い答えと短い答えの 2 つを考え出してきました。端的に言えば、効率性です。 Windows アプリケーションを作成するには、Delphi を使用するのが最も簡単な方法です。もちろん、この答えに満足しない人（上司や将来の顧客）もいます。したがって、Delphi を非常に効果的にする要因の組み合わせを示す詳細な回答を提示する必要があります。ソフトウェア開発ツールの効率を決める要因を以下の5点にまとめます。
• ビジュアル開発環境のパフォーマンス。
• コンパイラの速度とコンパイルされたコードの効率。
• プログラミング言語の機能とその複雑さ。
• データベース構造の柔軟性と拡張性。
• デザインと使用パターンのフレームワーク拡張。
構成、ドキュメント、サードパーティのサポートなど、含めるべき要素は他にもたくさんありますが、これが Delphi を選択した理由を人々に説明する最も正確かつ簡単な方法であることがわかりました。もちろん、上記の 5 つのポイントには主観的な要素も含まれる可能性がありますが、重要なのは、特定のツールを使用して開発を行ったときに、どれだけ効率的に開発できるかということです。図 1-1 に示すように、ツールのさまざまな側面のパフォーマンスが評価および定量化され (1 ～ 5 の間)、図 1-1 の各軸にマークが付けられ、最終的に五角形が得られます。五角形の面積が大きいほど、このツールはより効率的になります。
この方法を使用してどのような答えが得られたかを説明する必要はありません。一度試してみれば、自分でわかります。これらの分野における Delphi のパフォーマンスを詳しく見て、他の Windows 開発ツールと比較してみましょう。
1.2.1 ビジュアル開発環境
ビジュアル開発環境は通常、エディター、デバッガー、フォーム デザイナーの 3 つのコンポーネントに分かれています。最新の RAD (高速アプリケーション開発) ツールと同様に、これら 3 つの部分は連携して動作します。フォーム デザイナーで作業すると、Delphi はフォーム上で操作しているコントロールのコードをバックグラウンドで自動的に生成します。エディターに自分でコードを追加してアプリケーションの動作を定義することもできます。また、同じエディターでブレークポイントと監視ポイントを設定してプログラムをデバッグすることもできます。
一般に、Delphi のエディタは他のツールのエディタと似ていますが、Code Insight テクノロジーにより入力作業が大幅に節約されます。このテクノロジは、Visual Basic のようなタイプ ライブラリではなく、コンパイラ情報に基づいているため、より幅広い用途があります。 Delphi のエディターにも優れた構成オプションが多数ありますが、Visual Studio のエディターには構成の余地がもっとあると思います。バージョン 5 では、Delphi のデバッガ機能がついに Visual Studio のデバッガに追いつき、リモート デバッグ、プロセスの関連付け、DLL およびパッケージのデバッグ、自動ローカル監視、CPU ウィンドウなどの多くの高度な機能が追加されました。 Delphi は、デバッグ中にウィンドウをランダムに配置してドッキングし、この状態をコマンドのデスクトップ設定として保存することもサポートしています。その結果、Delphi の IDE はデバッグ機能を適切にサポートするようになりました。
一部の統合環境 (VB や一部の Java ツールなど) でよく見られるように、非常に完全なデバッガーの利点は、アプリケーションのデバッグ時にコードを変更して動作を変更できることです。残念ながら、この機能はネイティブ コードにコンパイルするときに実装するには複雑すぎるため、Delphi ではサポートされていません。
RAD ツール (Delphi、Visual Basic、C++Builder、PowerBilder など) の場合、フォーム デザイナーは独自の機能です。 VC++ や BC++ などのより古典的な開発環境の一部では、会話型エディタが提供されていますが、フォーム デザイナーは開発プロセスに統合されていません。図 1-1 の効率チャートからわかるように、フォーム デザイナが存在しないと、開発ツールの全体的な効率が低下します。過去数年にわたり、Delphi と Visual Basic はフォーム デザイナの機能を向上させるために激しく競争してきました。それぞれの新しいバージョンには、以前のものよりも優れた機能が備わっています。 Delphi のフォーム デザイナをユニークなものにしているのは、Delphi が真のオブジェクト指向フレームワークに基づいて構築されていることです。こうすることで、基本クラスに加えた変更がすべての派生クラスに反映されます。ここで重要なテクノロジーの 1 つは、視覚的なフォームの継承である VFI (Visual Form Inheritance) です。 VFI テクノロジーを使用すると、現在のプロジェクトまたはオブジェクト ライブラリ内の他のフォームから動的に継承できます。基本フォームが変更されると、派生フォームもすぐに更新されます。この重要な機能については、第 4 章「アプリケーションのフレームワークと設計」で詳しく説明します。
1.2.2 コンパイラの速度とコンパイルされたコードの効率
高速なコンパイラを使用すると、ソース コードを頻繁に変更し、再コンパイル、テスト、再度変更、再コンパイル、再度テスト…という良好な開発サイクルを形成しながら、段階的にソフトウェアを開発できます。コンパイル速度が非常に遅い場合、開発者はコードをバッチで変更し、非効率なループ プロセスに適応するために各コンパイルの前に複数の変更を加える必要があります。実行効率が向上し、実行時間が短縮され、より短いバイナリ コードが生成されることは明らかです。
おそらく、Pascal コンパイラの最も有名な機能はその速度であり、Delphi はこのコンパイラに基づいて構築されています。実際、これは Windows 用の最速の高級言語ネイティブ コード コンパイラーである可能性があります。以前は遅かった C++ コンパイラは、近年大きな進歩を遂げ、特に Visual C++ と C++Builder ではリンクやさまざまなキャッシュ戦略が追加されました。しかし、それでも、C++ コンパイラは Delphi のコンパイラよりも数倍遅いです。
コンパイル速度は実行効率に必ずしも比例しますか?もちろん違います。 Delphi と C++Builder は同じコンパイラ バックエンドを共有しているため、生成されるコードは優れた C++ コンパイラによって生成されるコードと同等です。最新の信頼できる評価基準によれば、Visual C++ は、いくつかの非常に強力な最適化手段のおかげで、コンパイル速度と生成されるコードの長さの点で最も効率的であると多くの場合考えられています。これらの小さな利点は、一般的なアプリケーション開発では気づきにくいですが、複雑な計算コードを作成する場合には効果を発揮する可能性があります。
Visual Basic のコンパイル テクノロジは少し特殊です。開発中、VB は統合された方法で動作し、応答性が非常に優れています。このコンパイラは、Delphi や C++ ツールに比べて速度が遅く、生成される実行可能コードの効率もはるかに低くなります。
Java も興味深い言語です。最新の Java ベースのツール言語 JB uilder と Visual J++ は、コンパイル速度が同等であると主張しています
Delphi に匹敵しますが、Java は統合言語であるため、生成されたコードの実行効率は満足のいくものではありません。 Jave は着実に進歩していますが、その実行速度は、ほとんどの状況において、依然として Delphi や C++ に遠く及びません。
1.2.3 プログラミング言語の機能と複雑さ
言語の機能と複雑さは見る人の好みに左右され、多くの議論の対象となります。ある人にとっては簡単なことでも、ある人にとっては難しいこともあるし、ある人にとっては機能が限定されているものでも、別の人にとっては完璧であることもあります。したがって、以下の点は著者の個人的な経験と理解にのみ基づいています。
アセンブリは基本的に最も強力な言語です。これを使えばほとんど何でもできます。ただし、最も単純なアプリケーションをアセンブリで開発することさえ非常に難しく、何も起こらない可能性があります。それだけでなく、アセンブリ コードの一部をグループ開発環境に長期間保持し続けることは、場合によってはまったく不可能です。コードが人から人へと受け継がれるにつれて、設計のアイデアや意図がますます不明確になり、最終的にはコードが天国からの本のように見えます。その結果、アセンブリは強力ですが、ほとんどすべての開発者にとって複雑すぎるため、アセンブリの評価を非常に低くしました。
C++ も非常に強力な言語です。その潜在的な機能 (プリプロセッサ マクロ、テンプレート、オペレータの読み込みなど) を利用すると、C++ を使用して独自の言語をほぼ設計できます。豊富な機能オプションを適切に使用すれば、簡潔で直感的で保守しやすいコードを開発できます。ただし、問題は、多くの開発者がこれらの機能を乱用しており、簡単に重大なエラーにつながる可能性があることです。実際、良い C++ コードを書くよりも、悪い C++ コードを書く方が簡単です。なぜなら、言語自体が良いデザインの方向に進むわけではないからです。それは開発者次第です。
Object Pascal と Java は、複雑さと機能のバランスをよく理解しているため、私たちに非常に似ていると感じます。これらはすべて、開発者の論理設計を強化するために、使用可能な機能を制限するというアプローチを採用しています。たとえば、どちらも完全にオブジェクト指向であるが悪用されやすい多重継承の概念を回避し、代わりに複数のインターフェイスの機能を実行する単一のクラスを実装します。どちらも、美しくも危険なオペレーターのロードをサポートしていません。どちらも、例外処理、実行時型情報 (RT TI)、自己管理文字列有効期間メモリなどの強力な機能を備えています。同時に、どちらの言語も専任の編集委員会によって書かれたものではなく、その言語について共通の理解を共有する単一組織内の個人またはグループによって作成されています。
Visual Basic はもともと、初心者が簡単に始められ、より早く上達できるようにするために設計されました (そのため、この名前が付けられました)。しかし、VB は言語として、その長所と短所から常に学習する必要があるため、近年ますます複雑になっています。これらの詳細を開発者から隠すために、VB には複雑なプロジェクトを作成するためのウィザードがまだいくつか残されています。
1.2.4 データベース構造の柔軟性と拡張性
Borland にはデータベース スキームがないため、Delphi はすべてのツールの中で最も柔軟であると考えられるデータベース構造を維持しています。 BDE は、ローカル、クライアント/サーバー、および ODBC データベース プラットフォームに基づくほとんどのアプリケーションに対して非常に強力です。これに満足できない場合は、BDE の使用を避け、新しいネイティブ ADO コンポーネントを使用することができます。 ADO がインストールされていない場合は、独自のデータ アクセス クラスを作成するか、サードパーティのデータ アクセス ソリューションを購入できます。さらに、MIDAS により、データ ソースへの多層アクセスの実装が容易になります。 Microsoft のツール (ODBC、OLE DB など) は、論理的に Microsoft 独自のデータベースおよびデータ アクセス ソリューションをサポートする傾向があります。
1.2.5 設計および使用パターンに対するフレームワークの拡張
これは、他のソフトウェア設計ツールでは見落とされがちな重要な機能です。 VCL は Delphi の最も重要なコンポーネントです。設計時にコンポーネントを操作し、コンポーネントを作成し、OO (オブジェクト指向) テクノロジを使用して他のコンポーネントの動作を継承する機能は、Delphi の効率を決定する重要な要素です。多くの場合、VCL コンポーネントは固定の OO 設計アプローチを使用して作成されます。比較すると、他のコンポーネントベースのフレームワークは、多くの場合、厳格すぎるか、複雑すぎることがよくあります。たとえば、Active X コントロールは VCL コントロールと同じデザイン時機能を備えていますが、異なる動作を持つ新しいクラスを作成するために継承することはできません。 OWL や MFC などの従来のクラス フレームワークでは、内部構造について多くの知識が必要であり、RAD ツールによる設計時のサポートがなければ、その機能は抑制されます。将来的に VCL の機能に匹敵する可能性があるツールは、Windows Foundation Class である Visual J++ の WFC (Windows Foundation Classes) です。しかし、Java の問題をめぐる Sun Microsystems の訴訟はまだ係争中であり、Visual J++ の将来は不透明です。