問題タブ [single-responsibility-principle]

MVP パターンを使用するシナリオで、オブジェクト指向プログラミングの原則を適用しようとしています。私は 4 つの解決策を得ましたが、最後の 2 つはより気に入りました。ただし、ほとんどのソリューションは、SRP、IOC / DIP、Open-Closed Principleなどの特定の原則を分解しています.

簡単に言えば、視聴者とプレゼンターにはオプションの動作が必要です。この動作により、ビューアにウィンドウを表示したり、1 つのパネルに含めることができます。私の意見では、ビューアーは JFrame とリスナーの知識を持っている必要があります。ビューアーが選択したウィンドウの動作をサポートしている場合、ウィンドウ化されたプレゼンターはいくつかの追加アクションを実行する必要があります。

この状況に最適なデザインを見つけるのを手伝ってもらえますか? 例を見ればその必要性が明確になると思います。

解決策 1 - アダプターのような

解決策 2 - 継承の使用

解決策 3 - ウィンドウ ハンドラーを使用する

解決策 4

ありがとうございました

現在、別のチームから引き継いだもののコードレビューを行っており、SRP の適用と貧血またはリッチドメインモデル (Martin Fowler によって定義されている) との関係について 1 つの疑問があります。リッチ ドメイン モデルの概念は、プロパティを設定/取得できるだけでなく、より複雑なビジネス ロジックを実行できるインテリジェントなオブジェクトを持つことです。SRPにどのように適合するのだろうか？

これらの小道具を公開し、そのプロパティでいくつかの簡単な計算を提供できるいくつかのプロパティを持つモデル クラスがあるとします。次の要件は、次のように、このオブジェクト データを自分の管理下にないストレージ オブジェクトに格納できるようにすることです。

ストレージへの格納方法

MyObject にこのような store メソッドがあれば SRP に違反しませんか?

このオブジェクトの視点から、その状態を保存できるのは良い考えです。別の方法として、ここにある種のサービスを導入して、次のようにすることもできます。

この問題について読むことができるリンクを教えてもらえますか? SO here で1つのスレッドを見つけましたが、私の質問に完全には答えていません。

DDD ではどのように解決されますか? DDD のモデルは定義上リッチであり、責任が多すぎると見なすことができます。

私は、データベースにアクセスするための Web サービスを提供し、.NET クラスを介してそれを公開するシステムに対して開発しています。私たちの通常の作業方法は、データベースにアクセスしてそのインスタンスを直接使用する必要があるときはいつでも Web サービス クラスのインスタンスを作成することです。もちろん、これは完全に IoC に反し、ほとんどテスト不可能なコードを作成します。私は現在、(より多くの) SOLID コードを記述できるようにするために、IoC を使用して作業する新しい標準的な方法を考案しようとしています。

私の現在の解決策はこれです（あまり説明されていません）：

DatabaseConnectionWeb サービスは、保護されたメンバーとして Web サービス オブジェクトを格納し、一般的に使用される多数の一般的なデータベース呼び出しへのアクセスを提供するクラスにラップされます。

実際のアプリケーションでデータベース アクセスが必要な場合は、そのクラスから派生させて (たとえば、新しいクラスを呼び出してApplicationDatabaseConnection)、必要なデータベース インタラクションをメソッドに実装して、Web サービスを呼び出すことができるようにします。

このクラスはアプリケーションで直接使用されませんが、アプリケーションのさまざまな部分に「コネクタ」インターフェイスを提供します。各部分は、最上位のクラスのようなコントローラー/ビュー モデルによって表されます。これらのアプリケーション関数の 1 つが (たとえば UI から) 呼び出されるたびに、適切なコントローラー オブジェクトが作成されApplicationDatabaseConnection、それぞれの「コネクタ」インターフェイスの実装としてオブジェクトが渡されるため、データベース アクセスはその時点で適切にカプセル化および分離されます。私が言うことができるように。

これに関する私の問題は次のとおりです。これは、自分のコードでISP（インターフェイス分離の原則）の実際の使用を見つけた最初のケ​​ースですが（これが実際に概念の賢明な使用かどうかはわかりませんが）、私はこのクラスがやりすぎて、SRP (単一責任の原則) に違反するのではないかと心配しています。それとも、「データベースへのアクセスを提供するだけで、多くの異なる消費者に対して」というのは単一の責任ですか?

もう少し明確にするために、関連するクラスは大まかに次のようになります。

私が考えることができる代替案は、私にとっても理想的ではないようです。

データベース アクセス機能を分割するために、クラスは異なるコネクタ (インターフェイスの背後) のメソッドを持つApplicationDatabaseConnectionファクトリ クラスにすることしかできませんが、ファクトリ パターンを必要とするものは実際には何もありません。「コントローラー」オブジェクトをインスタンス化するときだけ知っていることは何もありません。CreateIConnectorAFactoryIConnectorBFactory

また、実際のコネクタ クラスも基本的に の派生でDatabaseConnectionある必要があります。これは、同じ基本機能が必要であり、(遅くとも) 構成全体がかなり不吉になるからです。

私は自分の思考のある時点で間違った方向に進み、今では完全に間違った方向に進んでいると思います. そのようなソリューションの構造はどのように見えるべきですか? 正しい方向へのプッシュは大歓迎です。

編集：

@Tobias の回答により、重要な詳細を忘れていたことに気付きました。Web サービスには、ほぼ同じ機能を備えた 2 つの異なるバージョンがありますが、API が完全に異なります。これが、カプセル化する必要がある理由の 1 つです。

もう 1 つは、私のロジック クラスが Web サービスに直接 (またはインターフェイス経由で) アクセスする場合、それらは Web サービス クエリを詳細に構築することにも関係しているため、より緊密に結合されたコード (私たちが行ってきたようなもの) が作成されます。これまでのところ生産) であり、SRP に違反しています - したがって、コネクタ インターフェイスのアイデアです。

有名なオブジェクト指向プログラミング設計の S は、次の略です。

単一責任の原則。オブジェクトは単一の責任のみを持つべきであるという概念。

この原則は、配列、変数、およびプログラムのすべての要素にまで拡張できますか?

たとえば、次のようにします。

そして、それを関数の結果を格納するために使用しますが、同じ A[100] を使用して、たとえば、A のどのインデックスを既にチェックして精緻化したかをチェックします。これは間違っていると考えられますか？たとえば、すでにチェックしたインデックスなど、格納する別の要素を作成するべきではありませんか? これは将来の厄介なコードのヒントではありませんか?

PS: 私の質問が理解できない場合は申し訳ありませんが、英語は私の母国語ではありません. ポイントの理解に問題がある場合は、下のコメントでお知らせください。

私は SRP と SOLID を真に理解し、人々がそれを適用する理由を完全に理解しようと努めてきました。私はまだ SRP の「アート」をマスターしようとしています。これに取り掛かると、私が最もよく理解しているアドバイスは次のとおりです。 " (臭い、私は知っています) CreateComputerObject、FindComputerObject、および DeleteComputerObject を持っています。これは 3 つの別個のクラスに分割する必要があると思いますよね?

しかし、もっと重要なことは、SRP を宗教的に適用した場合、Visual Studio/C# プロジェクトで何十ものクラス .cs ファイルを取得できないのでしょうか? もしそうなら、そしてそれがそうあるべきだとしたら、どのようにプロジェクトを編成しますか?

どうもありがとう

質問が示すように、

関数名が示すように IsNullOrEmpty や IsNullOrWhiteSpace などの文字列関数を使用しているため、これらは複数の作業を行っていますが、これはSRPに違反していませんか?

むしろ、戦略パターンを使用して検証する正しい戦略を選択するよりも、 string.isValid(Enum typeofValidation) であってはなりません。

または、ユーティリティ クラスまたは静的クラスで SRP に違反してもまったく問題ありません。

ASP.NET MVC では、[HttpPost] メソッドで、MVC ランタイムがフィールド名に基づいて、フロント エンドのフォーム フィールドからビュー モデルにデータを自動的にマップして転送します。

ASP.NET WebForm で同じことを達成するにはどうすればよいですか?

たとえば、FirstName プロパティと LastName プロパティを持つ Person というオブジェクトがあります。

FirstName と LastName の Textbox コントロールを含む WebForm ページがあります。

フォームで [送信] を押すと、分離コードの Button_Click イベントで FirstName と LastName を Person オブジェクトに自動的にバインドする方法はありますか?

Webサイトを開発しており、CountryなどのモデルのCRUDを処理するコントローラーがあります。管理者のみがCRUD操作を実行できます。ただし、コントローラーがドロップダウンに入力するエンティティのJSON選択リストを提供することも必要です。このパターンは、アプリケーション全体に存在します。

これは、標準の許可属性を使用して、コントローラーへの入り口で管理者へのアクセスを制限できないことを意味します。各アクションを特定のauthorize属性で装飾する必要があります。

1つのコントローラーに複数の認証レベルが必要であるという事実は悪い兆候ですか？SRPに違反していることを示唆していますか？

多くのコントローラーが、管理者のみが更新可能である必要があるが、すべての許可されたユーザーにJSON選択リストを提供するエンティティに関連しているという事実に対処するための最良のパターンは何ですか？

ありがとう

ちょうど今、この質問を入力したところ、興味深いスレッドが表示されました。私はそれが私の質問に答えるとは思わない。

私は貧血モデルを持つことが望ましい.NET MVC3で多くの作業をしてきました。ビュー モデルと編集モデルは、コントローラーからビューに渡すだけのダム データ コンテナーとして最適です。あらゆる種類のアプリケーション フローはコントローラーから来る必要があり、ビューは UI の問題を処理します。MVC では、モデルに動作は必要ありません。

ただし、コントローラーにもビジネスロジックは必要ありません。大規模なアプリケーションの場合は、ドメイン コードをモデル、ビュー、およびコントローラー (および一般的な HTTP) から分離して独立させるのが最善です。そのため、何よりもまずドメイン モデル (DDD に従って集合体に構成されるエンティティと値オブジェクトを含む) を提供する別のプロジェクトがあります。

私は貧弱なモデルから離れてドメインコードのより豊かなモデルに移行しようと何度か試みましたが、あきらめることを考えています. データと動作の両方を含むエンティティ クラスが SRP に違反しているように思えます。

たとえば、電子メールを作成する、Web での非常に一般的なシナリオを考えてみましょう。何らかのイベントが発生した場合、EmailTemplate、EmailAddress、およびカスタム値を指定して EmailMessage オブジェクトを作成するのはドメインの役割です。テンプレートはプロパティを持つエンティティとして存在し、カスタム値はユーザーによる入力として提供されます。また、引数のために、EmailMessage の FROM アドレスを外部サービス (IConfigurationManager.DefaultFromMailAddress) から提供できるとしましょう。これらの要件を考えると、豊富なドメイン モデルにより、EmailTemplate に EmailMessage を構成する責任を与えることができるように思われます。

これは、リッチ ドメイン モデルに対する私の試みの 1 つです。ただし、このメソッドを追加した後は、エンティティ データ プロパティを含めてメッセージを作成するのは EmailTemplate の役割でした。それは約 15 行の長さで、EmailTemplate の本当の意味からクラスの注意をそらすように見えました。つまり、EmailTemplate は単にデータ (件名の形式、本文の形式、添付ファイル、オプションの差出人/返信先アドレス) を格納することです。 ）。

私は最終的に、このメソッドを、前の引数が与えられた場合に EmailMessage を作成することだけを担当する専用クラスにリファクタリングしました。実際、貧血ドメインを好むようになってきました。責任を分離し、クラスと単体テストをより短く、より簡潔に、より集中的にするのに役立つからです。エンティティやその他のデータ オブジェクトを「動作のない」ものにすることは、責任を分離するのに適しているようです。それとも私はここで軌道に乗っていませんか？

私は現在、ロイヤリティの支払いを管理するシステムをモデル化しています。ロイヤルティは次のように単純です。

• 収益の 15% を著者 A に支払う

または次のいずれかのように複雑です。

• 作成者 B に、売上の 1000 個までは収益の 15%、その後は収益の 12% を支払う
• また、販売数が 1000 までの場合、販売ごとに著者 B に 1.50 ドルを支払う

また：

• 最初の 1,000 ドルの収益について著者 C に収益の 15% を支払い、その後、収益の 12% を支払う

つまり、支払いは、販売ごとの定額または収益のパーセンテージのいずれかです。支払いの条件は、販売数量または収益に基づく場合があります。私は、支払い範囲と支払い値の型を指定することによって、このすべての柔軟性を包含するクラス (舞台裏のデータベース テーブルに密接に対応する) を設計しようとしました。ただし、このクラスでやりすぎて、将来追加のシナリオに対応する必要が生じた場合に追い詰められるのではないかと心配しています。代替設計アプローチの提案を求めています。

任意の提案をいただければ幸いです。

2012 年 5 月 9 日更新:

これらのルールは、SQL Server データベースに永続化する必要があることに注意してください。