2009-07-23 10 views
2

私は過去3年間、趣味/職業レベルでDelphiを学習してきました。私は恐怖と恥ずかしさで私の初期のコードを振り返ることができるようになりました。だから私は今、私の初期のアプリをいくつか見直し、それらをリファクタリングしています。GUI情報隠蔽のためのDelphiでのフレームの使用

私が逃げようとしている悪い習慣の1つは、別のユニットから1つのフォームのコンポーネントにアクセスすることです。これを実行するために、私は情報隠蔽の方法としてフレームを使用することを実験してきました。だからではなく、その上のコンポーネントでフォームを持つ、私はその後、登録

type 
    TMyForm = class(TForm) 
    private 
    MyFrame: TMyFrame; 
    procedure SetTimeDate(const Value: TMyItem); 
    function ReadTimeDate:TMyItem ; 

を、すべてのフォーム要素を保持するためのフレームを作成し、フォームにフレームを配置し、プライベートな宣言の中にフレームの宣言を移動していますフォームの初期化部

initialization 
begin 
RegisterClasses([TMyFrame]) 

でフレームがIは、次いで、Iフレーム及びその構成要素へのアクセスを有する形部のパブリックセクションで必要なプロパティを宣言しています。

public 
    property TimeDate: TOverlayItem read ReadTimeDate write SetTimeDate; 

私はフレームを使用して、頻繁に繰り返されるコンポーネントグループを統合しています。

これは私が望む目的(Myframeとそのコンポーネントを隠している)で動作するようですが、他の誰かがこのメソッドの経験がありますか?

フレームを使用する際に欠点はありますか? 私は実際にこれを行うことからどんな利益を得ていますか? フレーム内でネストされたフレームを使用する際に問題はありますか? Delphiでフレームを使用するための練習ガイドはありますか? DelphiでGUI情報が隠れているのと同じ効果を得る方法が改善されていますか?

HMcG

+0

RegisterClasses([TMyFrame])は何のために必要ですか? –

+0

私は移動しているので、 MyFrame:TMyFrame; をプライベートセクションに追加すると、TMyframeを登録しないと 'TMyFrame not found'が発生するという例外が発生します。 – HMcG

+0

デザインではカップリングを減らす方法に焦点を合わせる必要があります。そのため、最終的にフレームを使用しているかどうかは関係ありません。私は次の記事を非常に参考にしていることが分かりました:http://www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf – mghie

答えて

3

あなたのUIレイヤにまだ多くのロジックがあるようです。フォーム/パネルにはそのような多くのValueプロパティがあるべきではありません(ダイアログの場合を除く)。

MVCパターンで読み上げるよりも構造が必要な場合。

これまで述べてきたように、フレームはGUIを整理する良い方法です。すべてと同様に、過度に使用しないでください。

+0

私の初期のアプリケーションはすべてUIレイヤーのすべてのロジックを持っていたという点であなたは間違いありません。だから私は、メインのアプリケーションユニットで使用するためのUI値/プロパティを呼び出すきれいな方法です。私のアプリケーションの大部分はハードウェアとのインターフェースであり、かなり単純な操作をしていますが、特定の設定が多いため、Valueプロパティが多いフォーム(ダイアログ)から離れる方法は不明です。 Head First Design Patternsの本を(ゆっくりと)使っていますので、すぐにMVCに行ってください。私が望んでいたのは、簡単なツールやアプリケーションのためのよりクリーンなRADスタイルでした。 – HMcG

+0

RADはあなたをより良いデザインに導きません。 Formが操作できるSettingsオブジェクトを作成することを検討してください。 –

+0

私は、GUIレイヤのロジックが値を設定したレコードまたはクラスを作成し、そのオブジェクトを本体にアクセスしますか?これは、GUIフォームユニットに多数のプロパティを持つよりも良い方法のように聞こえる。ありがとう。 – HMcG

0

私はフレームが一般に複雑な再利用可能なビットを作成するのが好きです。ほとんどの場合、私はそれらがスクリーンを構築するための本当にきれいな方法かもしれないと思う。しかし、Henk Holtermanに記載されているように、画面とフレームにはUIの機能に関連するロジックだけが含まれ、ビジネスロジックについてはできるだけ無知であるべきです。

ポイントのカップルUIに隠れフレームや情報を再:説明したように

  1. in another question on StackOverflowあなたはイベントハンドラを使用しているとき、あなたのフレームに注意する必要があります。
  2. フレームには依然として多くの公開プロパティがあり、実際にはフォームが相互のビットを不適切に作成する問題を解決しません。たとえあなたがそれをしなくても、コードが許せば、誰かが最終的には、どこではいけないはずのコードを書くでしょう。私は常にグローバルフォーム変数を削除します。Delphiはコードを荒らし、しばしばラッパーオブジェクトを作成したり、UIに制御されたアクセスを提供するインターフェイスを実装したりします。

    ClientViewer := TClientViewer.Create(MyClient); 
    try 
        ClientViewer.Show; 
    finally 
        ClientViewer.Free; 
    end; 
    

    あるいは

    TClientViewer.ShowClient(MyClient); 
    

    :私は、一般的にソートの何かを書くために人々を強制します

    ClientForm := TClientViewForm.Create(Self); 
    try 
        ClientForm.Client := MyClient; 
        ClientForm.ShowModal; 
    finally 
        ClientForm.Free; 
    end; 
    

    :だからではなく、このようなコードを持っていることの

クラスメソッドShowClientに、最初のliに表示されているビットを処理させる刺すこのようにして、呼び出しコードはフォームポインタを受け取ることはなく、ラッパークラスによって特別に提供されていないビットには触れません。

+0

1) - それは私がまだ出くわしたことではありません。 ポイント2)は私がMyFrameをプライベートにしていることです.Frameに関連付けられたMyFormユニットだけがフレームとフレームコンポーネントにアクセスできます。他のどのユニットも(プライベート)MyFrameを見ることはできません。 ラッパークラスメソッドが同じ効果を持つ場合、これはおそらく同じ効果を達成する簡単な方法です。 HMcG – HMcG

関連する問題