問題タブ [interface]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
oop - インターフェイスと基本クラス
いつインターフェイスを使用し、いつ基本クラスを使用する必要がありますか?
メソッドの基本実装を実際に定義したくない場合は、常にインターフェイスにする必要がありますか?
犬と猫のクラスがある場合。PetBase の代わりに IPet を実装する必要があるのはなぜですか? ISheds または IBarks (IMakesNoise?) のインターフェイスを持つことは理解できます。これらはペットごとに配置できるためですが、一般的な Pet にどちらを使用すればよいかわかりません。
.net - Generic.IList 間の呼び出しのあいまいさを解決する方法.this[] と IList.this[]?
IList<T> と List の両方を拡張するインターフェイスを実装するコレクションがあります。
つまり、2 つのバージョンのインデクサーがあるということです。
一般的な実装を使用したいので、通常どおり実装します。
シリアライゼーションには IList バージョンのみが必要なので、明示的に実装して隠しておきます。
ただし、私の単体テストでは、次の
コンパイラ エラーが発生する
次のメソッドまたはプロパティ間の呼び出しがあいまいです
これには少し驚いています。私は以前にそれをやったと信じており、うまく機能しています。ここで何が欠けていますか?IList<T> と IList を同じインターフェイス内に共存させるにはどうすればよいですか?
Edit IList<T> はIList を実装していないため、シリアル化のために IList を実装する必要があります。回避策には興味がありません。不足しているものを知りたいです。
もう一度編集: インターフェイスから IList を削除して、クラスに移動する必要がありました。インターフェイスを実装するクラスは最終的に Xaml にシリアル化されるため、IDictionary または IList を実装するコレクションが必要になるため、これを行いたくありません...
c# - C# での XMLSerialization
インターフェイスを明示的に実装する単純な型があります。
タイプIMessageHeaderのオブジェクトをシリアライズおよびデシリアライズする方法はありますか??
試してみると、次のエラーが発生しました
「インターフェイス IMessageHeader をシリアル化できません」
c# - 構造体がインターフェースを実装するのは安全ですか?
構造体がC#を介してCLRにインターフェイスを実装するのがいかに悪いかについて何かを読んだことを覚えているようですが、それについては何も見つからないようです。悪いですか?そうすることの意図しない結果はありますか?
c# - C#でジェネリックスを使用して数学ライブラリを作成する
ジェネリックスを使用して、データを格納するために選択された基本タイプに依存しない数学ライブラリを作成するための実行可能な方法はありますか?
つまり、Fractionクラスを作成したいとします。分数は、2つのintまたは2つのdoubleなどで表すことができます。重要なことは、基本的な4つの算術演算が明確に定義されていることです。だから、私は書くことができるようになりたいFraction<int> frac = new Fraction<int>(1,2)ですFraction<double> frac = new Fraction<double>(0.1, 1.0)。
残念ながら、4つの基本操作(+、-、*、/)を表すインターフェイスはありません。誰かがこれを実装するための実行可能で実行可能な方法を見つけましたか?
c# - C# および C++ で実装する必要があるインターフェイスを C++ で定義する
C# で実装する必要がある C++ で定義したインターフェイスがあります。これについて最善の方法は何ですか?インターフェイス定義で COM をまったく使用したくありません。私が今これを解決した方法は、C++ と C# の 2 つのインターフェイス定義を持つことです。次に、C# インターフェイスを COM サーバーとして公開します。これは、C++ で記述され、C# を呼び出すことができる私のアプリケーションでした。C# だけでなく C++ で実装を定義する必要を回避できる方法はありますか?
java - Javaで静的なネストされたインターフェースが使用されるのはなぜですか?
コードベースで静的なネストされたインターフェースを見つけました。
これは今まで見たことがありません。元の開発者は手の届かないところにあります。したがって、私はSOに尋ねなければなりません:
静的インターフェイスの背後にあるセマンティクスは何ですか? ? を削除すると、何が変わりstaticますか? なぜ誰かがこれをするのでしょうか?
wpf - WPFはインターフェイスにデータバインドできませんか?
WPF形式のコントロールをインターフェイスにバインドしようとしていますが、インターフェイスのプロパティが見つからないというランタイムエラーが発生します。
これが私がデータソースとして使用しているクラスです:
XAML(抜粋)は次のとおりです。
背後にあるコードは次のとおりです(ここでも抜粋):
entlibのポリシーインジェクションアプリケーションブロックを介してポリシーインジェクションを使用しているため、データソースとして使用しているクラスはエンティティである必要があることに注意してください。
実行時にこのエラーが発生します:
c# - リフレクションによるインターフェースの実装
C# でリフレクションを介してインターフェイスのすべての実装を取得するにはどうすればよいですか?
c# - Using the same test suite on various implementations of a repository interface
I have been making a little toy web application in C# along the lines of Rob Connery's Asp.net MVC storefront.
I find that I have a repository interface, call it IFooRepository, with methods, say
And I have three implementations of this: ISqlFooRepository, IFileFooRepostory, and IMockFooRepository.
I also have some test cases. What I would like to do, and haven't worked out how to do yet, is to run the same test cases against each of these three implementations, and have a green tick for each test pass on each interface type.
e.g.
I want this test method to be run three times, with some variation in the environment that allows it to get three different kinds of repository. At present I have three cut-and-pasted test classes that differ only in the implementation of the private helper method IFooRepository GetRepository(); Obviously, this is smelly.
However, I cannot just remove duplication by consolidating the cut and pasted methods, since they need to be present, public and marked as test for the test to run.
I am using the Microsoft testing framework, and would prefer to stay with it if I can. But a suggestion of how to do this in, say, MBUnit would also be of some interest.