タグ付けされた質問 「object-oriented」

ジェネリック型パラメーター（クラステンプレート、およびパラメーターポリモーフィズムとも呼ばれますが、それぞれの名前には異なる意味があります）をサポートするオブジェクト指向言語では、多くの場合、型パラメーターに型制約を指定して、それを降順にすることができます別のタイプから。たとえば、これはC＃の構文です。 //for classes: class ExampleClass<T> where T : I1 { } //for methods: S ExampleMethod<S>(S value) where S : I2 { ... } これらのインターフェースによって制約されるタイプよりも実際のインターフェースタイプを使用する理由は何ですか？たとえば、メソッドシグネチャを作成する理由は何I2 ExampleMethod(I2 value)ですか？

15 object-oriented  type-systems  generics 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 最近、オブジェクト指向プログラミングを使用して、関数の加算、減算、乗算、除算、およびパワーを備えた計算機を作成するタスクを割り当てられました。このタスクを正常に完了しました。しかし、その後、オブジェクト指向のテクニック/メソッドを使用せずにプログラム全体を再プログラミングしました。 私が気づいたのは、コードの長さが大幅に短縮され、非常に理解しやすいことでした。ここでの私の質問は、オブジェクト指向プログラミングをいつ使用する必要があるかということです。オブジェクト指向言語でオブジェクト指向のないプログラムを作成しても大丈夫ですか？これで私を親切に助けてください。 PS：ここでは、手続き型プログラミングよりもオブジェクト指向プログラミングのメリットを教えてほしいとは思っていません。

15 c++  object-oriented 

次のマップがあります。 Map<Double, List<SoundEvent>> soundEventCells = new HashMap<Double, List<SoundEvent>>(); これHashMapは、double値（ある時点）を対応するSoundEvent「セル」にマップします。各「セル」には、多数のSoundEventsを含めることができます。それがaとして実装されているList<SoundEvent>理由です。それがまさにそれだからです。 コードを読みやすくするために、次のような非常に単純な静的内部クラスを実装することを考えました。 private static class SoundEventCell { private List<SoundEvent> soundEvents = new ArrayList<SoundEvent>(); public void addEvent(SoundEvent event){ soundEvents.add(event); } public int getSize(){ return soundEvents.size(); } public SoundEvent getEvent(int index){ return soundEvents.get(index); } // .. remove() method unneeded } また、マップ宣言（および他の多くのコード）の方が見栄えがよくなります。たとえば、次のようになります。 Map<Double, SoundEventCell> soundEventCells …

15 java  design  object-oriented 

戦略デザインパターン、多くの場合、それらが不足している言語のファーストクラスの機能の代替としてみなされています。 たとえば、機能をオブジェクトに渡したいとします。Javaでは、目的の動作をカプセル化する別のオブジェクトをオブジェクトに渡す必要があります。Rubyなどの言語では、機能自体を匿名関数の形式で渡すだけです。 しかし、私はそれについて考えていたので、多分Strategyは単なる匿名関数が提供する以上のものを提供すると決めました。 これは、オブジェクトがメソッドの実行期間とは無関係に存在する状態を保持できるためです。ただし、匿名関数自体は、関数の実行が終了した時点で存在しなくなる状態のみを保持できます。 ファーストクラスの関数をサポートするオブジェクト指向言語では、関数を使用するよりも戦略パターンに利点がありますか？

15 design-patterns  object-oriented  functions 

顧客が、CMSのeショップで製品に新しいプロパティ（色など）を追加する可能性を望んでいると想像してください。 プロパティをフィールドとして持つ代わりに： class Car extends Product { protected String type; protected int seats; } あなたはおそらく次のようなことをすることになります： class Product { protected String productName; protected Map<String, Property> properties; } class Property { protected String name; protected String value; } つまり、既存の型システムの上に独自の型システムを作成します。これは、ドメイン固有の言語を作成しているように見えるかもしれない、またはできないように思えます。 このアプローチは既知の設計パターンですか？問題を別の方法で解決しますか？ランタイムにフィールドを追加できる言語がありますが、データベースはどうですか？上記のように列を追加/変更するか、何かを使用しますか？ お時間をいただきありがとうございます:)。

15 design-patterns  object-oriented 

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

15 design  object-oriented  interfaces 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 私はJavaで、非常にオブジェクト指向のスタイルで、自分でプログラミングしています。他のプログラマーと仕事をする機会がなかった（少なくとも私はプロではない）。 好奇心から、私は尋ねたいと思いました：プロジェクトでチームと働くことは、特にオブジェクト指向プロジェクトで働くとき、どのように働きますか？ 分割タスクはどのように機能しますか？他のプログラマーが開発したものとうまく機能するものをどのように開発しますか？ プログラマはいつ、どのように通信しますか？ ありがとう

15 object-oriented  teamwork 

私たちの知識領域には、素足で圧力記録プレートの上を歩く人々が含まれます。センサーデータで人間の足が認識されると、「Foot」クラスのオブジェクトを生成する画像認識を行います。 足のデータに対して実行する必要がある計算がいくつかあります。 さて、どのAPIの方が良いでしょう： class Foot : public RecognizedObject { MaxPressureFrame getMaxPressureFrame(); FootAxis getFootAxis(); AnatomicalZones getAnatomicalZones(); // + similar getters for other calculations // ... } または： class Foot : public RecognizedObject { virtual CalculationBase getCalculation(QString aName); // ... } 今、私が思いつくことができる多くの賛否両論がありますが、どれが最も重要かを本当に決めることはできません。これはエンドユーザーアプリケーションであり、当社が販売するソフトウェアライブラリではありません。 何かアドバイス？ 最初のアプローチのプロには次のようなものがあります。 KISS-すべてが非常に具体的です。APIですが、実装も同様です。 強く型付けされた戻り値。 このクラスを継承するのは簡単です。上書きすることはできず、追加するだけです。 APIは非常に閉じられており、何も入れられず、オーバーライドされることもありません。 いくつかの短所： 新しい計算がリストに追加されるたびに、ゲッターの数が増えます APIは変更される可能性が高く、重大な変更が導入された場合、新しいAPIバージョンであるFoot2が必要です。 他のプロジェクトでクラスを再利用する場合、すべての計算が必要になるとは限りません …

15 design  c++  object-oriented  programming-practices  language-agnostic 

私は最近Rubyをいじくり回しており、純粋なオブジェクト指向言語（および純粋ではないものでも）で1つのパラメータのみを取り、連鎖するメソッドを作成することは、スタイル？そうでない場合は、なぜですか？この件に関する詳細かつ厳密な回答をいただければ幸いです。

15 object-oriented  currying  method-chaining 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 デメテルの法則は、結合と結合を備えたオブジェクト指向システムにどのように適用されますか？ 私は「ソフトウェア開発と専門的実践」という本を読んでいて、LoDに関する章に出くわし、その原理がオブジェクト指向システムにどのように適用されるのか興味がありました。

15 object-oriented  design-principles 

この質問に触発されたサードパーティライブラリの使用-常にラッパーを使用しますか？ 人々が実際にサードパーティのライブラリと見なしているものを知りたかった。 PHPの例： Zendフレームワークを使用してアプリケーションを構築している場合、Zendフレームワークライブラリをサードパーティのコードとして扱う必要がありますか？ C＃の例： デスクトップアプリケーションを構築している場合、すべての.Netクラスをサードパーティのコードとして扱う必要がありますか？ Javaの例： JDKのすべてのライブラリをサードパーティライブラリとして扱う必要がありますか？ 一部の人々は、ライブラリが安定していて頻繁に変更されない場合、それをラップする必要はないと言います。ただし、サードパーティのコードに依存するクラスをラップせずにテストする方法はわかりません。

15 programming-languages  design  object-oriented  unit-testing  terminology 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または詳細な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 プログラミング言語は最初は連続して実行されるコード行のみを使用し、抽象化の最初のレベルの1つである関数を含めるように進化したため、さらに抽象化するクラスとオブジェクトが作成されました。次の抽象化レベルは何ですか？ クラスよりもさらに抽象的なものはありますか？

15 programming-languages  object-oriented  language-agnostic  abstraction 

The ThoughtWorks AnthologyのJeff Bay （RTF）によるObject Calisthenicsの規則4に従って、「ファーストクラスのコレクションを使用する」ことをお勧めします。 ルール4：ファーストクラスコレクション このルールの適用は簡単です。コレクションを含むクラスには、他のメンバー変数を含めないでください。各コレクションは独自のクラスにラップされるため、コレクションに関連する動作にはホームがあります。フィルタがこの新しいクラスの一部になることがあります。また、新しいクラスは、2つのグループを結合したり、グループの各要素にルールを適用するなどのアクティビティを処理できます。 これから理解できるのは、コレクションをラップアップする別のクラスを使用し、そのコレクションのデータを追加、削除、変更するメソッドを使用する必要があるということです。 そして、どのデータ型がコレクションに入れられ、何が出てくるかを確認するためにこれが必要です。 （適用可能な言語で）ジェネリックコレクションを使用する場合、この規則に従う必要がありますか？ 重要な意味が欠けている場合は、明確にしてください。

15 object-oriented  generics 

Stack Overflowの仮想関数に関する質問について議論しているときに、純粋な（抽象的な）仮想関数と非純粋な仮想関数の正式な命名法があるかどうか疑問に思いました。 私の情報は常にウィキペディアに依存しており、純粋な仮想関数と非純粋な仮想関数が一般的な用語であると述べています。残念ながら、この記事では、起源や参考文献でバックアップしていません。 純粋で非純粋が一般的な用語であるという私の返信に対するJon Skeetの回答を引用するには： @スティーブン：うーん...多分、しかし私はC ++のコンテキストでそれを見たことがあります。私はそれらについて話している人はC ++のバックグラウンドを持っている可能性が高いと思う:) これらの用語はC ++に由来していましたか、それとも以前の言語で最初に定義または実装されたもので、「公式の」科学用語ですか？ 更新： Frank Sheararは、SIMULA 67 Common Base Language（1970）の説明へのリンクを提供してくれました。この言語は、OOキーワードをclass、object、および正式な概念としての仮想として導入した最初の言語のようです。それはしません定義/純粋な非純粋または抽象的、しかしそれは概念をサポートしています。 誰がそれらを定義しましたか？

15 object-oriented  terminology  naming  history 

最近、コードのレビュー中に、新しい同僚が書いたコードに出会いました。これには匂いのあるパターンが含まれています。同僚の決定は、有名なClean Codeの本（およびおそらく他の同様の本）によって提案されたルールに基づいていると思います。 クラスコンストラクターは有効なオブジェクトの作成に完全に責任があり、その主なタスクはオブジェクトの（プライベート）プロパティの割り当てであることを理解しています。もちろん、オプションのプロパティ値がクラスコンストラクター以外のメソッドによって設定される可能性がありますが、そのような状況はかなりまれです（クラスの残りの部分がそのようなプロパティのオプション性を考慮する場合は、必ずしも間違っているわけではありません）。これは、オブジェクトが常に有効な状態であることを保証できるため、重要です。 しかし、私が遭遇したコードでは、ほとんどのプロパティ値は実際にはコンストラクター以外のメソッドによって設定されています。計算の結果の値は、クラス全体のいくつかのプライベートメソッド内で使用されるプロパティに割り当てられます。著者は、クラスプロパティを、それらを必要とする関数にパラメーター化するのではなく、クラス全体でアクセスできるグローバル変数であるかのように使用しているようです。さらに、クラスのメソッドは特定の順序で呼び出す必要があります。そうしないと、クラスはそれほど多くのことをしないからです。 このコードは、大きなパラメーターリスト（<3パラメーター）を回避するために、メソッドを短くする（<= 5行のコード）アドバイスにインスパイアされており、コンストラクターが機能しないようにする必要がある（何らかの計算を実行するなど）これはオブジェクトの有効性にとって不可欠です）。 もちろん、メソッドが特定の順序で呼び出されない場合に、あらゆる種類の未定義エラーが発生する可能性があることを証明できれば、もちろんこのパターンに反論することができます。ただし、これに対する応答では、プロパティの設定が必要なメソッドが呼び出されたらプロパティを設定する必要があることを検証する検証が追加されると予測しています。 ただし、特定の順序で（手続き的に）呼び出される一連のメソッドではなく、クラスが実際のオブジェクトの青写真になるように、コードを完全に変更することをお勧めします。 私が遭遇したコードは臭いを感じます。実際、クラスプロパティに値を保存するタイミングと、使用する別のメソッドのパラメーターに値を配置するタイミングについては、かなり明確な違いがあると思います。 。この区別の言葉を探しています。

15 object-oriented  clean-code