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

オブジェクト指向設計とは、ソフトウェアの問題を解決するために、相互作用するオブジェクトのシステムを計画するプロセスです。

10
コンストラクタなしで生きることはできますか？
何らかの理由で、すべてのオブジェクトがこの方法で作成されるとしましょう$ obj = CLASS :: getInstance（）。次に、セッターを使用して依存関係を注入し、$ obj-> initInstance（）を使用して初期化を開始します。コンストラクターをまったく使用しない場合、解決できない実際のトラブルや状況はありますか？ PSこの方法でオブジェクトを作成する理由は、いくつかのルールに従ってgetInstance（）内のクラスを置き換えることができるからです。 私はPHPで働いています、それが問題なら
12
オブジェクト指向設計
次のものがあるとします： +--------+ +------+ | Animal | | Food | +-+------+ +----+-+ ^ ^ | | | | +------+ +-------+ | Deer | | Grass | +------+ +-------+ Deerから継承しAnimal、からGrass継承しFoodます。 ここまでは順調ですね。Animalオブジェクトはオブジェクトを食べることができFoodます。 それでは少し混ぜましょう。Lionを継承するを追加しましょうAnimal。 +--------+ +------+ | Animal | | Food | +-+-----++ +----+-+ ^ ^ ^ | | | | | | +------+ …
6
オブジェクトは自身のIDを知っている必要がありますか？
obj.idはかなり一般的であり、オブジェクトがそれ自体について知ることができる範囲内に収まるようです。私は自分のオブジェクトが自分のIDを知っている必要がある理由を尋ねています。 それを持っている理由がないようですか？それが存在する主な理由の1つはそれを取得することです。したがって、私のリポジトリはそれを知る必要があり、したがってデータベースとの対話に使用する必要があります。 また、IDがペイロードに収まらないように見えるRESTful APIのオブジェクトをJSONにシリアル化したいという問題に一度遭遇しました。 オブジェクトは自身のIDを知る必要がありますか？なぜですか？ 更新： 用語 id：オブジェクトの識別子属性。データベース用語では、代理キーは自然キーではありません。 オブジェクト：エンティティ、またはシステム内で一意に識別可能なオブジェクト。
4
定義としてC＃の抽象クラスを使用する
C ++開発者として、私はC ++ヘッダーファイルに非常に慣れており、コード内に何らかの「ドキュメント」を強制することが有益であることがわかりました。そのため、私は通常、C＃コードを読む必要があるときに悪い時間を過ごします。私が作業しているクラスのそのようなメンタルマップを持っていません。 ソフトウェアエンジニアとして、プログラムのフレームワークを設計していると仮定しましょう。C ++ヘッダーで行うのと同様に、すべてのクラスを抽象的な未実装クラスとして定義し、開発者に実装させるのはあまりにもクレイジーでしょうか？ 誰かがこれをひどい解決策だと思う理由がいくつかあるのではないかと推測していますが、その理由はわかりません。このようなソリューションでは、何を考慮する必要がありますか？
9
いつプライベート/内部クラスを使用すべきですか？
明確にするために、私が尋ねているのは public class A{ private/*or public*/ B b; } 対 public class A{ private/*or public*/ class B{ .... } } どちらか一方を使用するいくつかの理由を明確に考えることができますが、私が本当に見たいのは、長所と短所が単なる学術的ではないことを示す説得力のある例です。
11
同じオブジェクトへの2つの参照が必要になるのはいつですか？
特にJavaでは、他の言語でも同様です。同じオブジェクトへの2つの参照がいつ役立つのでしょうか。 例： Dog a = new Dog(); Dob b = a; これが役立つ状況はありますか？でa表されるオブジェクトとやり取りしたいときはいつでも、これが使用するのに好ましいソリューションになるのはなぜaですか？
3
共通の機能を共有するWindowsフォームに最適な設計
過去に、アプリケーションでWindowsフォームの拡張を許可するために継承を使用しました。すべてのフォームに共通のコントロール、アートワーク、および機能がある場合、共通のコントロールと機能を実装する基本フォームを作成し、他のコントロールがその基本フォームから継承できるようにします。ただし、その設計にはいくつかの問題があります。 コントロールは一度に1つのコンテナにしか入れることができないため、静的なコントロールは扱いにくいものになります。たとえば、このクラスの他の（派生）インスタンスがすべて同じTreeViewを変更および表示できるように、保護および静的にするTreeViewを含むBaseFormというベースフォームがあるとします。TreeViewは一度に1つのコンテナにしか入れることができないため、これはBaseFormから継承する複数のクラスでは機能しません。おそらく初期化された最後のフォームにあります。すべてのインスタンスはコントロールを編集できますが、一度に1つだけ表示されます。もちろん、回避策はありますが、それらはすべていものです。（これは私にとって本当に悪い設計のようです。なぜ複数のコンテナが同じオブジェクトへのポインタを格納できないのでしょうか？とにかく、それがそうです。） フォーム間の状態、つまり、ボタンの状態、ラベルテキストなど、グローバル変数を使用して、Loadの状態をリセットする必要があります。 これは、Visual Studioのデザイナーによって実際にサポートされていません。 使用するのに優れた、それでも簡単に保守可能な設計はありますか？または、フォームの継承が依然として最善のアプローチですか？ 更新 MVCからMVPに、オブザーバーパターンからイベントパターンに移動しました。ここに私が今考えているものがあります、批評してください： BaseFormクラスには、コントロールと、それらのコントロールに接続されたイベントのみが含まれます。それらを処理するために何らかのロジックが必要なすべてのイベントは、すぐにBaseFormPresenterクラスに渡されます。このクラスは、UIからのデータを処理し、論理演算を実行してから、BaseFormModelを更新します。モデルは、状態の変更時に発生するイベントをPresenterクラスに公開し、Presenterクラスはサブスクライブ（または監視）します。プレゼンターはイベント通知を受け取ると、ロジックを実行し、それに応じてビューを変更します。 メモリには各Modelクラスが1つしかありませんが、BaseFormの多くのインスタンス、したがってBaseFormPresenterが存在する可能性があります。これにより、BaseFormの各インスタンスを同じデータモデルに同期するという私の問題が解決します。 質問： どのレイヤーが最後に押されたボタンのようなものを保存する必要があるので、フォーム間でユーザーのために強調表示し続けることができます（CSSメニューのように）？ このデザインを批判してください。ご協力いただきありがとうございます！
3
パブリックメンバーを仮想化または抽象化しないでください-本当にですか？
2000年代に、私の同僚は、パブリックメソッドを仮想または抽象化するのはアンチパターンだと言っていました。 たとえば、彼は次のようなクラスはうまく設計されていないと考えました。 public abstract class PublicAbstractOrVirtual { public abstract void Method1(string argument); public virtual void Method2(string argument) { if (argument == null) throw new ArgumentNullException(nameof(argument)); // default implementation } } 彼は言った 実装Method1およびオーバーライドする派生クラスの開発者はMethod2、引数の検証を繰り返す必要があります。 場合には、基本クラスの開発者は、カスタマイズの一部の周りに何かを追加することを決定しMethod1たりMethod2、後で、彼はそれを行うことはできません。 代わりに、私の同僚がこのアプローチを提案しました： public abstract class ProtectedAbstractOrVirtual { public void Method1(string argument) { if (argument == null) throw new …
9
init（）メソッドはコード臭いですか？
init()型のメソッドを宣言する目的はありますか？ 私はコンストラクタよりも優先init()すべきかどうか、または宣言を避ける方法をinit()尋ねていません。 メソッドを宣言する背後に何らかの理由があるのかinit()（それがどれほど一般的かを見て）、それがコードのにおいであり、避けるべきかどうかを尋ねています。 init()イディオムは非常に一般的ですが、私は、任意の真のメリットを見ていません。 メソッドによる初期化を促進する型について話している： class Demo { public void init() { //... } } これはいつプロダクションコードで使用されますか？ コンストラクターがオブジェクトを完全に初期化せず、部分的に作成されたオブジェクトを生成することを示唆しているため、コードの匂いがするかもしれません。状態が設定されていない場合、オブジェクトは存在しないはずです。 これは、エンタープライズアプリケーションの意味で、生産をスピードアップするために使用されるある種の手法の一部である可能性があると信じさせてくれます。それは私がそのようなイディオムを持つことを考えることができる唯一の論理的な理由です。
4
インスタンス変数が多すぎるとコードが重複しますか？
パターンのリファクタリングによると： クラスが多くのことをしようとすると、多くの場合、インスタンス変数が多すぎます。クラスのインスタンス変数が多すぎる場合、複製されたコードはそれほど遅れることはありません。 インスタンス変数が多すぎるとコードが重複しますか？
4
データベースの設計が不十分なリレーショナルデータベース駆動型アプリケーションでより良いオブジェクト指向コードを作成する方法
私は主に、すべてのページに複数のテーブルとそれらのテーブルに適用されるフィルターがある類似したページの束で構成されるJava Webアプリケーションを作成しています。これらのテーブルのデータは、SQLデータベースから取得されます。 私はmyBatisをORMとして使用していますが、データベースの設計が貧弱で、mybatisはデータベース指向のツールであるため、私の場合はこれが最良の選択ではないかもしれません。 データベースの設計が貧弱であるため、クエリが非常に異なる可能性があるため、類似したものに対して異なるクエリを作成する必要があるため、多くの重複コードを記述していることがわかりました。つまり、クエリを簡単にパラメータ化することはできません。これは私のコードに伝播し、単純なループでテーブルの列に行を入力する代わりに、次のようなコードがあります： 取得Aデータ（P1、...、PI）; get B Data（p1、...、pi）; Cデータの取得（p1、...、pi）; Dデータの取得（p1、...、pi）; ... そして、異なる列を持つ異なるテーブルがある場合、これはすぐに爆発します。 また、ページ内のhtml要素へのオブジェクトのマッピングである「ウィケット」を使用しているという事実も複雑さを増しています。そのため、私のJavaコードはデータベースとフロントエンドの間のアダプターになります。これにより、ロジックが混在した大量の配線、定型コードが作成されます。 正しい解決策は、ORMマッパーを、dbへのより均質なインターフェースを提供する追加レイヤーでラップすることでしょうか、または私が書いているこのスパゲッティコードを処理するより良い方法はありますか？ 編集：データベースに関する詳細情報 データベースは、主に電話情報を保持しています。貧弱なデザインは以下で構成されています： ドメインの知識とは関係のない人工キーを主キーとして持つテーブル。 一意のトリガー、チェック、または外部キーは一切ありません。 さまざまなレコードのさまざまな概念に一致する一般的な名前のフィールド。 条件が異なる他のテーブルと交差することによってのみ分類できるレコード。 文字列として保存される数値または日付である列。 まとめると、散らかった/怠zyなデザインです。
7
Cプログラムのオブジェクト指向ベストプラクティス[終了]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 「オブジェクト指向の砂糖が本当に必要な場合は、C ++を使用してください」 -これを聞いたとき、友人の1人からすぐに返事をもらいました。ここでは2つのことが間違っていることを知っています。最初のOOは「砂糖」ではありません。2番目に、C ++はCを吸収していません。 サーバーをC（Pythonのフロントエンド）で記述する必要があるため、大規模なCプログラムを管理するためのより良い方法を模索しています。 オブジェクトの観点から大規模なシステムをモデリングし、オブジェクトの相互作用により、システムの管理、保守、拡張がより容易になります。しかし、このモデルをオブジェクト（およびそのすべて）を持たないCに変換しようとすると、いくつかの重要な決定に挑戦することになります。 システムに必要なオブジェクト指向の抽象化を提供するカスタムライブラリを作成しますか？オブジェクト、カプセル化、継承、ポリモーフィズム、例外、pub / sub（イベント/シグナル）、名前空間、イントロスペクションなど（GObjectやCOSなど）。 または、基本的なC構造（structおよび関数）を使用して、すべてのオブジェクトクラス（およびその他の抽象化）をアドホックな方法で近似します。（たとえば、SOに関するこの質問に対する回答の一部） 最初のアプローチは、モデル全体をCで実装するための構造化された方法を提供しますが、維持する必要がある複雑さの層も追加します。（複雑さは、最初にオブジェクトを使用することで軽減したかったことを思い出してください）。 2番目のアプローチについては知りません。また、あなたが必要とする可能性のあるすべての抽象化を近似するのにどれほど効果的かはわかりません。 したがって、私の簡単な質問は次のとおりです。Cでオブジェクト指向設計を実現するためのベストプラクティスは何ですか。それを行う方法を求めているのではないことに注意してください。これとこの質問はそれについて話す、とさえあります本は、この上。私がもっと興味を持っているのは、これを解決するときに現れる実際の問題に対処する現実的なアドバイス/例です。 注：C ++を支持してCを使用すべきではない理由をアドバイスしないでください。私たちはその段階を十分に過ぎました。
1
（/ did）Bertrand Meyerは、サブクラス化が「閉じた」モジュールを拡張する唯一の方法だと考えるのはなぜですか？
MeyerのObject-Oriented Software Construction（1988）で、彼は次のようにオープン/クローズド原則を定義しています。 モジュールがまだ拡張可能であれば、モジュールは開いていると言われます。たとえば、フィールドに含まれるデータ構造にフィールドを追加したり、実行する一連の機能に新しい要素を追加したりすることができます。 モジュールは、他のモジュールで使用できる場合、閉じられていると言われます。これは、モジュールに明確に定義された安定した説明（情報隠蔽という意味でのインターフェース）が与えられていることを前提としています。 彼は言い​​続けます： モジュールを再度開く場合、古いバージョンに依存しているため、すべてのクライアントを再度開いて更新する必要があります。…[この問題]は、モジュールを新しい関数またはデータ要素によって拡張する必要があるたびに発生し、直接および間接クライアントの変更をトリガーします。...設計とプログラミングに対する古典的なアプローチでは、オープンとクローズの両方のモジュールを記述する方法はありません。 このジレンマに対するMeyerの解決策は、既存のクラスを変更してライブラリモジュールを拡張しないことです。代わりに、既存のクラスをサブクラス化する新しいモジュールを作成し、新しいクライアントがその新しいモジュールに依存するようにします。 今、1988年に、私はTurbo PascalとBlankenship Basicでおもちゃ（手続き）プログラムを書いていました、そして、21世紀の専門的な経験はJVM、CLR、および動的言語でしたので、Meyerの意味がわかりません「設計とプログラミングへの古典的なアプローチ」による。 Meyerのクライアントモジュールを再度開く必要がある理由の具体例（より多くのケースを必要とする、より多くのメンバーを含む列挙のswitchステートメント）は十分に合理的なようですが、ライブラリに機能を追加するたびにアサーションを正当化することはほとんどありませんモジュール、すべてのクライアントを更新する必要があります。 この主張が1988年に自明であると思われる歴史的な理由はありますか？たとえば、C静的ライブラリに関数またはデータ構造を追加すると、下位互換性のあるAPIでもクライアントを再コンパイルする必要があるようにレイアウトが変更されましたか？または、MeyerはAPIの下位互換性を強制するメカニズムについて本当に話しているだけですか？
7
データ転送オブジェクトのインターフェイスを作成する必要がありますか？
データ転送オブジェクトのインターフェースを作成するのは良い考えですか、悪い考えですか？通常、オブジェクトは可変であると仮定します。 私の例はJavaですが、同様の概念を持つ他の言語にも適用できるはずです。 interface DataTransferObject { String getName(); void setName(String name); } class RealDataTransferObject implements DataTransferObject { String name; String getName() { return name; } void setName(String name) { this.name = name; } } もちろん、これは単純化された例であり、実際にはもっと多くのフィールドがあるかもしれません。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.