私のカスタムコントロールのクラス継承を設計する

Question

私はいくつかの異なるカスタムコントロールを作成しています。それぞれ異なるコントロールを実装していますが、共通のプロパティと機能が追加されています。だから私はそれらの共通のプロパティ（一般的なgetterとsetterで）とその機能の複製を抽象クラスに配置したいと思っていました。しかし、私は、私の抽象クラスと私が上に構築しているベースのWebコントロールの両方の実装を許可するコントロールとその基盤を構築する方法の周りに私の頭を包んで苦労している。誰か助けてくれますか？

コントロールのいくつかを、私は私の抽象クラス

public abstract class AssetDataInputControlBase<T> : Control, 
    IAssetDataInputControl<T> 
{ 
    protected virtual int AssetId 
    { 
     get 
     { 
      object o = ViewState["AssetId"]; 
      return o == null ? 0 : (int)o; 
     } 
     set { ViewState["AssetId"] = value; } 
    } 

    protected virtual AssetStructureField StructureField 
    { 
     get 
     { 
      object o = ViewState["StructureField"]; 
      return o == null ? null : (AssetStructureField)o; 
     } 
     set { ViewState["StructureField"] = value; } 
    } 

    public abstract T DataField { get; set; } 
} 

Answer 1

約abstractを忘れました。 .NET Webコントロールの継承は、貧弱な「最終製品」コントロールに多くの実装を強制するのではなく、機能を階層化していると私には思えます。私はこの流れについて行くことができるかどうか分かります。そして、これは、適切なクラスから継承して、ビルドするベース（意図しない）を得ることを意味します。

複合ウェブコントロールを構築したいようです。 を慎重に読んで、System.Web.UI名前空間の文書を読んでください。 System.Web.UI.CompositeControlから継承することを検討してください。これは、子コントロールコレクションといくつかの組み込みレンダリングを提供します。また、子コントロールの一意のIDを管理するためにINamingContainerを実装しています。

ちょっと考えて、実行時にカスタムコンポジットを構築するクラスを作ることができます（factory patternと言うことができますか？）。 慎重にお読みくださいSystem.Web.UI名前空間のドキュメントとにかく、ベースはすでにコンポジットのレンダリング方法を知っています。各サブコントロール（テキストボックス、リストボックスなど）は、自身をレンダリングする方法を知っています。工場では、各サブコントロールにデータバインディングが与えられています。次に、それらをカスタムCompositeControlコンストラクタに挿入します。

Answer 2

1つの提案を

public class AssetDataStringControl : TextBox 
public class AssetDataIntegerControl : TextBox 
public class AssetDataUrlControl : CompositeControl 
public class AssetDataListBoxControl : ListBox 
public class AssetDataDropDownControl : DropDownList 

を構築しています：AssetDataInputControlBaseにキャンバスを作成し、あなたはそれの内側にしたい任意のコントロールを配置します。キャンバスなので、コントロールのように振る舞います。必要なControl固有のメソッド/プロパティは、Controlメソッドを呼び出すメソッドをADICBに追加する必要があります。もしそれらがたくさんあるなら、このアイデアはあまり良くありません。

もう1つの提案：あなたのコントロールは、AssetDataInputControlBaseのようなものを返すメソッドを持つインターフェイスを実装できます。この場合、ADICBはControlなどを実装しません。代わりに、AssetID、AssetStructureField、およびDataField（および必要に応じてその他のもの）があります。したがって、コントロール（AssetDataStringControlなど）はコントロール（TextBoxなど）を拡張するだけでなく、ADICBオブジェクトへの参照も含みます。

これは、ADICBの値がControl（TextBox）とは無関係であることを前提としています。 StructureFieldのgetメソッドがTextBoxからのあらゆる種類の情報を必要とし、異なる方法で取得する必要がある場合は、代わりにListBoxがあれば、すべてが絡み合い、より良い解決策が必要になります。 がではない場合、コントロールはTextBox、ListBoxなどのエクステンションにすぎず、ADICBオブジェクトへの参照が1つ追加されています。一度書かれた複雑なADICBクラスは、すべてのコントロールで使用できます。

これは、複数の継承のための良い引数のように見えます。