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

インターフェイスへのプログラミングなど、インターフェイスに関連する設計上の考慮事項に関する質問。

3
ジェネリックと共通のインターフェース?
前回ジェネリッククラスを書いたときのことは覚えていません。何かを考えてから必要になると思うたびに、結論を出します。 この質問に対する2番目の答えは、明確化を求めることでした(まだコメントできないので、新しい質問をしました)。 ジェネリックが必要な場合の例として、与えられたコードを取り上げましょう。 public class Repository<T> where T : class, IBusinessOBject { T Get(int id) void Save(T obj); void Delete(T obj); } 型の制約があります: IBusinessObject 私の通常の考え方は次のとおりです。クラスはuse IBusinessObjectに制限されているため、これを使用するクラスもそうRepositoryです。リポジトリはこれらを保存します。IBusinessObjectほとんどの場合、これのクライアントはインターフェースをRepository介してオブジェクトを取得および使用したいと思うでしょうIBusinessObject。それではなぜ public class Repository { IBusinessOBject Get(int id) void Save(IBusinessOBject obj); void Delete(IBusinessOBject obj); } また、この例は、単なる別のコレクションタイプであり、ジェネリックコレクションはクラシックであるため、良くありません。この場合、型制約も奇妙に見えます。 実際、この例class Repository<T> where T : class, IBusinessbBjectはclass BusinessObjectRepository私によく似ています。これはジェネリックが修正するために作られたものです。 要点は、ジェネリックはコレクション以外のすべてに適しているので、クラス内でジェネリック型パラメーターの代わりにこの型制約を使用するように、型制約を特殊化することはありませんか?

4
誰がインターフェースを拡張しますか?なぜ?
知る限り、私のクラスのextends親クラスとimplementsインターフェース。しかし、私はを使用できない状況に出くわしますimplements SomeInterface。これは、ジェネリック型の宣言です。例えば: public interface CallsForGrow {...} public class GrowingArrayList <T implements CallsForGrow> // BAD, won't work! extends ArrayList<T> ここでの使用implementsは構文的に禁止されています。最初に、<>内でインターフェイスを使用することはまったく禁止されていると考えましたが、そうではありません。可能ですが、extends代わりに使用するだけ ですimplements。その結果、インターフェイスを「拡張」しています。この別の例は動作します: public interface CallsForGrow {...} public class GrowingArrayList <T extends CallsForGrow> // this works! extends ArrayList<T> 私にはそれは構文上の矛盾と思われます。しかし、Java 6の細かい部分を理解していないのかもしれません。インターフェイスを拡張する必要がある他の場所はありますか?私が拡張するつもりのインターフェースには、いくつかの特別な機能が必要ですか?

6
実装へのインターフェイス参照をキャストすることで、著者は何を意味しますか?
私は現在C#をマスターしようとしていますが、Gary McLean HallによるC#を介してAdaptive Codeを読んでいます。 彼はパターンとアンチパターンについて書いています。実装とインターフェースの部分で、彼は次のように書いています。 インターフェイスへのプログラミングの概念に慣れていない開発者は、多くの場合、インターフェイスの背後にあるものを手放すのが困難です。 コンパイル時に、インターフェースのクライアントは、使用しているインターフェースの実装を把握していないはずです。このような知識は、クライアントをインターフェイスの特定の実装に結び付ける誤った仮定につながる可能性があります。 クラスが永続ストレージにレコードを保存する必要がある一般的な例を想像してください。そのために、インターフェイスに正しく委任します。これにより、使用される永続的なストレージメカニズムの詳細が隠されます。ただし、実行時にどのインターフェイスの実装が使用されているかについて仮定するのは正しくありません。たとえば、インターフェイス参照を実装にキャストすることは常に悪い考えです。 それは言葉の壁か、私の経験不足かもしれませんが、それが何を意味するのかよくわかりません。ここに私が理解していることがあります: C#を練習するための自由時間の楽しいプロジェクトがあります。そこでクラスがあります: public class SomeClass... このクラスは多くの場所で使用されています。C#を学習しているときに、インターフェイスで抽象化する方がよいことを読んだので、次のようにしました。 public interface ISomeClass <- Here I made a "contract" of all the public methods and properties SomeClass needs to have. public class SomeClass : ISomeClass <- Same as before. All implementation here. そこで、いくつかのクラス参照をすべて調べて、それらをISomeClassに置き換えました。 私が書いた建設を除いて: ISomeClass myClass …

2
最小驚きの原理(POLA)とインターフェース
四半世紀前に私がC ++を学んでいたとき、インターフェースは寛容であるべきだと教えられました。消費者は代わりにソースやドキュメントにアクセスできないかもしれないので、メソッドが呼び出される順番を気にしないでくださいこの。 しかし、私がジュニアプログラマーや上級開発者を指導したときはいつでも、彼らは驚いたことに反応し、これは本当にこれが本当のことなのか、それとも流行から外れたのかと疑問に思いました。 泥のように明確ですか? これらのメソッド(データファイルを作成するための)とのインターフェイスを検討してください。 OpenFile SetHeaderString WriteDataLine SetTrailerString CloseFile もちろん、これらを順番に実行することもできますが、ファイル名(考えてみてくださいa.out)や、含まれているヘッダーとトレーラーの文字列については気にしないと言って、単に呼び出すことができますAddDataLine。 それほど極端ではない例として、ヘッダーとトレーラーを省略する場合があります。 さらに、ファイルを開く前にヘッダーとトレーラーの文字列を設定することもできます。 これは認識されているインターフェイス設計の原則ですか、それとも名前が与えられる前のPOLAの方法ですか? NBは、このインターフェイスの詳細に動揺することはありません。これは、この質問のための単なる例です。

5
列挙型は脆弱なインターフェースを作成しますか?
以下の例を考えてください。ColorChoice列挙の変更は、すべてのIWindowColorサブクラスに影響します。 列挙型は脆弱なインターフェースを引き起こす傾向がありますか?多態的な柔軟性を可能にする列挙型よりも優れたものはありますか? enum class ColorChoice { Blue = 0, Red = 1 }; class IWindowColor { public: ColorChoice getColor() const=0; void setColor( const ColorChoice value )=0; }; 編集:私の例として色を使用して申し訳ありませんが、それは質問についてのものではありません。これは、ニシンを避け、柔軟性の意味についてより多くの情報を提供する別の例です。 enum class CharacterType { orc = 0, elf = 1 }; class ISomethingThatNeedsToKnowWhatTypeOfCharacter { public: CharacterType getCharacterType() const; void setCharacterType( const CharacterType …

4
フロントエンド開発者は、バックエンド開発者向けにJSON形式を指定する必要がありますか?
私はプロジェクトでフロントエンドの役割を担っています。PHPがJavaScriptに返すJSONの正確な形式をバックエンドチームメイトに指定する必要がありますか? たとえば、ここで説明する形式と同様の形式を使用する必要があることを伝えます。 フロントエンドで使用するためのJSONを適切に構成する方法 または、自分の役割を可能な限り無菌状態に保ち、単にバックエンドインターフェイスから必要な入力と出力を言葉で説明する必要がありますか?(もちろん、これが発生した場合、異なるデータ構造形式を処理することは私の側でより困難になる可能性があります)

5
インターフェイスを使用する場合(ユニットテスト、IoC?)
私はここで男子学生の間違いを犯したのではないかと疑い、明確化を求めています。私のソリューションの多くのクラス(C#)-あえて過半数を言う-私は対応するインターフェースを書くことになりました。たとえば、「ICalculator」インターフェースと、それを実装する「Calculator」クラス。ただし、その計算機を別の実装に置き換えることは決してないでしょう。また、これらのクラスのほとんどは、依存関係と同じプロジェクトに存在します。実際に必要なのはinternal、必要なだけですが、publicそれぞれのインターフェイスを実装する副作用として存在することになりました。 すべてのインターフェイスを作成するこのプラクティスは、いくつかの偽りに起因すると思います。 1)元々、ユニットテストモックを作成するにはインターフェイスが必要だと思っていました(私はMoqを使用しています)が、その後、そのメンバーがvirtualであり、パラメーターのないコンストラクターがある場合、クラスをモックできることがわかりました(私が間違っている)。 2)IoCフレームワーク(Castle Windsor)にクラスを登録するにはインターフェースが必要だと当初考えていました。例えば Container.Register(Component.For<ICalculator>().ImplementedBy<Calculator>()... 実際、私はそれ自体に対して具体的な型を登録することができました: Container.Register(Component.For<Calculator>().ImplementedBy<Calculator>()... 3)依存性注入のコンストラクタパラメーターなどのインターフェイスを使用すると、「疎結合」になります。 それで、私はインターフェースに夢中になりましたか?!私は、あなたが「通常」インターフェースを使用するシナリオを知っています。例えば、パブリックAPIを公開したり、「プラグイン可能な」機能のようなもののために。私のソリューションには、そのようなユースケースに適合する少数のクラスがありますが、他のすべてのインターフェースは不要であり、削除する必要があるのでしょうか?上記の3)に関して、これを行う場合、「疎結合」に違反しませんか? 編集:-Moqで遊んでいるだけであり、それらをモックできるようにするには、メソッドがパブリックで仮想であり、パブリックのパラメータレスコンストラクターを必要とするようです。それで、私は内部クラスを持つことができないように見えますか?

4
クラスファイルとインターフェイスファイルを整理するにはどうすればよいですか?
OK ..すべての議論の後、私が扱っている具体的な例をより良く反映するために質問を少し変更しています。 私は2つのクラスModelOneとを持っていますModelTwo。これらのクラスは同様のタイプの機能を実行しますが、互いに無関係です。しかし、私はCommonFunc両方ModelOneで実装されているいくつかのパブリック機能を含む3番目のクラスをModelTwo持っていDRYます。2つのモデルはModelMainクラス内でインスタンス化されます(それ自体はより高いレベルなどでインスタンス化されますが、このレベルで停止しています)。 私が使用しているIoCコンテナはMicrosoft Unityです。私はそれの専門家であるふりはしませんが、インターフェイスのクラスとコンテナをクラスに登録し、具体的なクラスが必要な場合は、特定のインターフェイスに一致するオブジェクトをIoCコンテナに尋ねることです。これは、Unityからインスタンス化するすべてのオブジェクトに対して、一致するインターフェイスが必要であることを意味します。各クラスは異なる(重複しない)機能を実行するため、これは、インターフェイスとクラス1の比率が1:1であることを意味します。しかし、それは私が書くすべてのクラスのためにインターフェースを慎重に書いているという意味ではありません。 したがって、コード的には2になります。 public interface ICommonFunc { } public interface IModelOne { ICommonFunc Common { get; } .. } public interface IModelTwo { ICommonFunc Common { get; } .. } public interface IModelMain { IModelOne One { get; } IModelTwo Two { get; } .. } public …

5
C#インターフェースでのキーワード「使用」の使用
C#を使用してコードを記述し、Visual Studio 2010を使用してインターフェイスを定義すると、常に(使用例に示すように)多数の "using"ステートメントが含まれます。 using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace TestEngine.TestNameSpace { interface ITest1 { bool testMethod(int xyz); } } これらが何のためにあり、本当に必要なのだろうか。これらは省略できますか?インターフェイスの説明でこれらの部分を使用している場合にのみ必要ですか?

2
PHPの違法:OOP設計の理由はありますか?
以下のインターフェースの継承はPHPでは違法ですが、実際にはかなり役に立つと思います。以下のデザインに実際のアンチパターンまたは文書化された問題がありますか?PHPは私を保護していますか? <?php /** * Marker interface */ interface IConfig {} /** * An api sdk tool */ interface IApi { public __construct(IConfig $cfg); } /** * Api configuration specific to http */ interface IHttpConfig extends IConfig { public getSomeNiceHttpSpecificFeature(); } /** * Illegal, but would be really nice to have. …

5
オブジェクトを同じメソッドに2回渡すか、結合されたインターフェイスで統合しますか?
デジタルボードと通信した後にデータファイルを作成する方法があります。 CreateDataFile(IFileAccess boardFileAccess, IMeasurer boardMeasurer) ここではboardFileAccessとboardMeasurerの同じインスタンスですBoardその実装するオブジェクトの両方IFileAccessとIMeasurer。IMeasurerこの場合、ボード上の1つのピンをアクティブに設定して簡単な測定を行う単一の方法に使用されます。この測定からのデータは、を使用してボードにローカルに保存されIFileAccessます。Board別のプロジェクトにあります。 私はCreateDataFile、簡単な測定を行ってからデータを保存することで1つのことを行うという結論に達しました。同じ方法で両方を行うことは、このコードを使用して測定を行ってファイルに書き込む必要がある他の人にとってより直感的です個別のメソッド呼び出しとして。 私には、同じオブジェクトをメソッドに2回渡すのは厄介に思えます。IDataFileCreator拡張IFileAccessし、必要なメソッドを呼び出すだけのインスタンスをIMeasurer含む実装を持つローカルインターフェイスを作成することを検討しました。同じボードオブジェクトが常に測定とファイル書き込みに使用されることを考えると、同じオブジェクトをメソッドに2回渡すのは悪い習慣ですか?もしそうなら、ローカルインターフェイスと実装を使用して適切なソリューションですか?BoardBoard

3
疎結合を実現するために、インターフェイスがスーパークラスよりも役立つのはなぜですか?
(この質問の目的のために、私が「インターフェース」と言うとき、私は言葉の他の意味での「インターフェース」ではなく、言語構成体を意味しinterfaceます、すなわち、クラスが通信し、操作します。) オブジェクトを具象型ではなく抽象化に依存させることで、疎結合を実現できます。 これは、2つの主な理由のための疎結合することができます:1 -抽象化が依存するコードが少なく破るためにある意味、具体的なタイプより変更になりにくいです。2 -彼らはすべての抽象化をフィットするので別の具体的なタイプは、実行時に使用することができます。既存の依存コードを変更する必要なしに、新しいコンクリートタイプを後で追加することもできます。 たとえば、あるクラスCarと2つのサブクラスVolvoとを考えMazdaます。 コードがに依存している場合、ランタイム中にCara Volvoまたはaを使用できMazdaます。また、後で追加のサブクラスを追加して、依存コードを変更する必要はありません。 また、Car-抽象化である-は、Volvoまたはよりも変更される可能性が低いMazdaです。車はかなり以前から一般的に同じでしたが、ボルボとマツダははるかに変わる可能性が高いです。すなわち、抽象化は具体的な型よりも安定しています。 これはすべて、疎結合とは何か、そして具体的ではなく抽象化に依存することによってどのように達成されるかを理解していることを示すことでした。(不正確なものを書いた場合はそう言ってください)。 私が理解していないのはこれです: 抽象化は、スーパークラスまたはインターフェースにすることができます。 もしそうなら、なぜインターフェイスは疎結合を可能にする能力で特に称賛されていますか?スーパークラスを使用することとどう違うかわかりません。 私が見る唯一の違いは次のとおりです。1-インターフェースは単一継承によって制限されませんが、それは疎結合のトピックとはあまり関係がありません。2-インターフェースには実装ロジックがないため、より「抽象的」です。しかし、それでも、なぜそんなに大きな違いがあるのか​​わかりません。 単純なスーパークラスはそうではないが、インターフェイスが疎結合を可能にするのに優れていると言われている理由を説明してください。

5
インターフェイスに代わる機能プログラミングとは何ですか?
「機能的な」スタイルでプログラミングしたい場合、インターフェイスを何に置き換えますか? interface IFace { string Name { get; set; } int Id { get; } } class Foo : IFace { ... } たぶんTuple<>? Tuple<Func<string> /*get_Name*/, Action<String> /*set_Name*/, Func<int> /*get_Id*/> Foo; そもそもインターフェイスを使用している唯一の理由は、特定のプロパティ/メソッドを常に利用できるようにしたいからです。 編集:私が考えている/試みていることについてのいくつかの詳細。 たとえば、次の3つの関数を取るメソッドがあります。 static class Blarf { public static void DoSomething(Func<string> getName, Action<string> setName, Func<int> getId); } Bar私のインスタンスでこのメソッドを使用できます: class …

6
抽象クラス、インターフェースの違い、およびそれらをいつ使用するか
最近、私は頭をOOPに巻きつけ始めました。そして今、抽象クラスとインターフェースの違いについて読むほど、混乱してしまいます。これまでのところ、どちらもインスタンス化できません。インターフェースは多かれ少なかれ構造的な青写真であり、スケルトンを決定し、抽象は部分的にコードを実装できることによって異なります。 私の特定の状況を通して、これらについてもっと学びたいです。背景情報をもう少し知りたい場合の最初の質問へのリンクは次のとおりです。新しいクラスに適した設計モデルは何ですか? ここに私が作成した2つのクラスがあります。 class Ad { $title; $description $price; function get_data($website){ } function validate_price(){ } } class calendar_event { $title; $description $start_date; function get_data($website){ //guts } function validate_dates(){ //guts } } ご覧のとおり、これらのクラスはほぼ同じです。ここに示されているが、他の機能があるではないlike get_zip()、save_to_database()私のクラスで共通しています。また、すべての一般的なメソッドと、もちろんそれらのクラスに固有のプロパティ(マイレージ、重量など)を持つ他のクラスのCarsとPetsを追加しました。 現在、DRYの原則に違反しており、複数のファイルにわたって同じコードを管理および変更しています。私は、ボート、馬、またはその他のようなクラスを増やすつもりです。 これは、インターフェイスまたは抽象クラスを使用する場所ですか?抽象クラスについて理解していることから、抽象クラスにすべての共通要素が組み込まれたテンプレートとしてスーパークラスを使用し、将来のクラスで特に必要な項目のみを追加します。例えば: abstract class content { $title; $description function get_data($website){ } function common_function2() { } function common_function3() …

6
インターフェイスメソッドを抽象メソッドと見なすことはできますか?
私はそれについて考えていた、と私はいくつかの疑問がありました。 たとえば、インターフェイスを宣言するとき: public interface MyInterface { public void method1(); public void method2(); } これらのインターフェイスメソッドは抽象と見なされますか?つまり、抽象メソッドの概念は次のとおりです。 抽象メソッドは宣言されたメソッドですが、実装は含まれていません。 だから、これらのメソッドは抽象的と見なすことができますか?私はabstract言葉を使っていないので、それらは「純粋な」抽象メソッドではありませんが、概念的にはそうであるように見えます。 それについて何か教えていただけますか? ありがとう。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.