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

複数のクラスが一連の規則と実装を順守しているということは、インターフェースのポイントではありませんか？

243 design-patterns  coding-standards  interfaces 

私は最近、非常に大きなアプリケーション（15M loc）で作業している新しい仕事を始めました。私の以前の仕事では、同様に大きなアプリケーションがありましたが、（良くも悪くも）OSGiを使用しました。これは、アプリケーションを独立して変更、コンパイル、デプロイできる多数のマイクロサービスに分割することを意味しました。新しいアプリケーションは、たった2つの.dllを備えた1つの大きなコードベースにすぎません。 ですから、このクラスのインターフェースを変更する必要があります。それが上司が私に要求したことだからです。彼らは当初、あまり一般化されていないいくつかの仮定でそれを書きました。しばらくの間、リファクタリングの問題は非常に密に結合されているため回避していました。インターフェイスを変更しましたが、現在25000以上のエラーがあります。エラーの一部は、「XYZPriceCalculator」のような重要な名前のクラスにあり、これは本当に壊れてはいけません。しかし、すべてのエラーが解決されるまで、アプリケーションを起動して動作するかどうかを確認することはできません。また、ユニットテストの多くは、そのインターフェイスを直接参照するか、そのインターフェイスを参照する基本クラスに結合されるため、それらを修正するだけでも非常に大きなタスクです。さらに、これらのすべてのピースがどのように組み合わされるかについては本当にわからないので、たとえ始めたとしても、物が壊れた場合にどのように見えるかはよくわかりません。 私は最後の仕事でこのような問題に本当に直面したことはありません。私は何をしますか？

166 interfaces  debugging  coupling  errors 

しばらくの間、C＃で勉強とコーディングを行ってきました。しかし、それでも、インターフェイスの有用性を理解することはできません。テーブルに持っていくものが少なすぎます。機能の署名を提供する以外、何もしません。実装する必要のある関数の名前と署名を覚えていれば、それらは不要です。これらは、インターフェイス内の上記の関数が継承クラスに実装されていることを確認するためだけにあります。 C＃は優れた言語ですが、Microsoftが最初に問題を作成し（多重継承を許可しない）、解決策を提供するという感覚を与えることがありますが、これは面倒なものです。 それは限られたコーディング経験に基づく私の理解です。インターフェースについてどう思いますか？どのくらいの頻度でそれらを使用しますか？

158 interfaces 

私は常に、構成が継承よりも優先されることを読みました。種類とは異なり、上のブログの記事は、例えば、相続上の組成物を用いて提唱したが、私は多型が達成されたかを確認することはできません。 しかし、私は人々が作曲を好むと言うとき、彼らは本当に作曲とインターフェース実装の組み合わせを好むことを意味すると感じています。継承なしでどのようにポリモーフィズムを取得するのですか？ 継承を使用する具体的な例を次に示します。構成を使用するためにこれをどのように変更しますか？ Class Shape { string name; public: void getName(); virtual void draw()=0; } Class Circle: public Shape { void draw(/*draw circle*/); }

109 interfaces  inheritance  composition 

Java 8では、インターフェイスに実装メソッド、静的メソッド、いわゆる「デフォルト」メソッド（実装クラスがオーバーライドする必要はありません）を含めることができます。 私の（おそらく素朴な）見解では、このようなインターフェースに違反する必要はありませんでした。インターフェイスは常にあなたが満たさなければならない契約であり、これは非常にシンプルで純粋な概念です。今では、いくつかのものが混在しています。私の考えでは： 静的メソッドはインターフェイスに属しません。これらはユーティリティクラスに属します。 「デフォルト」メソッドはインターフェースでまったく許可されるべきではありません。この目的には常に抽象クラスを使用できます。 要するに： Java 8より前： 抽象クラスと通常クラスを使用して、静的メソッドとデフォルトメソッドを提供できます。インターフェイスの役割は明確です。 クラスを実装することにより、インターフェイス内のすべてのメソッドをオーバーライドする必要があります。 すべての実装を変更せずにインターフェイスに新しいメソッドを追加することはできませんが、これは実際には良いことです。 Java 8以降： インターフェースと抽象クラス（多重継承を除く）には実質的に違いはありません。実際、インターフェイスを使用して通常のクラスをエミュレートできます。 実装をプログラミングするとき、プログラマはデフォルトのメソッドをオーバーライドするのを忘れることがあります。 クラスが同じシグネチャを持つデフォルトメソッドを持つ2つ以上のインターフェイスを実装しようとすると、コンパイルエラーが発生します。 インターフェイスにデフォルトのメソッドを追加することにより、実装するすべてのクラスがこの動作を自動的に継承します。これらのクラスの一部は、その新しい機能を念頭に置いて設計されていない可能性があり、これにより問題が発生する可能性があります。たとえば、誰かが新しいデフォルトのメソッドdefault void foo()をinterface Ixに追加すると、同じシグネチャを持つプライベートメソッドをCx実装Ixしているクラスfooはコンパイルされません。 このような大きな変更の主な理由は何ですか？また、追加された新しいメリット（ある場合）は何ですか？

99 java  programming-languages  interfaces  java8 

現時点では、ユニットテストを許可するようにコード設計を変更することはコードのにおいであるのか、それともコードのにおいをせずにどの程度できるのかについて、チームで議論が行われています。これは、他のすべてのソフトウェア開発会社に存在するプラクティスを導入し始めたばかりだからです。 具体的には、非常に薄いWeb APIサービスが用意されます。その主な責任は、Web要求/応答をマーシャリングし、ビジネスロジックを含む基盤となるAPIを呼び出すことです。 1つの例は、認証方法の種類を返すファクトリの作成を計画していることです。インターフェースを継承する必要はありません。具体的なタイプ以外のものになるとは思わないからです。ただし、Web APIサービスを単体テストするには、このファクトリをモックする必要があります。 これは本質的に、（コンストラクターまたはセッターを介して）DIを受け入れるようにWeb APIコントローラークラスを設計することを意味します。つまり、DIを許可するためだけにコントローラーの一部を設計し、そうでなければ必要のないインターフェースを実装することを意味しますこの方法でコントローラーを設計する必要を避けるために、Ninjectのようなサードパーティのフレームワークがありますが、インターフェイスを作成する必要があります。 チームの何人かは、テストのためだけにコードを設計することを渋っているようです。単体テストを行うには妥協が必要だと思われますが、彼らの懸念をどのように和らげるかはわかりません。 明確にするために、これはまったく新しいプロジェクトであるため、コードを変更して単体テストを有効にすることではありません。ユニットテスト可能になるように記述するコードを設計することです。

91 unit-testing  interfaces  web-api  asp.net-core 

ハードウェア/ソフトウェアインターフェースおよびオペレーティングシステムに関する初心者向けコースでは、多くの場合、ハードウェアの一部をソフトウェアに、またはその逆に置き換える方が良いかどうかというトピックが出てきます。接続できません。

90 interfaces  operating-systems  software  hardware 

私は、ロバート・マーティンによる「クリーン・コード」を読んで、できればより良いプログラマーになることを望んでいます。これまでのところ、どれも本当に画期的なものではありませんでしたが、アプリケーションの設計とコードの記述方法について、私は違った考え方をしました。 本の一部には、同意しないだけでなく、特にインターフェースの命名規則に関して、私には意味がありません。これは、本から直接取ったテキストです。混乱を招くと思われるこの側面を太字で示し、説明を希望します。 私はインターフェースを装飾しないままにしておきたい。前のIは、今日のレガシーワッドで非常に一般的であるが、せいぜい気を散らすものであり、最悪の場合には情報が多すぎる。ユーザーにインターフェースを渡していることをユーザーに知らせたくない。 おそらく、私が学生だからか、プロやチームベースのプログラミングを一度もしたことがないからかもしれませんが、それがインターフェースであることをユーザーに知ってもらいたいからでしょう。 インターフェイスの実装とクラスの拡張には大きな違いがあります。 それで、私の質問は、「コードの一部がインターフェースを期待しているという事実を隠す必要があるのか​​？」に要約されます。 編集 回答に応じて： タイプがインターフェースである場合、またはクラスがあなたのビジネスであり、コードを使用している誰かのビジネスではない場合。したがって、このサードパーティのコードでコードの詳細を漏らさないでください。 特定の型がインターフェイスであるか、サードパーティのコードのクラスであるかの詳細を「漏洩」しないのはなぜですか？サードパーティの開発者がコードを使用して、インターフェイスを実装するのか、クラスを拡張するのかを知ることは重要ではありませんか？違いは、私が自分の頭に浮かぶほど重要ではありませんか？

73 naming  interfaces  coding-standards 

「抽象クラス」と「インターフェース」は類似した概念であり、インターフェースはより抽象的な概念です。1つの差別化要因は、抽象クラスが必要なときに派生クラスのメソッド実装を提供することです。ただし、C＃では、この差別化要因は、インターフェイスメソッドの実装を提供できる拡張メソッドの最近の導入によって削減されました。別の差別化要因は、クラスが1つの抽象クラスのみを継承できる（つまり、多重継承がない）が、複数のインターフェイスを実装できることです。これにより、インターフェイスの制限が緩和され、柔軟性が高まります。それでは、C＃では、拡張メソッドを備えたインターフェイスの代わりに抽象クラスをいつ使用すべきでしょうか？ インターフェイス+拡張メソッドモデルの注目すべき例はLINQです。ここではIEnumerable、多数の拡張メソッドを介して実装されるすべてのタイプに対してクエリ機能が提供されます。

70 c#  design  interfaces  inheritance  abstract-class 

何が良くて、なぜですか？（インターフェース設計の観点から）： A）2持っているShow()とHide()機能を b）1つのSetVisible(bool visible)機能を持つ 編集：たとえば、一部のオブジェクトには可視性の状態があり、この関数を使用して変更します。 C）3つのすべての持っているためにShow()、Hide()、SetVisible(bool visible)機能を

59 java  c++  interfaces 

C＃では、次のコードが有効です interface I{ int property{get;set;} } これは私には意味がありません。これは、インターフェースの最も重要な原則の1つ、つまり状態の欠如（つまり、フィールドなし）を破っているようです。プロパティは暗黙のプライベートフィールドを作成しませんか？それはインターフェースにとって本当に悪いことではないでしょうか？

47 c#  interfaces  properties 

次のようなインターフェイスを設計した同僚が隣に座っています。 public interface IEventGetter { public List<FooType> getFooList(String fooName, Date start, Date end) throws Exception; .... } 問題は、現時点では、この「end」パラメーターをコードのどこにも使用していないことです。将来的に使用する必要があるため、そこにあるだけです。 現在、役に立たないインターフェースにパラメーターを入れるのは悪い考えだと彼に納得させようとしていますが、「終了」日付の使用をいつか実装すると、多くの作業が必要になると主張し続けます。その後、すべてのコードを適応させる必要があります。 さて、私の質問は、「尊敬される」コーディングの達人のようなトピックを扱っているソースはありますか？

42 java  object-oriented-design  interfaces 

Rich Hickeyの思考を刺激するgoto会議の基調講演「価値の価値」で29分間、彼はJavaのような言語のオーバーヘッドについて話し、「これらのインターフェースはすべて再利用を殺します」のような声明を出します。彼はどういう意味ですか？本当？ 私は答えを探して、次のことを見つけました。 最小知識の原則別名、気密APIインターフェイスを奨励するデメテルの法則。ウィキペディアには、いくつかの欠点もリストされています。 再利用ではなく、その使用が適切な目標であると主張するケヴリン・ヘニーのインペリアル衣料危機。 ジャック・ディーデリッヒの「クラスを書くのをやめなさい」は、一般的なオーバーエンジニアリングに反対する議論をしています。 明らかに、不適切に書かれたものは何も役に立たないでしょう。しかし、適切に作成されたAPIのインターフェースは、そのコードの使用をどのように防ぐのでしょうか？1つの目的のために作られたものが他のものにより多く使用されている歴史の中に例があります。しかし、ソフトウェアの世界では、意図していない目的で何かを使用すると、通常は壊れます。 私は、いくつかのコードの正当であるが意図しない使用を防ぐ良いインターフェースの良い例を探しています。それは存在しますか？想像できません。

41 java  interfaces  code-reuse  clojure 

インターフェースはめったに使用せず、他のコードでは一般的です。 また、コード内でめったにサブクラスとスーパークラスを作成しません（独自のクラスを作成します）。 それは悪いことですか？ このスタイルを変更することをお勧めしますか？ このスタイルには副作用がありますか？ これは、私が大規模なプロジェクトに取り組んだことがないためですか？

40 programming-practices  coding-style  interfaces 

以前は、多くの抽象クラス/メソッドを作成していました。その後、インターフェイスの使用を開始しました。 現在、インターフェイスが抽象クラスを廃止していないかどうかはわかりません。 完全に抽象クラスが必要ですか？代わりにインターフェースを作成してください。いくつかの実装を含む抽象クラスが必要ですか？インターフェイスを作成し、クラスを作成します。クラスを継承し、インターフェイスを実装します。追加の利点は、一部のクラスが親クラスを必要とせず、インターフェイスを実装するだけであることです。 それでは、抽象クラス/メソッドは廃止されていますか？

37 object-oriented  architecture  inheritance  interfaces