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

PHP5の時点で、言語にインターフェースが追加されていることに気付きました。ただし、PHPは非常に緩やかに型付けされているため、インターフェイスを使用する利点のほとんどが失われているようです。なぜこれが言語に含まれているのですか？

35 php  object-oriented  interfaces  static-typing  duck-typing 

読んだ後、パッケージ名は単数形か複数形か？私は、自分のペットの探求の1つであるインターフェイスの実装の命名に関する適切な議論を見たことがないことに気付きました。 Orderさまざまな方法で実装することを目的としたインターフェースを持っているが、プロジェクトが最初に作成されたときの最初の実装のみがあると仮定しましょう。あなたはのために行くかDefaultOrderまたはOrderImpl虚偽の二分法を避けるために、または他のいくつかの変種？そして、実装が増えたらどうしますか？ そして最も重要なのはなぜですか？

34 naming  interfaces 

UIとモデルの間の適切なデカップリングを実装する方法を十分に理解しようとしていますが、行を分割する場所を正確に把握するのに苦労しています。 私はModel-View-Presenterを見てきましたが、それをどのように実装するのか正確にはわかりません。たとえば、私のビューには複数のダイアログがあります。 各ダイアログのインスタンスを持つViewクラスが必要ですか？その場合、ダイアログはプレゼンターとどのように対話する必要がありますか？すなわち。個々のダイアログがプレゼンターを介してモデルからデータを要求する必要がある場合、ダイアログはプレゼンターへの参照をどのように取得する必要がありますか？建設中に与えられたビューへの参照を介して？ 私は多分ビューが静的なクラスであるべきだと思っていましたか？次に、GetViewダイアログとそこからプレゼンターを取得します... ビューとモデルの所有権を持つプレゼンターをセットアップすることを考えていました（ビューを持つプレゼンターとプレゼンターがモデルを持つのとは対照的に）、プレゼンターはビューのイベントのコールバックを登録しますが、それは多くのように見えますより結合された（または少なくとも言語に依存） 私がしようとしている： これを可能な限り分離する 理想的には、プレゼンター/モデルを他の言語のビューと結合することを可能にします（言語間で大量のことをやったことはありませんが、可能な限り、特にvoid(void)私ができる限り、少なくともC＃アプリでC ++ライブラリ... コードを簡潔かつシンプルに保つ だから..相互作用をどのように処理すべきか提案はありますか？

34 design-patterns  ui  interfaces 

クラスimplementsがインターフェイスの場合、継承をフォローしていると言えますか？クラスがextends別のクラスの場合、それは継承であることを知っています。

31 java  terminology  interfaces  inheritance  definition 

とても簡単です。私はインターフェイスを実装していますが、このクラスには不要なプロパティが1つあり、実際には使用しないでください。私の最初のアイデアは、次のようなことをすることでした。 int IFoo.Bar { get { raise new NotImplementedException(); } } これ自体に問題はないと思いますが、「正しい」とは感じません。他の誰かが以前に同様の状況に遭遇したことはありますか？もしそうなら、どのようにアプローチしましたか？

31 c#  design  interfaces  implementations 

インターフェイスを簡素化するには、getBalance()メソッドを持たない方が良いでしょうか？に渡す0とcharge(float c);同じ結果が得られます。 public class Client { private float bal; float getBalance() { return bal; } float charge(float c) { bal -= c; return bal; } } たぶんメモしてくださいjavadoc？または、バランスを取る方法を理解するためにクラスユーザーに任せてください。

30 interfaces  cqrs 

クラス内にあるようなメソッド.compareTo()がComparableインターフェイスにある理由を知りたいです。私には、なぜそのようなメソッドがクラスにないのかはarbitrary意的に思えます。.equalsObject.compareTo()Object を使用する.compareTo()には、目的に応じてComparableインターフェイスを実装し、.compareTo()メソッドを実装します。以下のために.equals()、すべてのクラスから継承するため、この方法は、単に、あなたのクラスのメソッドをオーバーライドしObjectたクラス。 私の質問は、なぜ.compareTo()クラスのようなものではなく、実装するインターフェースのようなメソッドなのObjectですか？同様に、実装されるインターフェースではなく.equals()、クラスのメソッドがなぜObjectですか？

30 java  language-design  interfaces 

同僚と私は、基本クラスとインターフェイスの関係について異なる意見を持っています。インターフェイスの実装が必要なときにそのクラスを使用できる場合を除き、クラスはインターフェイスを実装すべきではないと考えています。言い換えれば、私はこのようなコードを見たい： interface IFooWorker { void Work(); } abstract class BaseWorker { ... base class behaviors ... public abstract void Work() { } protected string CleanData(string data) { ... } } class DbWorker : BaseWorker, IFooWorker { public void Work() { Repository.AddCleanData(base.CleanData(UI.GetDirtyData())); } } DbWorkerは、インスタンス化可能なインターフェイスの実装であるため、IFooWorkerインターフェイスを取得するものです。契約を完全に満たします。私の同僚はほぼ同じものを好む： interface IFooWorker { void Work(); } …

30 design-patterns  object-oriented  object-oriented-design  interfaces 

「実装ではなくインターフェースへのプログラミング」という用語に頻繁に出くわしましたが、それが何を意味するのか理解していると思います。しかし、私はそれが利点であり、可能な実装であることを確実に理解したいと思っています。 「インターフェースへのプログラミング」とは、可能な場合、具体的な実装を参照するのではなく、クラスのより抽象的なレベル（インターフェース、抽象クラス、またはある種のスーパークラス）を参照する必要があることを意味します。 Javaの一般的な例は、次を使用することです。 List myList = new ArrayList();の代わりにArrayList myList = new ArrayList();。 これに関して2つの質問があります。 このアプローチの主な利点を確実に理解したいと思います。利点は主に柔軟性だと思います。具体的な実装ではなく、より高レベルの参照としてオブジェクトを宣言すると、開発サイクル全体およびコード全体で柔軟性と保守性が向上します。これは正しいです？柔軟性が主な利点ですか？ 「インターフェースへのプログラミング」の方法は他にありますか？または、「具体的な実装ではなく、インターフェイスとして変数を宣言する」がこの概念の唯一の実装ですか？ 私はJavaコンストラクトInterfaceについて話しているのではありません。オブジェクト指向の原則「実装ではなく、インターフェイスへのプログラミング」について話しています。この原則では、世界の「インターフェース」とは、クラスの任意の「スーパータイプ」を指します。インターフェース、抽象クラス、またはより具体的なサブクラスよりも抽象的で具体的ではない単純なスーパークラスです。

29 design  object-oriented  interfaces 

交換可能かつテスト可能であるためには、通常、ロジックを備えたサービスにインターフェースが必要です。 public class FooService: IFooService { ... } 設計面ではこれに同意しますが、このアプローチで気になる点の1つは、1つのサービスに対して2つのもの（クラスとインターフェース）を宣言する必要があり、チームでは通常2つのファイル（1つクラス用とインターフェイス用）。IDE（VS2010）で[定義に移動]を使用すると、実際のクラスではなくインターフェイス（他のクラスがインターフェイスを参照するため）を指すため、ナビゲーションの難しさがもう1つあります。 FooServiceと同じファイルにIFooServiceを記述すると、上記の奇妙さが軽減されると考えていました。結局、IFooServiceとFooServiceは非常に関連しています。これは良い習慣ですか？IFooServiceを独自のファイルに配置する必要がある正当な理由はありますか？

29 c#  .net  visual-studio  interfaces 

インターフェイスのサフィックスとして「-able」を使用するのが一般的です Serializable Printable Enumerable Drinkable Shootable Rotatable 「Can-」の方がわかりやすいので、もっと良いかもしれないと考えていました。はい、より冗長であり、インターフェイス名にノイズを追加します。特に、受動動詞を使用できます。 例えば、Shootableは、オブジェクトが射撃できることを意味します（銃がこれを実装する場合があります）、または射撃できることを意味します（ターゲットボードがこれを実装する場合があります）。「Can-」プレフィックスを使用すると、前者は「CanShoot」になり、後者は「CanBeShotAt」または「CanShootAt」になります。 例2ドキュメント「CanBePrinted」とプリンター「CanPrint」 または、「-Able」に固執し、ドキュメントにコンテキストを提供させますか？ ご意見。

29 api  interfaces 

過去数ヶ月間、私は次のテクニック/パターンで数回つまずきました。しかし、特定の名前を見つけることはできないようです。また、その長所と短所を100％確信しています。 パターンは次のとおりです。 Javaインターフェース内では、一般的なメソッドのセットが通常どおり定義されます。ただし、内部クラスを使用すると、デフォルトのインスタンスがインターフェースを介してリークされます。 public interface Vehicle { public void accelerate(); public void decelerate(); public static class Default { public static Vehicle getInstance() { return new Car(); // or use Spring to retrieve an instance } } } 私にとって、最大の利点は、開発者がインターフェイスについてのみ知る必要があり、実装についてではなく、インスタンスをすぐに作成したい場合などです。 Vehicle someVehicle = Vehicle.Default.getInstance(); someVehicle.accelerate(); さらに、構成に応じてインスタンスを動的に提供するために、Springと共にこの手法が使用されているのを見てきました。この点で、これもモジュール化に役立つようです。 それにもかかわらず、インターフェイスを実装の1つと結合するため、これがインターフェイスの誤用であるという感覚を揺るがすことはできません。（依存性反転の原理など。）誰もがこの技術がどのように呼ばれるか、そしてその長所と短所を私に説明してもらえますか？ 更新： しばらく検討した後、次のシングルトンバージョンのパターンがはるかに頻繁に使用されていることを再確認しました。このバージョンでは、パブリックの静的インスタンスは、（フィールドが最終であるために）1回だけ初期化されるインターフェイスを介して公開されます。さらに、インスタンスはほとんどの場合、Springまたは実装からインターフェイスを分離する汎用ファクトリーを使用して取得されます。 public interface Vehicle …

28 java  interfaces  anti-patterns  technique 

これはC ++標準では必須ではありませんが、たとえばGCCが純粋な抽象クラスを含む親クラスを実装する方法は、問題のクラスのすべてのインスタンス化にその抽象クラスのvテーブルへのポインタを含めることです。 当然、これは、このクラスのすべてのインスタンスのサイズを、それが持つすべての親クラスのポインターによって膨張させます。 しかし、多くのC＃クラスと構造体には、基本的に純粋な抽象クラスである多くの親インターフェイスがあることに気付きました。sayのすべてのインスタンスがDecimal、さまざまなインターフェースすべてへの6つのポインターで肥大化していた場合、私は驚くでしょう。 それで、C＃がインターフェースを異なる方法で実行する場合、少なくとも典型的な実装では、どのようにインターフェースを実行しますか（標準自体はそのような実装を定義しないかもしれません）。また、純粋な仮想親をクラスに追加するときに、C ++の実装にオブジェクトサイズの膨張を回避する方法がありますか？

27 c#  c++  interfaces  optimization  abstract-class 

タスクは、入力仕様に従って、デバイス内のハードウェアを構成することです。これは次のように達成する必要があります。 1）構成情報を収集します。これは、さまざまな時間と場所で発生する可能性があります。たとえば、モジュールAとモジュールBは両方とも（異なる時間に）私のモジュールにリソースを要求できます。これらの「リソース」は、実際には構成です。 2）これ以上要求が実現されないことが明らかになった後、要求されたリソースの要約を提供する起動コマンドをハードウェアに送信する必要があります。 3）その後のみ、前述のリソースの詳細な構成を行うことができます（およびする必要があります）。 4）また、2）の後でのみ、選択したリソースの宣言された呼び出し元へのルーティングを行うことができます（およびする必要があります）。 バグの一般的な原因は、それを書いた私でさえ、この順序を間違えていることです。コードを初めて見る人がインターフェイスを使用できるようにするために、どのような命名規則、設計、またはメカニズムを使用できますか？

24 c++  interfaces 

インターフェイスがあるとしましょうIFoo： public interface IFoo { void Bar(string s); int Quux(object o); } APIのバージョン2では、Glargこのインターフェイスにメソッドを追加する必要があります。既存のAPIユーザーを破壊せず、後方互換性を維持せずに、どのように行いますか？これは主に.NETを対象としていますが、他のフレームワークと言語にも適用できます。

22 versioning  interfaces