問題タブ [marker-interfaces]

マーカー インターフェイスに実装するものが何もない場合、実装するのは何にSerializable使用されますか?

Stack Overflowで以前に説明したように、マーカーインターフェイス（メンバーのないインターフェイス）よりも属性を優先する必要があります。MSDNのインターフェイスデザインの記事でも、この推奨事項が主張されています。

マーカーインターフェイス（メンバーのないインターフェイス）の使用は避けてください。

カスタム属性は、タイプをマークする方法を提供します。カスタム属性の詳細については、「カスタム属性の記述」を参照してください。コードが実行されるまで属性のチェックを延期できる場合は、カスタム属性が推奨されます。シナリオでコンパイル時のチェックが必要な場合、このガイドラインに準拠することはできません。

この推奨事項を適用するためのFxCopルールもあります。

空のインターフェースは避けてください

インターフェイスは、動作または使用契約を提供するメンバーを定義します。インターフェイスによって記述された機能は、継承階層のどこにタイプが表示されているかに関係なく、どのタイプでも採用できます。タイプは、インターフェースのメンバーに実装を提供することによってインターフェースを実装します。空のインターフェースはメンバーを定義しないため、実装可能なコントラクトを定義しません。

タイプに実装が期待される空のインターフェイスがデザインに含まれている場合は、インターフェイスをマーカーとして使用しているか、タイプのグループを識別する方法を使用している可能性があります。この識別が実行時に発生する場合、これを実現する正しい方法は、カスタム属性を使用することです。属性の有無、または属性のプロパティを使用して、ターゲットタイプを識別します。コンパイル時に識別を行う必要がある場合は、空のインターフェイスを使用できます。

この記事では、警告を無視する可能性がある理由を1つだけ述べています。それは、型のコンパイル時の識別が必要な場合です。（これは、インターフェイスデザインの記事と一致しています）。

コンパイル時にインターフェイスを使用してタイプのセットを識別する場合は、このルールから警告を除外しても安全です。

実際の質問があります。Microsoftは、フレームワーククラスライブラリの設計における独自の推奨事項に準拠していませんでした（少なくともいくつかのケースでは）：IRequiresSessionStateインターフェイスとIReadOnlySessionStateインターフェイス。これらのインターフェイスは、ASP.NET Frameworkによって使用され、特定のハンドラーのセッション状態を有効にする必要があるかどうかを確認します。明らかに、コンパイル時の型の識別には使用されません。なぜ彼らはそれをしなかったのですか？私は2つの潜在的な理由を考えることができます：

1. マイクロ最適化：オブジェクトがインターフェースを実装しているかどうかのチェック（obj is IReadOnlySessionState）は、リフレクションを使用して属性（type.IsDefined(typeof(SessionStateAttribute), true)）をチェックするよりも高速です。ほとんどの場合、この違いはごくわずかですが、ASP.NETランタイムのパフォーマンスが重要なコードパスでは実際に問題になる可能性があります。ただし、各ハンドラータイプの結果をキャッシュするなど、回避策があります。興味深いのは、ASMX Webサービス（同様のパフォーマンス特性の影響を受ける）が実際にこの目的で属性のEnableSessionプロパティを使用することです。WebMethod

2. インターフェイスの実装は、サードパーティの.NET言語による属性で型を装飾するよりもサポートされる可能性が高い可能性があります。ASP.NETは言語に依存しないように設計されており、ASP.NETは、ディレクティブの属性に基づいて前述のインターフェイスを実装する型のコードを生成します（ CodeDomを使用してサードパーティの言語で生成される可能性があります）。属性の代わりにインターフェースを使用する意味があります。EnableSessionState<%@ Page %>

属性の代わりにマーカーインターフェイスを使用する説得力のある理由は何ですか？

これは単に（時期尚早？）最適化ですか、それともフレームワーク設計の小さな間違いですか？（彼らは反射が「赤い目を持つ大きな怪物」だと思いますか？）考え？

私は定期的に次の問題に直面しているのを目にします。ある種のマーカーインターフェイス（簡単にするために使用しましょうjava.io.Serializable）といくつかのラッパー（アダプター、デコレーター、プロキシなど）があります。ただし、シリアライズ可能なインスタンスを別のインスタンス（シリアライズ可能ではない）でラップすると、機能が失われます。List実装で実装できるjava.util.RandomAccessでも同じ問題が発生します。それを処理するための優れたOOP方法はありますか？

なぜJavaアノテーションがそれほど多く使用されているのかを知りたいです...たとえばjpaでxml構成を置き換えたことは知っていますが、なぜこの種の構成がまったく使用されるのですか? 次のコードを検討してください。

��て、これを永続化コンテキストに入れようとすると、の永続化メソッドを使用して、インスタンスEntityManagerを永続化しようとすると実行時エラーが発生します(コンパイル エラーが発生する方がよいでしょう) 。NonEnt@Annotations を使用する代わりに、メソッドのないインターフェイスをエンティティに強制的に実装するという明らかな解決策があります。しかし、これはフレームワーク デザイナーの間では人気がありません。このソリューションの欠点は何ですか?
回答ありがとうございます...

ObjectOutputStream.writeObject(Object o)をとらないのはなぜSerializableですか？なぜそれがかかるのObjectですか？

マーカーインターフェイスの代わりにカスタム属性をコーディングしています

このような辞書をコーディングすることはできませんか？

マーカーインターフェイスを避けて、カスタム属性を使用しようとしています。上記のコードを記述できないのはなぜですか？

たとえばforeachループで、C＃でマーカーインターフェイスをローカルに作成できるかどうか疑問に思っています。

HandleInputメソッドとUpdateメソッドを呼び出す必要のあるゲームコンポーネントがあるとします。メソッドは、対応するインターフェイスIUpdateableとIInputHandlerでそれぞれ定義されています。もちろん、次のような通常のforeachループを実行することもできます。

ただし、反復変数のタイプがIUpdateableとIInputHandlerの両方で構成される一時的なマーカーインターフェイスであることを指定する方法があれば、非常に便利です。

これは可能でしょうか、そしてそれは望ましいでしょうか？個人的にはエレガントだと思います。//ありがとう、フィリップシールド

バックグラウンド

Udi Dahan は、データ アクセスに使用する便利なパターンとしてフェッチ戦略を提案しています。同意します。

概念は、役割を明確にすることです。たとえば、集約ルート - 顧客があります。アプリケーションのいくつかの部分に顧客が必要です。選択する顧客のリスト、顧客の詳細のビュー、および顧客を非アクティブ化するボタンが必要です。

Udi は、これらの役割ごとにインターフェイスを提案するようです。そのため、購入した最新の 10 個の製品を含むICustomerInList非常に基本的な詳細と、顧客を非アクティブ化する方法があります。各インターフェイスは、それぞれの状況でジョブを完了するのに十分な数の Customer Aggregate Root を公開します。My Customer Aggregate Root は、これらすべてのインターフェースを実装しています。ICustomerDetailIDeactivateCustomer

ここで、これらのロールごとにフェッチ戦略を実装したいと考えています。各戦略は、必要な情報のみを公開するインターフェースの背後にあるため、集計ルートに異なる量のデータをロードできます。

この部分を実装する一般的な方法は、Service Locator または他のスタイルの依存性注入を要求することです。このコードは、たとえば、必要なインターフェイスをICustomerInList取得し、それをロードするためのフェッチ戦略を見つけます ( IStrategyForFetching<ICustomerInList>)。この戦略は、ICustomerInList インターフェイスに必要な情報を含む Customer のみをロードすることを認識しているクラスによって実装されます。

ここまでは順調ですね。

質問

Service Locator またはIStrategyForFetching<ICustomerInList>. 私が目にするすべての例は、既知の ID で 1 つのオブジェクトのみを選択しています。このケースは簡単です。呼び出し元のコードはこの ID を渡し、特定のインターフェイスを取得します。

検索したい場合は？それとも、顧客リストの 2 ページ目が必要ですか? ここで、Fetching Strategy が必要とするより多くの用語を渡したいと思います。

可能な解決策

私が見たいくつかの例では、述語 (特定の集約ルートが結果セットの一部である必要がある場合に true または false を返す式) を使用しています。これは条件には問題なく機能しますが、最初の n 人の顧客だけを取得する場合はどうでしょうか? または、検索結果の 2 ページ目を取得しますか? または、結果はどのようにソートされますか?

私の最初の反応は、汎用パラメーターを myIStrategyForFetching<ICustomerInList>に追加し始めることIStrategyForFetching<TAggregateRoot, TStrategyForSelecting, TStrategyForOrdering>です。これはすぐに複雑で見苦しくなります。リポジトリが異なると、さらに複雑になります。特定の選択方法を使用する場合にのみデータを提供するリポジトリもあれば、特定のタイプの順序付けのみを提供するリポジトリもあります。特定の方法でソートされた集約ルートのみを返す特殊なリポジトリとともに、ソート機能を使用できる一般的なリポジトリを柔軟に実装したいと考えています。

最初に使用したのと同じパターンを適用する必要があるように思えます - How do I make roles explicit? ペイロード Y (検索/順序付けパラメーター) を使用して X (集約ルート) を取得するための戦略を実装する必要がありますか?

編集 (2012-03-05)

毎回集約ルートを返さない場合でも、これはすべて有効です。各インターフェイスが異なる DTO によって実装されている場合でも、IStrategyForFetching を使用できます。これが、このパターンが強力である理由です。何を取得し、何を返すかを集約ルートにマップする必要はまったくありません。

使ってしまいましたIStrategyForFetching<TEntity, TSpecification>。TEntity は私が取得したいものであり、TSpecification は取得したい方法です。

私は現在、c＃でマーカーインターフェイスを実装しようとしています。しかし、私はこれまでこれを行っていないので、アドバイスをお願いしたいと思います。

私の問題を簡単に説明します。
私はインターフェイスファクトリを持っていますが、ファクトリにはいくつかのサブインターフェイスが含まれています。これらのサブインターフェイスにはプロパティやメソッドなどがないため、マーカーインターフェイスにする必要があります。したがって、マーカーインターフェイスはインターフェイスファクトリを実装する必要があります。そして、私のマーカーインターフェイスは、たとえば、Cars、Trucksなどです。マーカーインターフェイスは、Cars for MyBMW、MyAUDIなどに実装されています。このようなパターンを実装するにはどうすればよいですか？ありがとう！

いくつかのプロパティを持つクラスがあり、そのうちの1つはオブジェクトになるため、ExtraDataと呼びましょう。これは、3つの異なるタイプのいずれかのオブジェクトであり、3つすべての間に共有フィールドはありません。

3つのオブジェクトクラスすべてが実装するマーカーインターフェイスを作成し、ExtraDataプロパティをそのインターフェイスタイプにする必要がありますか？私が読んだことはすべて、.NETでこれを回避し、可能な限りカスタム属性を使用することを示しています。これを行う場合、ExtraDataを単純なオブジェクトにし、属性をチェックしてそのタイプを判別しますか？このデータを使用し、属性をチェックしてそれに応じてキャストしたい場合、これは多くの余分な作業のように思えます。

これは「マーカーインターフェイスを使用しない」ルールの例外ですか？それとも私は明らかな何かを見逃していますか？

ありがとう。