問題タブ [sealed]

私は現在MediaElements、作成しているアプリケーションでいくつかを使用しています。それらを動的に作成し、ラップパネルに追加しています。

問題は、それらにキーを追加して、戻って特定のキーを見つけることができるようにする必要があることです。

から継承しMediaElement、キーをメンバーとして追加するだけでした。残念ながら、これは封印されたクラスであるため、これを行うことはできません。

そこで、とキーを含むクラスを作成しようとしましたMediaElementが、がではないため、GUIに追加できませんUIElement。

とにかく私はこれを行うことができますか？追加できるようにする必要がありMediaElementsます。後で戻って見つけて、変更または削除できるようにする必要があります。

重複の可能性：
最終および封印の目的

こんにちは、みんな、

封印されたクラスの設計をいつ選択する必要がありますか？

シングルトンクラスの設計をいつ選択する必要がありますか？

封印された特性と値を表すケース オブジェクトを使用した一種の列挙があるとすれば、暗黙の引数を必要とせずに、特定の型の単一の一意の値を取得するメカニズムを強制することは可能ですか?

暗黙の場合、これは次のようになります

テストする暗黙の引数を削除することは可能ですか? つまり、V が Enum の定義済みサブタイプであることを確認します (明らかに、test[Enum] は失敗するはずです)。ゴルディアンノットは次のとおりです。

?

TDDを始めたばかりで、このレンガの壁にぶつかるまではすべて順調でした。

サードパーティのAPIを中心にファサードを書いています。APIは、すべてがインターフェイスを介してアクセスされるという点で非常に優れているため、ファサードをテストするときに簡単にモックできます。

API全体はルートインターフェースを介してアクセスされ、ここからドリルダウンできるインターフェースの深い階層があります。私のファサードは、標準のIoCプラクティスでは、コンストラクターでこのルートインターフェイスを使用します。

TDDは順調に進んでいましたが、インターフェイスツリー全体をモックする必要があるため、深いインターフェイスを使用するとモックが少し複雑になるというわずかな苦痛がありました。大したことではありませんが、私はモックを構築するヘルパー関数を維持しました。しかし、私が正しいアプローチを使用しているかどうか疑問に思います。

とにかく、ツリーの途中で、パブリックコンストラクターがない、突然密閉されたコンクリートタイプにぶつかったので、それをあざける方法がありません。これにより、モックされたAPIがこのメンバーに対して常にnullを返すため、テストが失敗します。

これを回避する唯一の方法は、このタイプの独自のインターフェイスを作成し、それにアクセスするための仮想メソッドをファサードに配置することです。ただし、このメソッドを使用して型へのアクセスを強制する方法がないため、これは面倒に思えます。また、忘れがちです。たとえば、次のように使用するのが自然です。

それ以外の：

これを忘れると、テストが失敗します。

私は何か基本的なものが欠けていますか？私が言ったように、私はユニットテストに非常に慣れていません。

ps。私はMoqを使用しています。

私は小さなプロジェクトに取り組んでおり、その問題に遭遇しました。

プロジェクトの出力は、インターフェイスを含むライブラリです。そのインターフェイスを実装し、可能であれば次のように機能を封印したいと思います。

アイデアは、誰もが利用できるインターフェイスを持ち、それを実装する特殊なクラスを持つことです。例外は、誰かがタイプ A の特殊なクラスを作成した場合、メソッドの動作を変更できないようにすることです。

問題は、メソッドがインターフェイスで「仮想」として宣言されていないため、そこに「オーバーライド」キーワードを配置できないことです。また、許可されていないため、インターフェースで「仮想」として宣言することはできません。また、「sealed」で必要になるため、「override」キーワードを削除することはできません。

回避策やブレインストーミングのアイデアは大歓迎ですが、誰かがインターフェイスを含むソリューションを思い付くことができれば、私はそれを学ぶことができて本当にうれしいです!

ありがとう！

編集：この質問は忘れてください！アニが言ったように、C# のデフォルトのメソッドは封印されていることを忘れていました。たまには基本に立ち返ってみるのもいいですね…

次の設計を検討してください。

プロパティが派生クラス (やクラスなど) でオーバーライドされるのを防ぐために、基本クラスのTitleプロパティをシールする方法はありますか?BaseBookBookSuperBook

私の理解では、 List<'T> は実際には封印されていません。いいえ？

また、これは F# インタラクティブ以外では問題なく機能するようです。その正確なコードは私の F# プロジェクトにあり、コンパイラは問題なく処理します。いくつかの C# プロジェクトで同じことが起こっています。コードは、すべての場合で期待どおりに機能します。

通常、静的メソッドを使用して List<'T> を拡張するだけですが (「F# の方法」で実行します)、List.Add を非表示にしても問題なく動作するはずです。

クラスのいくつかのメソッドとプロパティをオーバーライドできないようにし、すべての派生クラスで基本の実装を使用したいと考えています。これを達成する方法は？seal キーワードが機能していないようで、「オーバーライドではないため、メソッドを封印できません」と表示されます。

Visual Studioのコード化されたUIテストを使用しており、生成されたコードに微調整を加えたいと考えています。

コードはとの部分クラスとして生成されるUIMap.csため、1つの解決策は、 inUIMap.Designer.csなどのわずかに異なる名前のメソッドを作成し、ソースが再生成されるたびに上書きされるinの代わりにこれを使用することです。myMethod_persistUIMap.csmyMethodUIMap.Designer.cs

ただし、これは非常に厄介なように思われるので、代わりにでオーバーライドすることをお勧めmyMethodしますUIMap.cs。myMethodこのように、インターフェイスは多くのGumphで複雑になることはなく、コードを呼び出す際のすべてのインスタンスを次のように変更することを覚えておく必要はありません。myMethod_persist

残念ながら、C＃に関しては、私は少し初心者であり、これが可能かどうかさえわかりません。

基本的に私が欲しいのはこれです：

しかし、sealedキーワードとoverrideキーワードは通常、部分クラスではなく、派生サブクラスクラスで使用されることを私は知っています。これは可能ですか？そうでない場合、私の最良の選択肢は何でしょうか？

コマンドはsealedc++0xになりますか、それともそれを使用するのはMSだけですか？