1. ビジネス オブジェクトの実装: ビジネス ルールをカプセル化するクラスは、真のオブジェクト指向プログラミングの基礎です。この記事では、プログラミングのあらゆる側面を取り上げ、Delphi プログラムの通常の作成方法についていくつか説明します。これらの設計メソッドの背後にある基本概念はカプセル化です。つまり、プロパティを操作するメソッドを持つ、明確に定義されたインターフェイス (メソッド) を持つクラスのセットを設計します。この概念はプログラム全体を通じて使用され、データの保存方法と表示方法に強い影響を与えます。 C++ に関する Francis Glassborow の記事を読者に紹介したいと思います。言語は異なりますが、優れたクラス設計の概念は言語に依存しません。現在、Delphi で作成されたプログラムのほとんどはオブジェクト指向ではありません。言語にオブジェクト モデルがあり、独自のクラスまたは新しいクラスを使用しているからといって、そのプログラムが真のオブジェクト指向であることを意味するわけではありません。サードパーティのコントロールがウィンドウにドラッグされるとコードの再利用は終了しますが、ウィンドウとユニット間の相互依存関係は急速に増加します。 (!!!) 将来、プログラムの基礎を変更したい場合 (別のデータベースに切り替える、または 2 層構造から 3 層構造に移行するなど)、大きな支障が生じるか、費用がかかることになります。プログラムが本当にオブジェクト指向で記述されている場合、制限的ではなく非常に便利になります。もちろん、そのようなプログラムを作成するにはコンセプトの改善が必要ですが、最初はほとんどの開発チームがこれを実行したり検討したりすることに消極的です。この記事を通じて、より良いプログラムの書き方をご紹介できれば幸いです。その結果、従来の方法で作成されたプログラムよりも信頼性が高く、保守が容易で、スタイルが一貫しており、柔軟性があり、再利用可能で、より良く実行されるシステムが得られます。特に大規模なプログラムの場合、コードが明確で真のオブジェクト指向であるプログラムは、従来の方法で作成された同じプログラムよりも必要なメンテナンス リソースが少なくなります。オブジェクト指向プログラムの信頼性が向上するのは、データと操作が明確に定義されたクラスにカプセル化されているという事実から来ます。コンパイラは、強力な型チェックを通じてコード内の正しいクラス、メソッド、プロパティを強制します。将来の変更がプログラム全体に影響を与える場合でも、コードの意図を誤解する可能性はありません。クラスが正しく使用されていれば、クラス間の関係は一目瞭然であり、コードのほとんどは、データがどのように永続化されるかなどの詳細を考慮するのではなく、プログラムの核心に重点を置いています。コード全体の単純さと一貫性により、プログラムの保守性が大幅に向上します。これから説明するように、クラス継承を広範囲に使用すると、生産性と信頼性が向上し、一貫性が向上します。これらの一貫性は、クラスの動作、データの保存方法、ユーザー インターフェイスでのデータの表示方法など、示されているコードに反映されています。ほとんどの機能は基本クラスで提供されるため、その動作をすばやく変更することでプログラムを根本的に変更することができます。 (たとえば、ユーザー対話インターフェイスがウィンドウ駆動型のフォームから HTML ベースに変更されます) これらの基本クラスはプログラムから独立して設計できるため、2 番目の同様のプログラムの生産性がすぐに向上します。適切な基本クラスのセットは、時間、費用、信頼性の点で、小規模なプログラムに対して最大 50% の大幅な改善をもたらします。最初に強調すべきことは、真のオブジェクト指向開発への切り替えは簡単なことではないということです。初めて、支援を経験しているか、プログラムが小規模で、緊急の納期がないことを確認する必要があります。オブジェクト指向 (OO) の解決策は、プログラム内でどのクラスを使用し、どのクラスを使用しないかを指定することではないことに注意してください。企業が独自のビジュアル コントロールを開発する場合、またはサードパーティのビジュアル コントロールを使用する場合、オブジェクト指向プログラムを設計する最初のステップは、どのクラスが必要かを検討することです。これは絶対に基本的なステップであり、初期段階での間違いを修正するには多額の費用がかかるため、他のさまざまな開発による技術的保証が適用されます。クラスを設計するとき、私たちは通常、低結合と高凝集性を達成するよう努めます。クラスは可能な限り独立していますが、何らかの強力な方法で組み合わせることができます。この目標を達成する 1 つの方法は、プログラム内で果たすさまざまな役割に応じて、クラスをさまざまなカテゴリに分類することです。これらの役割を正しく選択すると、まとまりのあるクラスのセットが得られます。クラスの役割の設計には一貫した基本原則があります。それは、クラスの役割をプレゼンテーション、アプリケーション、およびデータの永続的ストレージ (通常はデータベース) に分割することです。これは 3 層データベース プログラムのパーティショニングと同じですが、このパーティショニングの概念は、シングル チップ プログラムから分散多層プログラムまで、さまざまな環境で実装できることに注意することが重要です。アプリケーション ロジックを構成するクラスのグループは、ユーザー アクションの要求への応答やデータの処理など、最も困難な作業を担当します。この層の一部のクラスは現実世界のエンティティを表し、システムによってモデル化されます。これらのクラスは、多くの場合、「ビジネス クラス」または「問題ドメイン クラス」と呼ばれます。これらはあらゆるオブジェクト指向プログラムの重要な部分を形成しており、他のクラスが何らかの方法でこれらのクラスをサポートするため、すべての開発者の焦点になります。特定のプログラムにどのビジネス オブジェクトが存在するかを識別することは、一般に経験と本能の問題ですが、このプロセスには完全な規律 (または技術?) が必要です。SSADM(1) などの従来の技術に対するオブジェクト指向の利点は存在します。分析、設計、およびエンティティの保守プロセス全体を通じて、各ビジネス オブジェクトは、オブジェクト指向分析 (OOA)、オブジェクト指向設計 (OOD)、およびオブジェクト指向プログラミング (OOP) を通じて表現できます。適切なビジネスターゲットを特定するためのいくつかのテクニックについては後ほど説明します。まず、以下の処理が完了しているものとします。異なる層 (プレゼンテーション、アプリケーション、永続性) 間のクラスの相互通信は明確に定義され、相互接続されています。これらのクラス間の関係を図 1 に示します。図内の矢印は、同じ層のクラスが別のクラスのメソッドを呼び出せることを示しています。この図は、プレゼンテーション層 (ユーザー インターフェイス) のクラスがアプリケーション層またはユーザー インターフェイス内の他のクラスを操作できることも示しています。アプリケーション層 (ビジネス オブジェクト) は、アプリケーション層のクラスを操作し、永続化のメソッドを呼び出すことができます。永続層はアプリケーション層のリクエストにのみ応答します。ビジネス オブジェクト ビジネス オブジェクトがどのように実装されるかを示すために、次に、在庫、顧客、注文エンティティ (企業が一定量の商品を提供し、顧客がこれらの商品を購入する) を含む単純化されたプログラムを見ていきます。私たちの最初の分析では、これらのエンティティを表すには 3 つのビジネス オブジェクトが必要であることが判明しました。 Delphi プログラムには、TStockItem、TCustomer、Torder の 3 つのクラスがあります。これらのクラスのパブリック インターフェイスをリスト 1 に示します。ここで、これらのクラスの特性はプロパティ (PROperty) を通じて外部に公開されることに注意してください。これはシンプルで有益なクラス設計であり、プロパティを通じて外部アクセスを制御します。また、これらのプロパティはクラスの公開領域に存在し (理由は後述します)、適切なデフォルト値が割り当てられている必要があります。これらのプロパティ修飾はクラスをストリーミングする場合にのみ使用されますが、各プロパティに適切な初期値が与えられ、コードがより自己記述的になります。ファーストクラスのフレームワーク プログラム開発の初期段階で、3 つのビジネス オブジェクトを特定して実装しました。これら 3 つのオブジェクトは、何らかの方法で現実世界の実体を表すという共通の役割を果たします。したがって、それらが現実世界の実体と同様の特性と適切なレベルを持つようにしたいと考えています。各オブジェクトに、TPDObject (問題ドメイン オブジェクト) と呼ばれる共通の基本クラスを与えます。時間の経過とともに、パブリック メソッドとプロパティがこのクラスに追加され、TPDObject は拡張され続けます。 TPDObject には、特定のアプリケーションに関連する要素を含めるべきではないことに注意してください。プログラムに依存しないクラスとして、独立したユニットに配置され、フレームワークの基礎、つまり多くのプログラムで再利用できるクラスのセットを形成します。将来的には、私たちのフレームワークは大幅に拡張され、プログラムに依存しない重要な機能を提供し、特定のシステムですぐに使用できる基本クラスを形成する予定です。 TStockItem、TCustomer、および Torder は、TPDObject から特定のシステム用にカスタマイズされたオブジェクトです。 TMyAppPDObject は TPDObject の継承クラスです。その実装部分は空ですが、このように特定の要素を特定のプログラムに追加し、プログラム内のすべての問題ドメイン クラスに影響を与える場合は、クラス階層がより適切になるはずです。フレームワークの初期コードはリストにリストされています。クラス TPDObject は読み取り専用の属性 ID のみを提供し、そのタイプは TobjectID です。この属性は各オブジェクトに識別子を与えます。同じタイプと ID の 2 つのインスタンスは同じオブジェクトであると見なされます。ここでは、ID が別の標準型の値に直接割り当てられることを避けるために、意図的に独自の型として宣言されています。 TobjectID のタイプは特に選択されていません。ここでは整数を選択しました。これは、場合によっては特殊なクラスになる可能性もあります。クラスを ID として使用することは、より純粋なオブジェクト指向のアプローチであるように見えますが、問題領域内のクラスは、作成時の余分な負荷を避けるために、プログラムの実行中に何千回も作成および解放されるという事実に基づいています。オブジェクトを解放するとき、私はこれをしませんでした (純粋主義者として、TPDObject に TobjectID を複合オブジェクトとして含めます)。コードには、文字列をオブジェクト識別タイプに変換する一対の関数と、割り当てが行われていない場合の初期値として機能する定数があります。オブジェクトの識別について言及されている分類は数多くあります。すべてのビジネス オブジェクトには、作成時にプログラム内で繰り返されない識別 (GUID であっても) を付与する必要があると主張するものもあります。実際、特定のコンテキスト内でさまざまなオブジェクトを区別できることが本当に重要であり、これをシンプルに保つことで、パフォーマンスとストレージ スペースに明らかな利点が得られます。仕様に関する質問: クラス フレームワークを設計する際のいくつかの設計概念と実践を強化するために、いくつかの質問をし、その背後にある基本原則について読者に考えてもらいます。真のオブジェクト指向設計では特定のクラスの使用が禁止されていないと述べましたが、重要な例外が 1 つあります。この例外は何ですか (答えは図 1 にあります) ((( リスト 1 - アプリケーション固有の問題ドメイン ユニット (要約) )))unit 問題ドメイン;インターフェイス使用フレームワーク;タイプ TMyAppPDObject = class (TPDObject) end; TMyAppPDObject ) 公開プロパティ名: 文字列; プロパティ QuantityInStock: 基数のデフォルト 0; プロパティ TradePrice: 通貨; プロパティ RetailPrice: 通貨; TCustomer = クラス (TMyAppPDObject) … ; TOrder = クラス (TMyAppPDObject) … ;implementationend.((( リスト 1 終了 )))((( リスト 2 - アプリケーションに依存しないフレームワーク ユニット )))unit Framework;interfaceconst NotAssigned = 0; type TObjectID = タイプ Integer; TPDObject = クラス プライベート FID: TObjectID : TObjectID 読み取り FID デフォルト NotAssigned; end;function StrToID (値: String): TObjectID;function IDToStr (Value: TObjectID): String;implementation…end.((( End Listing 2 )))(1) SSADM (Structured Systems Analysis & Systems Design) は、 1981 英国政府の中央コンピュータ電気通信庁 (CCTA) の Web サイト: http://www.ccta.gov.uk ) ソフトウェア分析および設計の標準手法を開発しました。 Philip Brown は、システム設計コンサルタントであり、積極的な開発者、プレゼンター、トレーナーです。機会があれば、より優れたアプリケーションを提供するための強力な OO テクニックのメリットを推進します。連絡先は [email protected] です。