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

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 私は時々、実際には他の場所に属していないように見えるメソッドと値を保持するのに役立つ「Util」クラスを作成します。しかし、これらのクラスの1つを作成するたびに、「あー、これを後悔するつもりだ...」と思うのは、どこかで悪いことを読んだからです。 しかし、他方では、2つの説得力のある（少なくとも私にとって）ケースがあるようです。 パッケージ内の複数のクラスで使用される実装の秘密 インターフェイスを乱雑にすることなく、クラスを増強するための便利な機能を提供します 私は破壊に向かっていますか？あなたが言うこと ！！リファクタリングする必要がありますか？

14 design  object-oriented  code-smell 

この投稿を改善したいですか？引用や回答が正しい理由の説明など、この質問に対する詳細な回答を提供します。十分な詳細がない回答は、編集または削除できます。 特定のクラスの各インスタンスが一意に識別可能なインスタンスであることを保証するさまざまな方法を探しています。 たとえばName、フィールドを持つクラスがありますname。John Smithに初期化されたNameオブジェクトを取得したら、John Smithという名前でもname別のNameオブジェクトをインスタンス化することはできません。インスタンス化が行われる場合は、元のオブジェクトへの参照を返す必要があります。新しいオブジェクトより。 これを行う1つの方法はMap、現在のすべてのNameオブジェクトを保持する静的ファクトリーを使用することであり、ファクトリーは、John Smithを名前として持つオブジェクトが存在しないことを確認してから、Nameオブジェクト。 私の頭の外で考えることができる別の方法は、Nameクラスに静的なマップを持ち、渡された値がname別のオブジェクトで既に使用されている場合にコンストラクタを呼び出して例外をスローするときに、例外をスローすることを知っていますコンストラクターでは一般的に悪い考えです。 これを達成する他の方法はありますか？

14 java  object-oriented 

この答えに触発された： リスコフの代替原則では 、 サブタイプでは前提条件を強化できません。 サブタイプでは事後条件を弱めることはできません。 スーパータイプの不変式は、サブタイプに保存する必要があります。 履歴制約（「履歴ルール」）。オブジェクトは、そのメソッド（カプセル化）によってのみ変更可能と見なされます。サブタイプはスーパータイプには存在しないメソッドを導入する可能性があるため、これらのメソッドの導入により、スーパータイプでは許可されないサブタイプの状態変更が可能になります。これは履歴制約により禁止されています。 これらの4つのポイントに違反するクラス階層を誰かが投稿し、それに応じてそれらを解決する方法を誰かが投稿することを望んでいました。 階層内の4つのポイントのそれぞれを識別する方法と、それを修正する最良の方法について、教育目的で詳細な説明を探しています。 注： 私は人々が作業するためのコードサンプルを投稿したいと思っていましたが、問題自体は障害のある階層を特定する方法に関するものです:)

14 object-oriented  inheritance  solid  design-principles  liskov-substitution 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新することがありますので、上のトピックソフトウェア工学スタックExchange用。 4年前に閉鎖されました。 私は約250人の開発者がいる中規模の会社で働いています。残念ながら、それらの多くは手続き型の考え方に固執しており、実際にはアプリケーションに豊富なロジックが含まれている場合でも、一部のチームは大きなトランザクションスクリプトアプリケーションを常に提供しています。また、設計の依存関係を管理できず、最終的に別の多数のサービスに依存するサービスになります（クリーンな例 Big Ball of Mudの）。 私の質問は、この種の知識を広める方法を提案できますか？ 問題の表面は、これらのアプリケーションのアーキテクチャと設計が貧弱であることです。別の問題は、あらゆる種類のテストの作成に反対する開発者がいることです。 これを変更するために私がやっていること（しかし、私は失敗しているか、変更が小さすぎます） 設計原則（SOLID、クリーンコードなど）に関するプレゼンテーションの実行。 TDDおよびBDDに関するワークショップ。 コーチングチーム（これには、ソナー、findbugs、jdependおよびその他のツールの使用が含まれます）。 IDEとリファクタリングの話。 私が将来することを考えているいくつかのこと（しかし、それらは良くないかもしれないと心配です） オブジェクト指向のエバンジェリストのチームを編成し、オブジェクト指向の考え方を異なるチームに広めます（これらの人々は、数か月ごとにチームを変更する必要があります）。 設計を批判し、改善を提案するために、設計レビューセッションを実行します（時間の制約のために改善が行われない場合でも、これは役立つと思います） 。 私がコーチするチームで見つけたのは、チームを離れるとすぐに、古いチームに戻るということです。私は彼らと一緒に多くの時間を費やさないことを知っています。通常は1ヶ月です。だから私がやっていることは何でも、それは固執しません。 この質問にフラストレーションがたまっているのは残念ですが、これを書く別の方法は、気が散るまで壁に頭をぶつけることでした。

14 design  learning  object-oriented  architecture 

私は、2k行を超えるコード（および成長中）の巨大なクラスをいくつか持っており、可能であればリファクタリングして、より軽くてクリーンなデザインにしたいと考えています。 それが非常に大きい理由は、主にこれらのクラスがほとんどのメソッドがアクセスする必要があるマップのセットを処理し、メソッドが互いに非常に接続されているためです。 非常に具体的な例を挙げServerます。着信メッセージを処理するというクラスがあります。それはのようなメソッドを持っているjoinChatroom、searchUsers、sendPrivateMessage、これらの方法のなどすべてがマップする操作などusers、chatrooms、servers、... チャットルームに関するメッセージを処理するクラス、ユーザーに関するすべてを処理するクラスなどがあればいいかもしれませんが、ここでの主な問題は、ほとんどのメソッドですべてのマップを使用する必要があることです。これらがすべてServerこれらの共通マップに依存しており、メソッドが互いに非常に関連しているため、今のところそれらはすべてクラスに固執している理由です。 クラスChatroomsを作成する必要がありますが、他の各オブジェクトへの参照があります。クラスは、他のすべてのオブジェクトへの参照などを使用して再びユーザーになります。 私は何か間違ったことをしているような気がします。

14 java  object-oriented  design-patterns  design 

オブジェクト指向は、多くのアルゴリズムを実装する上で非常に役立ちました。ただし、オブジェクト指向言語は「簡単な」アプローチをガイドすることがあり、このアプローチが常に良いものかどうかは疑問です。 オブジェクト指向は、アルゴリズムを高速かつ簡単にコーディングするのに非常に役立ちます。しかし、このOOPは、パフォーマンスに基づいたソフトウェアにとって不利なものになる可能性があります。つまり、プログラムの実行速度です。 たとえば、グラフノードをデータ構造に格納することは、最初は「簡単」に思えますが、Nodeオブジェクトに多くの属性とメソッドが含まれている場合、アルゴリズムが遅くなる可能性はありますか？ 言い換えれば、多くの異なるオブジェクト間の多くの参照、または多くのクラスの多くのメソッドを使用すると、「重い」実装になりますか？

14 object-oriented  algorithms  performance 

プログラムの設計に「マネージャー」クラスが多すぎるとコードの匂いがして、不要な複雑なレイヤーが追加されると聞きます。私にとって、人々が意味のあるコンテキストからオブジェクトを操作および制御するためにマネージャークラスを使用したいのは理にかなっていますが、ソリューションをそれらなしで機能させる方法を理解することは混乱する可能性があります。 マネージャークラスを可能な限り避けるべきですか？また、これらのマネージャーを削除できる一般的な/一般的なケースの代替回避策を実装する方法について、どの記事/論文を読むべきですか？

14 object-oriented  design-patterns  coding 

C＃プロジェクトのクラス階層を設計する必要があります。基本的に、クラスの機能はWinFormsクラスに似ているため、WinFormsツールキットを例に取りましょう。（ただし、WinFormsやWPFは使用できません。） すべてのクラスが提供する必要があるいくつかのコアプロパティと機能があります。寸法、位置、色、可視性（true / false）、Drawメソッドなど。 設計上のアドバイスが必要です。抽象ベースクラスと実際には型ではなく、動作に似たインターフェイスを持つ設計を使用しました。これは良いデザインですか？そうでない場合、より良いデザインになります。 コードは次のようになります。 abstract class Control { public int Width { get; set; } public int Height { get; set; } public int BackColor { get; set; } public int X { get; set; } public int Y { get; set; } public int BorderWidth { get; …

14 c#  object-oriented  design-patterns  class-design 

今日、私は基本的protectedにC ++コードでメソッドを使用しないことに気付きました。親の非パブリックメソッドを呼び出す必要性をほとんど感じないからです。テンプレートメソッドパターンではJavaでprotectedを使用していますが、C ++でプライベートメソッドをオーバーライドできるため、ここでも必要protectedありません。 それではprotected、C ++コードでメソッドを使用する実際のシナリオは何ですか？ （私は一般的に実装の継承があまり好きではないことに注意してください、それは多くを説明するかもしれません...）

14 c++  object-oriented  inheritance  access-modifiers 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 オブジェクト指向の背後にある元の概念は、データの状態を保護する方法で複数のシステム間でデータのメッセージングを処理するためのより良いアーキテクチャを見つけることであったことをどこかで読んだことを覚えています。今はおそらく貧弱な言い換えですが、オブジェクトの類推（バイク、車、人など）なしでオブジェクト指向を教える方法があり、代わりにメッセージングの側面に焦点を当てているのだろうかと思いました。記事、リンク、書籍などがある場合、それは役立ちます。

14 object-oriented 

私はオブジェクト指向とベクターベースのデザインの間で引き裂かれています。オブジェクトがアーキテクチャ全体に与える能力、構造、安全性が大好きです。しかし同時に、速度は私にとって非常に重要であり、配列に単純なフロート変数があると、MatlabやPythonのnumpyなどのベクトルベースの言語/ライブラリで非常に役立ちます。 これが私のポイントを説明するために書いたコードです 問題：トウのボラティリティ値を追加します。xとyが2つのボラティリティ数である場合、ボラティリティの合計は（x ^ 2 + y ^ 2）^ 0.5です（特定の数学的条件を仮定しますが、ここでは重要ではありません）。 この操作を非常に高速に実行すると同時に、人々がボラティリティを間違った方法（x + y）で追加しないようにする必要があります。これらは両方とも重要です。 オブジェクト指向ベースのデザインは次のようになります。 from datetime import datetime from pandas import * class Volatility: def __init__(self,value): self.value = value def __str__(self): return "Volatility: "+ str(self.value) def __add__(self,other): return Volatility(pow(self.value*self.value + other.value*other.value, 0.5)) （余談：Pythonを初めて使用する場合__add__は、単なる+演算子をオーバーライドする関数です） ボラティリティ値のトウリストを追加するとしましょう n = 1000000 vs1 = Series(map(lambda …

14 design-patterns  object-oriented  python  speed 

OOPで開発する場合、変更できないライブラリによってインターフェイス/コントラクトが与えられることがあります。このインターフェイスをJと呼びましょう。 これで、このインターフェイスを実装するオブジェクトを消費するクラスAのオブジェクトができました。Inside Aインターフェイスの定義のほんの一部だけが必要です。オブジェクトクラスの一部はプロジェクト中に私が作成します（そのうちの1つをタイプDと呼びましょう）。したがって、インターフェイスJ内のすべての実装にオーバーヘッドがあります。 インターフェイスJの機能のサブセットを実装したいのですが、これまでのソリューションでは満足できません。 Jのあらゆる側面を実装し、「notImplementedExceptions」をスローすると、ユーザーにオブジェクトの情報が誤って通知されます。タイプDのオブジェクトはインターフェースJに準拠しているように見えますが、 J）オブジェクトの整合性に依存することはできません。 新しく定義されたインターフェイスを実装すると、インターフェイスJのみを実装するオブジェクトを使用できなくなりますが、インターフェイスJは自分のインターフェイスと完全に互換性があります。 カスタムオブジェクトにインターフェイスJを実装させると、この機能をすべて必要としないため、かなりのオーバーヘッドが発生します。 インターフェースJを変更できた場合、インターフェースJの機能のこのサブセットを持つ「スーパーインターフェース」Kを作成し、インターフェースJをインターフェースKから継承させます。しかし、インターフェースJを変更することはできません。 この問題のオブジェクト指向ソリューションとは何ですか？最良のソリューションは、まだ「単なる」インターフェースJを実装していますか？または、インターフェイスを変更せずに「スーパークラス化」するOOPの方法はありますか？

14 object-oriented  interfaces 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 2年前に閉店。 仕事中のコーダーの本で、ジョー・アームストロングは次のように述べています。 再利用性の欠如は、関数型言語ではなくオブジェクト指向言語で発生すると思います。オブジェクト指向言語の問題は、それらが持ち歩くこの暗黙の環境をすべて持っているためです。バナナが欲しかったのに、バナナとジャングル全体を持ったゴリラが手に入れた ここではあまりわかりません。問題がバナナを取得することである場合、関数 'getBanana'の背後にあるすべてのロジックをカプセル化できます。猿とジャングルはこの文脈にどのように関係していますか。誰かの書き込みがあるという事実を証明、と言う、方法を理解しやすくして、問題を説明するコードスニペットでしたBananaオブジェクトが必要とするMonkeyとJungle、開始されるようにしてくださいオブジェクトを？

14 object-oriented  functional-programming 

クラスLinkedListは、add_first（）、add_last（）、add_after（）、remove_first（）、remove_last（）、remove（）などの関数とともに存在します 現在、push（）、pop（）、peek（）、またはtop（）などの機能を提供するクラスStackがあり、これらのメソッドを実装するためにLinkedListクラスメソッドを拡張しています。これは、リスコフ代替原理の違反ですか？ たとえば、リンクリストのn番目の位置にノードを追加する場合のadd_after（）の場合を考えます。これは基本クラスで実行できますが、Stackクラスでは実行できません。ここで事後条件が弱くなっていますか、それともadd_after（）メソッドを変更してスタックの一番上に追加しますか？ また、違反ではない場合、これは悪い設計ですか？そして、LinkedListクラスを使用してStack機能をどのように実装しますか？

13 design  object-oriented  object-oriented-design  solid  liskov-substitution 

このページは、次の引数を使用して継承よりも構成を推奨しています（私の言葉で言い換えます）。 サブクラスでオーバーライドされていないスーパークラスのメソッドのシグネチャの変更により、継承を使用するときに多くの場所で追加の変更が発生します。ただし、Compositionを使用する場合、必要な追加の変更は1つの場所であるサブクラスのみです。 それが本当に継承よりも構成を優先する唯一の理由ですか？その場合、サブクラスが実装を変更しない（つまり、サブクラスにダミーのオーバーライドを設定する）場合でも、スーパークラスのすべてのメソッドをオーバーライドすることを推奨するコーディングスタイルを適用することで、この問題を簡単に軽減できるためです。ここに何かが足りませんか？

13 object-oriented  inheritance  composition