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

バックグラウンド 特定の種類のハードウェアデバイスの使用状況に依存するプロジェクトがありますが、必要なことを行うのであれば、誰がそのハードウェアデバイスを作成するかは重要ではありません。そうは言っても、同じことをするはずの2つのデバイスでも、同じ製造元以外のデバイスでは違いがあります。したがって、インターフェイスを使用して、関連するデバイスの特定のメーカー/モデルからアプリケーションを分離し、代わりに、インターフェイスに最高レベルの機能をカバーさせることを考えています。これが私のアーキテクチャが次のようになると私が考えているものです： 1つのC＃プロジェクトでインターフェイスを定義しますIDevice。 別のC＃プロジェクトで定義されたライブラリに、デバイスを表すために使用される具象があります。 具体的なデバイスにIDeviceインターフェースを実装してもらいます。 IDeviceインタフェースは次のような方法かもしれないGetMeasurementかをSetRange。 アプリケーションに具象に関する知識を持たせ、具象をデバイスを利用する（実装しない）アプリケーションコードに渡しIDeviceます。 アプリケーションに影響を与えずに、使用中のデバイスを変更できるため（これは時々発生するようです）、これが適切な方法であると確信しています。言い換えると、具象の実装方法GetMeasurementやSetRange具象を通して実際に機能する方法は重要ではありません（デバイスのメーカーによって異なる場合があります）。 私の心の中で唯一の疑問は、今やアプリケーションとデバイスの具象クラスの両方がIDeviceインターフェースを含むライブラリに依存しているということです。しかし、それは悪いことですか？ また、デバイスとIDevice同じ名前空間に属していない限り、アプリケーションがデバイスについて知る必要がない方法もわかりません。 質問 これは、アプリケーションとそれが使用するデバイスとの間の依存関係を切り離すためのインターフェースを実装するための正しいアプローチのように思えますか？

10 c#  design-patterns  object-oriented  interfaces  dependency-management 

私の同僚は、基本クラスとインターフェイスのどちらを作成するかを選択するための経験則を考え出しました。 彼は言う： 実装しようとしているすべての新しいメソッドを想像してみてください。それらのそれぞれについて、このことを考慮してください。この方法は、内の複数のクラスによって実装されます正確にせずに、このフォームの任意の変化？答えが「はい」の場合は、基本クラスを作成します。他のすべての状況では、インターフェースを作成します。 例えば： クラスを検討catしてdogクラスを拡張し、mammal単一の方法を持っているがpet()。次に、alligator何も拡張せず、1つのメソッドを持つクラスを追加しslither()ます。 次に、eat()それらすべてにメソッドを追加します。 実装した場合eat()の方法は、のためにまったく同じになりcat、dogそしてalligator、私たちは、基本クラス（LETだと言う、作成する必要がありanimal、このメソッドを実装します）。 ただし、実装がalligator少しでも異なる場合は、IEatインターフェースを作成して作成mammalおよびalligator実装する必要があります。 彼はこの方法がすべてのケースをカバーすると主張しますが、私には過度に単純化しているようです。 この経験則に従う価値はありますか？

10 object-oriented  interfaces  inheritance 

私のAndroidアクティビティには、すべてOnClickListenerを必要とする複数のボタンが含まれています。私はこれを行う多くの異なる方法を見てきました： アクティビティクラスでのインターフェースの実装 インターフェースを実装する別のクラスを作成する 各ボタンの匿名内部クラスを定義します。 私はそれぞれのアプローチの多くの例を見てきました。ただし、なぜ1つのアプローチが別のアプローチの代わりに使用されるのかは、はっきりしません。これらのアプローチの違いは文体的ですか、それとも1つのアプローチを改善する理由がありますか？

10 java  android  interfaces 

私はGroovyを学んでいて、2.3で追加された新機能であるTraitsの追加について学びました。今の私には、Traitsを使用すると、基本的にスーパークラスとインターフェイスで実行できるすべてのことを実行できるように見えます。 Groovyにトレイトを追加すると、継承とインターフェースが廃止されますか？ そうでない場合、これらの各メカニズムを使用するのに最適な時期はいつですか？

10 interfaces  inheritance  groovy 

私はインターフェースを「発見」し、それらを愛するようになりました。インターフェイスの優れた点は、それがコントラクトであることであり、そのコントラクトを満たすオブジェクトは、そのインターフェイスが必要な場所であればどこでも使用できます。 インターフェースの問題は、それがデフォルトの実装を持つことができないことです。これは、ありふれたプロパティの苦痛であり、DRYを無効にします。これは、実装とシステムの分離を維持するため、これも良い方法です。一方、継承はより緊密な結合を維持し、カプセル化を壊す可能性があります。 ケース1（プライベートメンバーによる継承、適切なカプセル化、密結合） class Employee { int money_earned; string name; public: void do_work(){money_earned++;}; string get_name(return name;); }; class Nurse : public Employee: { public: void do_work(/*do work. Oops, can't update money_earned. Unaware I have to call superclass' do_work()*/); }; void HireNurse(Nurse *n) { nurse->do_work(); ) ケース2（単なるインターフェース） class IEmployee { virtual …

10 c++  design  interfaces  class-design  inheritance 

同じテーブルを更新するデータベースアクセスオブジェクトを必要とする2つのクラスがあるプロジェクトがあります。フレームワークとプロジェクトの制約により、これら2つのクラスを組み合わせることはできません。以下のケースを作成して、セットアップ方法を示します。クラスAはレコードを更新および読み取りできる必要があり、クラスBはレコードを更新および削除できる必要があります。 クラスをそのまま使用すると問題なく機能しますが、各クラスが実装に使用していない機能を必要とするという問題があります。たとえば、クラスAを使用するには、削除関数が呼び出されない場合でも、削除関数を実装するdaoを渡す必要があります。同様に、クラスBにread関数を実装するdaoを渡す必要がありますが、呼び出されることはありません。 他を継承するインターフェイス（IReadDao、IUpdateDao、IDeleteDaoは継承元のdaos）を使用してアプローチすることを考えましたが、このアプローチでは基本的に、関数の組み合わせごとに異なるインターフェイス（IUpdateAndRead、IReadAndDelete、IReadAndUpdate ... ） アプリケーションとデータベースを結合したくないので、daoのインターフェースを使用します。誰かが知っている私がやりたいことを達成するためのパターンや方法はありますか？前もって感謝します。 class IDao { void update(ModelDao model); void delete(String guid); ModelDao read(String guid); } Class A { private IDao dao; public A(IDao dao) { this.dao = dao; } public void doStuff() { ModelDao model = new ModelDao(); ... dao.update(model); } public void readThenDoSomething(String id) { …

9 java  interfaces 

カスタムエラーハンドラーのJavaでインターフェイスを作成しています。 引数エラーオブジェクトを渡したいのですが、Exceptionクラスの子である必要があります。 定義したクラス名をインターフェイスで使用しても大丈夫ですか？ 実装に依存しないという点で、インターフェースを少なくしませんか？ 私はこのようなことをやろうとします： public class CustomException { /* ... Implementation ... */ } public interface Interface { void onError(CustomException ex); }

9 java  design  object-oriented  interfaces 

次のスタイルで記述されたコードベースの一部があります。 // IScheduledTask.cs public interface IScheduledTask { string TaskName { get; set; } int TaskPriority { get; set; } List<IScheduledTask> Subtasks { get; set; } // ... several more properties in this vein } // ScheduledTaskImpl.cs public class ScheduledTaskImpl : IScheduledTask { public string TaskName { get; set; } public …

9 design  object-oriented-design  interfaces  procedural 

アジャイルソフトウェア開発、原則、パターン、およびプラクティス：ピアソン新国際版： 場合によっては、クライアントの異なるグループによって呼び出されるメソッドが重複することがあります。オーバーラップが小さい場合、グループのインターフェースは分離したままにする必要があります。共通の関数は、オーバーラップするすべてのインターフェースで宣言する必要があります。サーバークラスは、これらの各インターフェイスから共通の機能を継承しますが、実装するのは1回だけです。 ボブおじさんは、少しの重複がある場合について話します。 大きな重複がある場合はどうすればよいですか？ 私たちは持っていると言います Class UiInterface1; Class UiInterface2; Class UiInterface3; Class UiIterface : public UiInterface1, public UiInterface2, public UiInterface3{}; 間にかなりの重複がある場合、我々は何をすべきUiInterface1とはUiInterface2？

9 design  object-oriented  c++  interfaces  solid 

インターフェイスから実装するクラスがどのようにインスタンス化されるかに関するこの質問での議論を見てきました。私の場合、私はのインスタンスを使用するJavaで非常に小さなプログラムを書いており、TreeMapそこでの皆の意見によると、次のようにインスタンス化する必要があります。 Map<X> map = new TreeMap<X>(); 私のプログラムでmap.pollFirstEntry()は、Mapインターフェイスで宣言されていない関数（およびMapインターフェイスにも存在する他のカップル）を呼び出しています。私はTreeMap<X>次のようにこのメソッドを呼び出すすべての場所にキャストすることでこれを行うことができました： someEntry = ((TreeMap<X>) map).pollFirstEntry(); 上記の初期化ガイドラインの利点を大規模プログラムで理解していますが、このオブジェクトが他のメソッドに渡されない非常に小規模なプログラムの場合は、不要だと思います。それでも、私はこのサンプルコードを求人アプリケーションの一部として書いており、コードの見栄えを悪くしたり、散らかしたりしたくありません。最もエレガントなソリューションは何でしょうか？ 編集：私は、特定の関数を適用するよりも、広く適切なコーディング方法に関心があることを指摘しておきますTreeMap。一部の回答は既に指摘されている（そして、最初に回答したものとしてマークした）ため、機能を失うことなく、可能な限り高い抽象化レベルを使用する必要があります。

9 java  object-oriented  interfaces 

モデルに（EFを使用して）さまざまなエンティティがあるとします（ユーザー、製品、請求書、注文など）。 エンティティが事前に決定されたセットに属しているアプリケーションでエンティティオブジェクトの要約を印刷できるユーザーコントロールを作成しています。この場合、ユーザーと製品の要約を要約できると言います。 要約にはすべてIDと説明しか含まれないため、このための簡単なインターフェースを作成します。 public interface ISummarizableEntity { public string ID { get; } public string Description { get; } } 次に、問題のエンティティについて、このインターフェイスを実装する部分クラスを作成します。 public partial class User : ISummarizableEntity { public string ID { get{ return UserID.ToString(); } } public string Description { get{ return String.Format("{0} {1} is from {2} and is …

9 c#  design-patterns  interfaces  anti-patterns  data-types 

データベースにアクセスするために、約50のメソッドを持つ大きなインターフェースを使用しています。インターフェイスは私の同僚によって書かれました。これについて話し合いました： 私：50の方法は多すぎます。コードの匂いです。 同僚：それについて私は何をすべきか？あなたはDBアクセスを望んでいます-あなたはそれを持っています。 私：ええ、でもそれは不明確で、将来的にはメンテナンスが困難です。 同僚：わかりました、そうです、それは良くありません。インターフェイスはどのように見えるべきですか？ 私：それぞれ10個のメソッドを持つオブジェクトを返す5つのメソッドはどうでしょうか？ うーん、でもこれは同じでしょ？これは本当により明確になるでしょうか？努力する価値はありますか？ 時々、インターフェースが必要な状況にあり、最初に頭に浮かぶのは、1つの大きなインターフェースです。これの一般的なデザインパターンはありますか？ 更新（SJuanのコメントに対応）： 「メソッドの種類」：データベースからデータを取得するためのインターフェースです。すべてのメソッドの形式は（疑似コード）です。 List<Typename> createTablenameList() メソッドとテーブルは厳密には1対1の関係にあるわけではなく、常にデータベースから得られるある種のリストを取得するという事実に重点が置かれています。

9 design  c++  interfaces 

抽象クラスがあり、このクラスに抽象メソッドのみがあるとします。この抽象クラスは、同じメソッドのみを持つインターフェースとは異なりますか？ 私が知りたいのは、抽象的メンバーのみを持つ抽象クラスと同等のインターフェイスの間に、哲学的、客観的、および基礎となるプログラミング言語の実装に違いがあるかどうかです。

9 programming-languages  object-oriented  interfaces  abstract-class 

少し前に、メソッドパラメータの型、戻り値の型、およびプロパティの型の具体性についての「経験則」を読みましたが、覚えていません。 それはあなたの戻り値の型をできるだけ具体的にそしてあなたのパラメータ型をできるだけ抽象的に保つことについて何かを言った...またはその逆 実際に良いアドバイスなのか悪いアドバイスなのかはわかりませんので、ご自身の考えがあればコメントしてください。 乾杯。

9 object-oriented  programming-practices  interfaces  abstraction 

基本的に「必要なものだけを尋ねる」というインターフェースの設計と消費の原則を使用するようになりました。 たとえば、削除できるタイプがたくさんある場合は、Deletableインターフェイスを作成します。 interface Deletable { void delete(); } 次に、ジェネリッククラスを記述できます。 class Deleter<T extends Deletable> { void delete(T t) { t.delete(); } } コードの他の場所では、クライアントコードのニーズを満たすために可能な限り小さな責任を常に求めます。したがって、を削除するだけでよい場合Fileでも、Deletableではなくを要求しますFile。 この原則は常識であり、すでに受け入れられている名前ですか？物議を醸していますか？それは教科書で議論されていますか？

9 object-oriented  interfaces  solid  single-responsibility