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

「M」と言うモジュールがあり、「C1」、「C2」、「C3」と言うクライアントがいくつかあります。モジュールMの名前空間、つまり、それが公開するAPIとデータの宣言を、次のような方法でヘッダーファイルに割り当てます。 どのクライアントでも、必要なデータとAPIのみが表示されます。モジュールの残りの名前空間はクライアントから隠されています。つまり、インターフェース分離の原則に準拠しています。 宣言は複数のヘッダーファイルで繰り返されません。つまり、DRYに違反しません。 モジュールMは、クライアントに依存しません。 クライアントは、モジュールMで使用されていない部分で行われた変更の影響を受けません。 既存のクライアントは、追加のクライアント（または削除）の影響を受けません。 現在、クライアントの要件に応じてモジュールの名前空間を分割することでこれに対処しています。たとえば、下の画像では、3つのクライアントに必要なモジュールの名前空間のさまざまな部分が示されています。クライアントの要件は重複しています。モジュールの名前空間は、「a」、「1」、「2」、「3」の 4つの独立したヘッダーファイルに分割されます。 ただし、これは前述の要件の一部、つまりR3およびR5に違反します。このパーティション化はクライアントの性質に依存するため、要件3に違反しています。また、新規クライアントの追加のモジュールの名前空間は、現在7つのヘッダファイルに分割して、新しいクライアントの追加と同様に、上記の画像の右側に見ることができ、このパーティションの変更および要件5.に違反し、 - 「 '、' b '、' c '、' 1 '、' 2 * '、' 3 * 'および' 4 '。ヘッダーファイルは2つの古いクライアントの変更を意味し、それにより再構築がトリガーされます。 Cのインターフェイス分離を非自発的な方法で実現する方法はありますか？ はいの場合、上記の例をどのように扱いますか？ 私が想像する非現実的な仮想ソリューションは次のようになります- モジュールには、名前空間全体をカバーする1つの太いヘッダーファイルがあります。このヘッダーファイルは、ウィキペディアページのようなアドレス可能なセクションとサブセクションに分かれています。各クライアントには、特定のヘッダーファイルが用意されています。クライアント固有のヘッダーファイルは、ファットヘッダーファイルのセクション/サブセクションへのハイパーリンクの単なるリストです。また、ビルドシステムは、モジュールのヘッダーでポイントするセクションのいずれかが変更された場合、クライアント固有のヘッダーファイルを「変更された」ものとして認識する必要があります。

15 c  interfaces  solid 

Java 8以降、defaultメソッドがインターフェイスに導入されました。事実上、これはのすべてのメソッドがであるとinterfaceは限らないことを意味しますabstract。 Java 9（おそらく）以降、privateメソッドは許可されます。これは、のすべてのメソッドがであるとinterfaceは限らないことを意味しますpublic abstract。 「Javaインターフェイスのメソッドは、publicアクセス修飾子を付けて、または付けずに宣言する必要がありますか？」という質問 スタックオーバーフローで/programming/161633/should-methods-in-a-java-interface-be-declared-with-or-without-a-public-access-mで尋ねられました そこでは、ほとんどの回答はpublic abstract使用すべきではないと主張しました。なぜなら、のメソッドはinterface以外のものではないからですpublic abstract。もはやそうではありません。 インターフェースのこれらの新しい機能をpublic abstract考慮して、Javaインターフェースメソッドの宣言でキーワードを使用する必要がありますか？ 私の特定の環境では、経験豊富なソフトウェアエンジニアがJavaを経験していない人がいて、Javaコードを時々読んでいます。public abstractキーワードを省略すると、インターフェースがこれらのキーワードを使用するためのさまざまなルールを持つようになった経緯に詳しくない人にとっては、さらなる混乱点が生じると思います。

14 java  coding-style  interfaces  coding-standards  keywords 

私はこれに似た2つの関連する方法でインターフェースを設計しています： public interface ThingComputer { default Thing computeFirstThing() { return computeAllThings().get(0); } default List<Thing> computeAllThings() { return ImmutableList.of(computeFirstThing()); } } 実装の約半分で計算されるのは1つだけですが、残りの半分ではさらに多くの計算が行われます。 これは、広く使用されているJava 8コードに先例がありますか？Haskellがいくつかのタイプクラスで同様のことを行うことは知っています（Eqたとえば）。 利点は、2つの抽象クラス（SingleThingComputerおよびMultipleThingComputer）を使用した場合よりも大幅に少ないコードを記述する必要があることです。 欠点は、空の実装がコンパイルされますが、実行時にStackOverflowError。を使用して相互再帰を検出しThreadLocal、より良いエラーを与えることは可能ですが、それにより、バグのないコードにオーバーヘッドが追加されます。

14 java  design  interfaces  java8 

C＃でのインターフェイスおよび明示的なインターフェイスの実装の操作方法は理解していますが、頻繁に使用されない特定のメンバーを非表示にするのが悪いと考えられているのではないかと考えていました。例えば： public interface IMyInterface { int SomeValue { get; set; } int AnotherValue { get; set; } bool SomeFlag { get; set; } event EventHandler SomeValueChanged; event EventHandler AnotherValueChanged; event EventHandler SomeFlagChanged; } イベントは有用ですが、使用されることはほとんどないことを事前に知っています。したがって、IntelliSenseの乱雑さを避けるために、明示的な実装を介して実装クラスからそれらを隠すことは理にかなっていると思いました。

14 c#  interfaces  implementations 

私は最近、より「組織化された」プログラミングを掘り下げてきましたが、実装ではなくインターフェイスにプログラミングする必要があることを学んでいます。それを念頭に置いて、可能であれば実装を記述する前に、インターフェイスでプロジェクトを「スケッチ」する方が良いでしょうか？ サードパーティのライブラリ（Lidgrenなど）を使用する場合は、これらをインターフェイスでラップし、IOCコンテナを介して解決する必要がありますか、それともインターフェイスに公開してもかまいませんか？

14 c#  design  interfaces  third-party-libraries  inversion-of-control 

違いはありますか public class A extends AbstractB implements C {...} 対... public class A extends AbstractB {...} abstract class AbstractB implements C {...} どちらの場合でも、クラスAがインターフェースに準拠することになることを理解しています。2番目のケースでAbstractBは、のインターフェイスメソッドの実装を提供できますC。それが唯一の違いですか？ のインターフェイスメソッドの実装を提供したくない場合 AbstractB、どのスタイルを使用する必要がありますか？どちらか一方を使用すると、何らかの「文書化」の目的が隠されますか？

14 java  interfaces  abstract-class 

OOPで開発する場合、変更できないライブラリによってインターフェイス/コントラクトが与えられることがあります。このインターフェイスをJと呼びましょう。 これで、このインターフェイスを実装するオブジェクトを消費するクラスAのオブジェクトができました。Inside Aインターフェイスの定義のほんの一部だけが必要です。オブジェクトクラスの一部はプロジェクト中に私が作成します（そのうちの1つをタイプDと呼びましょう）。したがって、インターフェイスJ内のすべての実装にオーバーヘッドがあります。 インターフェイスJの機能のサブセットを実装したいのですが、これまでのソリューションでは満足できません。 Jのあらゆる側面を実装し、「notImplementedExceptions」をスローすると、ユーザーにオブジェクトの情報が誤って通知されます。タイプDのオブジェクトはインターフェースJに準拠しているように見えますが、 J）オブジェクトの整合性に依存することはできません。 新しく定義されたインターフェイスを実装すると、インターフェイスJのみを実装するオブジェクトを使用できなくなりますが、インターフェイスJは自分のインターフェイスと完全に互換性があります。 カスタムオブジェクトにインターフェイスJを実装させると、この機能をすべて必要としないため、かなりのオーバーヘッドが発生します。 インターフェースJを変更できた場合、インターフェースJの機能のこのサブセットを持つ「スーパーインターフェース」Kを作成し、インターフェースJをインターフェースKから継承させます。しかし、インターフェースJを変更することはできません。 この問題のオブジェクト指向ソリューションとは何ですか？最良のソリューションは、まだ「単なる」インターフェースJを実装していますか？または、インターフェイスを変更せずに「スーパークラス化」するOOPの方法はありますか？

14 object-oriented  interfaces 

コンテキスト：C＃を使用しています クラスを設計し、それを分離し、ユニットテストを容易にするために、すべての依存関係を渡します。内部的にオブジェクトのインスタンス化は行いません。ただし、必要なデータを取得するためにインターフェイスを参照する代わりに、必要なデータ/動作を返す汎用Funcsを参照するようにします。依存関係を注入するとき、ラムダ式を使用してそれを行うことができます。 私にとっては、単体テスト中に面倒なモックをする必要がないため、これはより良いアプローチのように思えます。また、周囲の実装に根本的な変更がある場合、ファクトリクラスを変更するだけで済みます。ロジックを含むクラスを変更する必要はありません。 ただし、これまでにIoCがこのように行われるのを見たことがないため、見落としがちな潜在的な落とし穴があると思います。私が考えることができるのは、Funcを定義しないC＃の以前のバージョンとのわずかな非互換性だけです。これは私の場合は問題ではありません。 より具体的なインターフェイスとは対照的に、IoCのFuncなどの汎用デリゲート/高階関数の使用に問題はありますか？

14 architecture  interfaces  inversion-of-control  delegates 

何十年には、インターフェースがあった場合をされているのみ だけメソッドのシグネチャを特定する（のみ）。これが「物事を行う正しい方法™」だと言われました。 その後、Java 8が登場して次のように述べました。 えーと、ええと、今ではデフォルトのメソッドを定義できます。さようなら。 経験豊富なJava開発者と、最近（ここ数年）開発を始めたJava開発者の両方によって、これがどのように消化されているのか興味があります。また、これがJavaの正統性と実践にどのように適合するかについても疑問に思っています。 私はいくつかの実験的なコードを構築しており、リファクタリングを行っている間に、標準インターフェース（Iterable）を単純に拡張し、2つのデフォルトメソッドを追加するインターフェースになりました。そして正直に言うと、私はそれについてかなり気分が良いと感じています。 私はこれが少しオープンエンドであることを知っていますが、実際のプロジェクトでJava 8を使用する時間がありましたが、デフォルトメソッドの使用に関する正統性はまだありますか？それらが議論されるときに私が主に見るものは、既存の消費者を壊すことなく、インターフェースに新しいメソッドを追加する方法についてです。しかし、上記の例のように最初からこれを使用するのはどうですか。インターフェースに実装を提供することで問題に直面した人はいますか？

13 java  interfaces  default-method 

私は吸血鬼、オオカミ、人間、トラックをシミュレートするために自分の小さなOOPプログラムを設計しており、インターフェイスに関する私自身の限られた理解を実装しようとしています。 （私はまだここで抽象化しており、まだコードの実装がないので、OOP設計の問題です...私は思う！） これらのクラス間の「共通の振る舞い」を探して、インターフェースとして実装するのは正しいですか？ たとえば、ヴァンパイアとオオカミの噛みつき...噛み付きのインターフェースが必要ですか？ public class Vampire : Villain, IBite, IMove, IAttack トラックについても同様です... public class Truck : Vehicle, IMove そして人間のために... public class Man : Human, IMove, IDead 私の考えはここにありますか？（あなたの助けに感謝）

13 object-oriented  interfaces 

カードに2つの重要な機能セットがあるカードゲームをモデル化しようとしています。 最初は効果です。これらは、カードをプレイしたときに起こるゲームの状態の変化です。有効なインターフェイスは次のとおりです。 boolean isPlayable(Player p, GameState gs); void play(Player p, GameState gs); そして、あなたはそのコストをまかなうことができ、そのすべての効果がプレイ可能である場合にのみ、カードをプレイ可能と考えることができます。そのようです： // in Card class boolean isPlayable(Player p, GameState gs) { if(p.resource < this.cost) return false; for(Effect e : this.effects) { if(!e.isPlayable(p,gs)) return false; } return true; } さて、これまでのところ、非常に簡単です。 カードの他の機能セットは能力です。これらの能力は、ゲームの状態の変化であり、自由にアクティブ化できます。これらのインターフェイスを思いついたとき、それらをアクティブ化できるかどうかを判断する方法と、アクティブ化を実装する方法が必要であることに気付きました。最終的には boolean isActivatable(Player p, GameState gs); void activate(Player p, …

13 interfaces 

これは一般的な質問ですが、私が現在経験している問題にも固有のものです。現在、ソリューションに指定されているインターフェイスがあります public interface IContextProvider { IDataContext { get; set; } IAreaContext { get; set; } } このインターフェイスはプログラム全体でよく使用されるため、必要なオブジェクトに簡単にアクセスできます。しかし、プログラムの一部のかなり低いレベルでは、IAreaContextを使用し、それからいくつかの操作を実行する別のクラスにアクセスする必要があります。そこで、この作成を行うための別のファクトリインターフェイスを作成しました。 public interface IEventContextFactory { IEventContext CreateEventContext(int eventId); } IContextProviderを実装し、NinJectを使用して注入されるクラスがあります。私が抱えている問題は、このIEventContextFactoryを使用する必要がある領域がIContextProviderにのみアクセスでき、それ自体がこの新しいインターフェイスを必要とする別のクラスを使用することです。IEventContextFactoryのこの実装を低レベルでインスタンス化する必要はなく、むしろIEventContextFactoryインターフェース全体で動作します。ただし、コンストラクタを介して別のパラメータを挿入する必要はありません。それを必要とするクラスに渡すだけです。つまり、 // example of problem public class MyClass { public MyClass(IContextProvider context, IEventContextFactory event) { _context = context; _event = event; } public void DoSomething() …

13 c#  design  interfaces 

Herb Sutterによると、実装を可能な限り分離するために、C ++の抽象クラスよりも抽象インターフェイス（すべて純粋な仮想関数）を好むはずです。私は個人的にこのルールが非常に役立つと感じていますが、最近、多くのJavaプログラマーとチームに参加しましたが、Javaコードにはこのガイドラインは存在しないようです。関数とその実装は、非常に頻繁に抽象クラスに配置されます。だから、C ++でさえハーブサッターをすべて間違っているのか、それともJavaと比較してC ++の抽象関数の使用に一般的な違いがあるのか​​。実装コードを持つ抽象クラスは、C ++よりもJavaの方が賢明ですか？

13 java  c++  interfaces  abstract-class 

私は自分自身にソフトウェア工学を教えようとしていますが、私を混乱させる矛盾する情報に出くわします。 私はOOPと抽象クラス/インターフェースとは何か、そしてそれらをどのように使用するかを学びましたが、「継承よりも合成を優先する」べきだと読んでいます。構成とは、あるクラスが別のクラスのオブジェクトを構成/作成して、その新しいオブジェクトの機能を利用/対話することです。 だから私の質問は...抽象クラスとインターフェイスを使用しないはずですか？抽象クラスを作成せず、その抽象クラスの機能を具象クラスで拡張/継承し、代わりに、新しいオブジェクトを作成して他のクラスの機能を使用するだけですか？ または、構成を使用し、抽象クラスから継承することになっています。両方を一緒に使用しますか？もしそうなら、それがどのように機能し、その利点のいくつかの例を提供できますか？ 私はPHPに最も慣れているので、他の言語に移り、新しく習得したSEスキルを移転する前に、それを使用してOOP / SEスキルを向上させています。

13 object-oriented  php  interfaces  inheritance  composition 

いくつかのデフォルト/共有機能を持つクラスがあります。私abstract classはそれを使用します： public interface ITypeNameMapper { string Map(TypeDefinition typeDefinition); } public abstract class TypeNameMapper : ITypeNameMapper { public virtual string Map(TypeDefinition typeDefinition) { if (typeDefinition is ClassDefinition classDefinition) { return Map(classDefinition); } ... throw new ArgumentOutOfRangeException(nameof(typeDefinition)); } protected abstract string Map(ClassDefinition classDefinition); } ご覧のとおり、インターフェイスもありますITypeNameMapper。私がすでに抽象クラスを持っているTypeNameMapperか、それでabstract class十分な場合、このインターフェイスを定義するのは理にかなっていますか？ TypeDefinition この最小限の例でも抽象的です。

12 c#  interfaces  abstract-class