一般的なDelphiプログラミングでどのようなデザインパターンを実装していますか？

Question

にはどのようなデザインパターンを実装していますか？Delphiプログラミング？どんなパターンがより簡単ですは、Delphiのプログラミングに適応する？あなたは、Delphi 2010分の2009ためデザインパターンのいくつかの変更について言うことができる場合、私は、喜んでいるだろう（すべての言語が異なる分野に優れているので、どのようなパターンは、Delphiを使用するときに非常に強い構造である可能性が高い？）

（これらはジェネリックスをサポートしているので、2010年にはRTTI）。

野生のインターネットには多くの記事がありますが、日々の使いやすさとパターンの変化については説明していません。 （ほとんどの人は、言語の詳細やアーキテクチャの変更について議論するだけです）。

Answer 1

デルファイの開発者はすべて、デルファイの開発者がFactory pattern（delphi.about.comはexample in "regular" Delphiです）を使用していますが、仮想作成コンストラクタを使用して実装されていることはごくわずかです。

ので：

仮想コンストラクタが仮想メソッドのようなクラスにあること:-)上でいくつかの光を当てるための時間は、オブジェクトインスタンスのようなものです。

ファクトリパターンの考え方は、実際の作成から作成するもの（この場合は「オブジェクトインスタンス」）の種類（この場合「クラス」）を決定するロジックを切り離すことです。任意の降順クラスで上書きすることができ

TComponentのはとてもvirtual Create constructorがあり、：：例えば

type 
    TComponent = class(TPersistent, ...) 
    constructor Create(AOwner: TComponent); virtual; 
    ... 
    end; 

TDirectoryListBox.Create constructor上書きそれ：

type 
    TDirectoryListBox = class(...) 
    constructor Create(AOwner: TComponent); override; 
    ... 
    end; 

それは仮想作成コンストラクタを使用して、このように動作します

クラス参照（オブジェクトインスタンス参照と同様のクラス）を 'class'型の変数に格納することができますタイプ'。コンポーネントクラスについては、事前に定義されたタイプTComponentClass in the Classes unitがあります：

type 
    TComponentClass = class of TComponent; 

あなたがタイプTComponentClassの変数（またはパラメータ）を持っている場合、あなたは工場出荷時のパターンと非常によく似ている多型の構造、行うことができます。

を

var 
    ClassToCreate: TComponentClass; 

... 

procedure SomeMethodInSomeUnit; 
begin 
    ClassToCreate := TButton; 
end; 

... 

procedure AnotherMethodInAnotherUnit; 
var 
    CreatedComponent: TComponent; 
begin 
    CreatedComponent := ClassToCreate.Create(Application); 
    ... 
end; 

デルファイRTLがここインスタンスのためにこれを使用しています。

Result := TComponentClass(FindClass(ReadStr)).Create(nil); 

、ここで：

// create another instance of this kind of grid 
SubGrid := TCustomDBGrid(TComponentClass(Self.ClassType).Create(Self)); 

DFMファイルから読み込まれているフォーム、データモジュール、フレーム、コンポーネントの作成プロセス全体がどのように機能するかが、Delphi RTLの最初の使用方法です。

フォーム（datamodule/frame/...）クラスは実際に（datamodule/frame/...）のフォームにあるコンポーネントの（公開された）リストを持っています。このリストには、各コンポーネントのインスタンス名とクラス参照が含まれています。コンポーネントのインスタンス名程度

1. 発見、
2. をその後、動的に作成するために、クラス参照を使用しています
3. 、基本となるクラスの参照を見つけるために、その名前を使用しています。そして、DelphiのRTLをDFMファイルを読むこと 正しいオブジェクト

一般的なDelphiの開発者は、通常そのようなことは起こりませんが、それがなければDelphiのRADの経験は存在しません。

Allen Bauer（エンバカデロのチーフサイエンティスト）は、blogarticle about this topicとも書いています。 についてのSOの質問もあります。

私は頻繁に以下のパターンを使用しています

--jeroen

Answer 2

:-)コンストラクタのトピックを作成することは、仮想上十分な光だった場合、私に教えてください：MVC で

1. オブザーバー
2. Singlton
3. テンプレート方法
4. 状態
私は頻繁に以下のパターンを使用し

Answer 3

：

• コマンド
• ビジター
• 表データゲートウェイ
• オブザーバー
• アダプタ
• シングルトン（多くのケア付き！）
• 抽象工場
彼のフォーム
• の全てで
• ファクトリメソッド
• 州
• 依存性注入ファサード
• サービスロケータ
• 別居インタフェース

Answer 4

あなたはGOFパターンの等価性にan excellent article by Marco Cantuを見つけることができますし、デルファイのイディオム。彼のボルコンセッションに出席したことを覚えています。優秀でした。
覚えておくべき主なアイデアは、言語/フレームワークの欠点を補うためにデザインパターンが必要であることです。ネイティブのイディオムがあれば、ホイールを再構成してGOFシバン全体を実装する必要はなく、単にそれを認識して名前を付けるだけです（Jeroenが彼のsuperb explanation on the Factoryで行ったように）。

Answer 5

非OOPプログラミング（構造化プログラミングとも呼ばれます）は、Delphiプログラマにとって非常に一般的です。非常に単純です：何かをする関数を作成し、それはレコード/オブジェクトのようなデータ構造には関係しません。例：IntToStr（）

カプセル化がインターフェイス/実装セクションを使用して提供され、結果として得られるマシンコードが非常に効率的であるため、Delphiはこれを非常にうまく行います。コンパイル時には、インターフェイスセクションに型付き定数があり、プログラムが完全にコンパイルされているなどの最適化もサポートされています。その定数の値を変更すると、ユニットは再コンパイルされず、定数変更。これは毎日の作業では必ずしも必要ではありませんが、Delphiの仕組みの一例です。

Answer 6

通常のUnitはシングルトンのように動作します。継承やポリモフィズムのようなOOPテクニックは使えませんが、それは良いことかもしれません:)

私は、一般的に、Delphiはサウンドのoopデザインを避けるのが簡単すぎると思っています。これはRADにはうってつけですが、コードを整理して保守しやすいようにするには、避けるべき落とし穴を知る必要があります。たとえば、フォームに追加するコンポーネント、TForm1型のグローバルForm1変数（手動で管理されたライフタイムと基本クラスの代わりにタイプ）、GUIとビジネスロジック間の分離がないなど、一般的な可視性があります。ちょうどいくつかの問題について言及する。