タグ付けされた質問 「interfaces」

空のインターフェースは、私が知る限り、一般的に悪い習慣と見なされます-特に属性のようなものが言語によってサポートされている場合。 ただし、他のインターフェイスから継承する場合、そのインターフェイスは「空」と見なされますか？ interface I1 { ... } interface I2 { ... } //unrelated to I1 interface I3 : I1, I2 { // empty body } 実装があることは何もI3実装する必要がありますI1とI2、および継承があること、異なるクラスのオブジェクトI3、その後（下記参照）を交換可能に使用することができるが、それは右呼び出すことですI3 空の？もしそうなら、これをアーキテクチャ化するより良い方法は何でしょうか？ // with I3 interface class A : I3 { ... } class B : I3 { ... } class Test { void foo() …

12 interfaces  inheritance 

Java Collections Frameworkを調べてみると、かなりの数のインターフェースにコメントがあることがわかりました(optional operation)。これらのメソッドを使用すると、クラスUnsupportedOperationExceptionを実装したくない場合にクラスを実装できます。 この例は、のaddAllメソッドSet Interfaceです。 さて、この一連の質問で述べられているように、インターフェースは、使用が期待できるものを定義する契約です。 インターフェースは、クラスが行うこととそれを行う方法を分離するため、重要です。クライアントが期待できるものを定義する契約により、開発者は契約を維持する限り、自由に実装できます。 そして インターフェースとは、オブジェクトが実行できるアクションの説明です。たとえば、ライトスイッチをオンにしたとき、ライトが点灯したとき、どのように気にせず、それを行うだけです。オブジェクト指向プログラミングでは、インターフェイスとは、オブジェクトが「X」になるために必要なすべての機能の説明です。 そして インターフェースベースのアプローチはかなり優れていると思います。その後、依存関係をうまくモックアウトできますが、基本的にはすべてがあまり密結合ではありません。 インターフェースのポイントは何ですか？ インターフェイスとは何ですか？ インターフェイス+拡張（mixin）vs基本クラス インターフェースの目的はコントラクトを定義し、依存関係を疎結合にすることであるため、一部のメソッドでUnsupportedOperationException目的を達成できない場合がありますか？それは私がもう渡されSetずに使うことができないことを意味しますaddAll。むしろ、どの実装Setが渡されたかを知る必要があるためaddAll、使用できるかどうかを知ることができます。それは私にはかなり価値がないようです。 それで、何のポイントUnsupportedOperationExceptionですか？従来のコードを補うだけで、インターフェースをクリーンアップする必要がありますか？それとも、私が見逃しているより感覚的な目的がありますか？

12 java  interfaces  methods 

例えば： 私はクラスを持っていると言いますA、B、C。私は2つのインタフェースを持って、それらを呼び出すことができますIAnimalし、IDog。IDogから継承しIAnimalます。Aand BはIDogsで、while Cはそうではありませんが、IAnimalです。 重要な部分は、IDog追加機能を提供しないことです。特定のメソッドへの引数として渡されることを許可するためだけに使用されますがA、BではありませんC。 これは悪い習慣ですか？

12 object-oriented  interfaces 

たとえば、Microsoftの.Net System.Randomクラスとまったく同じ目的とメソッドシグネチャを持つRandomというクラスを記述すると、著作権侵害になりますか？どの言語で書かれているかで違いはありますか？この場合、ActionScriptで使用するRandomクラスを作成します。これには、組み込みのシードされたPRNGクラスがありません。 誰もがソフトウェアのどの側面が保護されているかを理解するための良いリンクまたは参照提案を持っている場合、それも素晴らしいです。そして、はい、これは「本当の」法的助言の場所ではないことを知っています。公の掲示板を優越として指し示すために誰かが法廷に行く場合-彼らへの恥。

12 interfaces  copyright 

私は「依存性注入の原則、実践、およびパターン」という本を読んでおり、この本で十分に説明されているリークのある抽象化の概念について読んでいます。 最近では、依存関係の注入を使用してC＃コードベースをリファクタリングし、非同期呼び出しをブロックの代わりに使用しています。そうすることで、コードベースの抽象化を表し、非同期呼び出しを使用できるように再設計する必要があるいくつかのインターフェイスを検討しています。 例として、アプリケーションユーザーのリポジトリを表す次のインターフェースについて考えてみます。 public interface IUserRepository { Task<IEnumerable<User>> GetAllAsync(); } 本の定義によれば、リークの多い抽象化は特定の実装を念頭に置いて設計された抽象化であり、一部の実装は抽象化自体を通じて「リーク」します。 私の質問は次のとおりです。IUserRepositoryなどの非同期を念頭に置いて設計されたインターフェイスを、漏れやすい抽象化の例として検討できますか？ もちろん、可能なすべての実装が非同期と関係があるわけではありません。アウトプロセス実装（SQL実装など）だけが必要ですが、インメモリリポジトリは非同期を必要としません（実際にインメモリバージョンのインターフェイスを実装する方がおそらくインターフェースが非同期メソッドを公開している場合は困難です。たとえば、メソッドの実装でTask.CompletedTaskまたはTask.FromResult（users）のようなものを返す必要がある場合があります。 あれについてどう思う ？

12 c#  object-oriented  api-design  interfaces  dependency-injection 

パーサーを作成しているとしましょう。1つの実装は次のようになります。 public sealed class Parser1 { public string Parse(string text) { ... } } または、代わりにテキストをコンストラクタに渡すこともできます。 public sealed class Parser2 { public Parser2(string text) { this.text = text; } public string Parse() { ... } } どちらの場合も使用法は簡単ですが、他のものと比較して、へのパラメーター入力を有効にするとはどういう意味Parser1ですか？他のプログラマーがAPIを見たときに、どのメッセージを送信しましたか？また、特定の場合に技術的な利点/欠点はありますか？ 2番目の実装ではインターフェイスがまったく意味がないことに気づくと、別の質問が出てきます。 public interface IParser { string Parse(); } ...最初のインターフェイスが少なくともいくつかの目的に役立つ場合。これは特に、クラスが「インターフェース可能」かどうかを示していますか？

12 object-oriented  interfaces  methods  construction 

契約は同一なので、これはJava SEとAndroidの両方に適用されます。 Java SEのCharSequenceドキュメント Android用CharSequenceドキュメント CharSequencecontains(CharSequence)メソッドを定義しません。私は理由を見つけることができないようで、それを含めることは非常に有用でありCharSequence#toString()、文字のシーケンスをチェックするために呼び出す必要を防ぎます。 例えば、Androidの中で、ユーザーが呼び出すことを余儀なくされているEditable#toString()にもかかわらず、それは文字の配列を含むかどうかを確認するためにEditable実装しCharSequenceた場合に回避することができ、CharSequence定義されましたcontains(CharSequence)。 この設計選択の背後にある考え方は何ですか？それは潜在的な見落としですか、またはこれには設計上の理由がありますか？

11 java  design  interfaces  android 

私はいくつかのコードのリファクタリングに取り組んできましたが、ウサギの穴を降りる最初の一歩を踏み出したのではないかと思います。私はJavaで例を書いていますが、それは不可知論的であると思われます。 次のようにFoo定義されたインターフェイスがあります public interface Foo { int getX(); int getY(); int getZ(); } そして、実装として public final class DefaultFoo implements Foo { public DefaultFoo(int x, int y, int z) { this.x = x; this.y = y; this.z = z; } public int getX() { return x; } public int getY() { …

11 java  design-patterns  interfaces  inheritance 

「バー/クラブ」（あなたが飲む/社交する場所）を表す2つのオブジェクトがあります。 あるシナリオでは、バーの名前、住所、距離、スローガンが必要です 別のシナリオでは、バー名、住所、ウェブサイトのURL、ロゴが必要です したがって、同じものを表すが異なるフィールドを持つ2つのオブジェクトがあります。 不変オブジェクトを使用するのが好きなので、すべてのフィールドはconstructorから設定されます。 1つのオプションは、2つのコンストラクターを持ち、他のフィールドをヌルにすることです。 class Bar { private final String name; private final Distance distance; private final Url url; public Bar(String name, Distance distance){ this.name = name; this.distance = distance; this.url = null; } public Bar(String name, Url url){ this.name = name; this.distance = null; this.url = url; …

11 java  design-patterns  object-oriented  interfaces  inheritance 

Javaはとを明確に区別classしinterfaceます。（C＃もそうだと思いますが、経験はありません）。ただし、C ++を記述するとき、クラスとインターフェイスの間に言語による強制的な区別はありません。 そのため、Javaには多重継承がないための回避策としてインターフェイスを常に見てきました。このような区別をすることは、C ++ではarbitrary意的で無意味に感じます。 私は常に「最も明白な方法で物事を書く」アプローチを採用する傾向がありました。そのため、C ++でJavaのインターフェースと呼ばれるものがある場合、例えば： class Foo { public: virtual void doStuff() = 0; ~Foo() = 0; }; そして、私Fooはおそらくほとんどの実装者が、おそらく私が書くだろういくつかの一般的な機能を共有したいと決めた。 class Foo { public: virtual void doStuff() = 0; ~Foo() {} protected: // If it needs this to do its thing: int internalHelperThing(int); // Or if it doesn't need the …

11 c++  design  terminology  interfaces 

存在タイプを考える T = ∃X.{op₁:X, op₂:X→boolean} この汎用Javaインターフェース： interface T<X> { X op₁(); boolean op₂(X something); } 存在タイプとJavaインターフェースの基本的な違いは何ですか？ 明らかに、構文上の違いとJavaのオブジェクト指向（隠されたthisパラメーターなどの詳細も含まれます）があります。概念的および意味的な違いほどこれらに興味はありませんが、誰かがより細かい点（Tvs. 間の表記上の違いなどT<X>）を明らかにしたい場合は、それも高く評価されます。

11 java  interfaces  type-systems 

しばらくの間、C＃for WindowsおよびASP.net MVC開発で遊んでいます。しかし、私はまだいくつかの領域で不明です。私は、類似の種類のGeneric Collection Interfacesの使用と交換に関するパフォーマンスの問題の基本的な違いを理解しようとしています。 基本的な違いは何ですかIEnumerable<T>、ICollection<T>、List<T>(Class)？ アプリケーションで問題が発生することなく、それらを使用および交換しているようです。また、これらの3つと交換できるこれらのような類似の汎用コレクションはありますか？

11 c#  generics  interfaces 

私は最近、デザインパターンの調査を開始しましたが、コーディングしていることの1つは、小さな違いを除いて、戦略パターンに完全に適合します。 基本的に、私のアルゴリズムの一部（すべてではない）には、追加のパラメーターまたは2つを渡す必要があります。 だから私はどちらかをする必要があります 計算メソッドを呼び出すときに追加のパラメーターを渡します または それらをConcreteAlgorithmクラス内の変数として保存し、アルゴリズムを呼び出す前にそれらを更新できるようにします。 このニーズに合ったデザインパターンはありますか/戦略パターンにこだわってこれを実装するにはどうすればよいですか？ クライアントオブジェクトをすべてのアルゴリズムに渡し、変数をそこに格納し、特定のアルゴリズムで必要な場合にのみ使用することを検討しました。しかし、これは扱いにくく、戦略パターンのポイントを打ち負かすと思います。 明確にするために、私はJavaで実装しているので、オプションのパラメーター（これをうまく解決できる）の贅沢はありません。

11 java  design-patterns  interfaces  strategy 

C＃の複雑さを研究しているときに、明示的なインターフェイスの実装に関する興味深い一節に出会いました。 While this syntax is quite helpful when you need to resolve name clashes, you can use explicit interface implementation simply to hide more "advanced" members from the object level. の使用を許可するobject.method()か、キャストを要求するかの違いは((Interface)object).method()、経験の浅い目には意地悪な難読化のようです。テキストでは、これによりオブジェクトレベルでIntellisenseからメソッドが非表示になることが示されていますが、名前の競合を回避する必要がないのに、なぜそうする必要があるのでしょうか。

11 c#  design  interfaces 

私はTypescriptでゲームを作成しており、オブジェクトの実装ではなく、インターフェイスに基づいてコードを作成する「インターフェイスベースのプログラミング」のアイデアに固執しようと決心しました。 私は十分な数のインターフェースとそれらを実装するクラスを作成し、一歩下がって、クラスが単純であることを認識しました。実装を変更する必要はおそらくないでしょう。クラスは（Phaser.Spriteタンクのように動作するように制限された方法でを移動します）。 次に、YAGNIのアイデアについて数年前に読んだことを覚えています。これは基本的に、コードを過度に設計して、決して使用しない可能性があるものを含めるべきではないということです。 ベストプラクティスに従って、すべてのクラスがインターフェイスを実装する必要がありますか、それとも将来的にスワップアウトされる可能性があると予想されるクラスに限定する必要がありますか？

10 object-oriented-design  interfaces  patterns-and-practices