問題タブ [single-responsibility-principle]

インターフェイス分離の原則は、単一責任の原則の代わりにすぎませんか?

クラスが SRP を満たす場合、複数のインターフェイスを抽出する必要はないと思います。

したがって、ISP は、何らかの理由で SRP を壊さなければならない場合の解決策のように見えます。

私は正しいですか？

私はかなり長い間この分野に携わってきたと思いたいのですが、単純なことで自問自答することがあります...クラスが持つ責任、SRP、およびそのタイプのことを決定します。

つまり、メッセージング システムのコンテキストでは、次のようになります。

また

Controller/Manager タイプのクラスを使用していますか? そうでない場合、メッセージはどのようにして自分自身を送信する方法を知ることができますか?

オブジェクトに単一の責任がある場合、次のことを受け入れることができますか?

つまり、提供されたコラボレーターを使用します (ドメイン モデルが貧血になるのを防ぐのにも役立ちます)。

または、次のようにする必要があります。

現在、SOLID の原則、特に SRP について学んでいます。

この原則を理解するために、私は少し前に、アプリケーション全体のすべてのサービス メソッドを含む単一の Spring Service クラスを持つ小さなアプリケーションに取り組んだことを思い出します。

さらに、すべてのjpa-dataアクセスメソッドを含む単一のDAOクラスがありました。

これはすべて、明らかに SRP に違反しています。ではない？

私は iOS 開発が初めてで、アドバイスが必要です。チャットのようなアプリがあります。UI には、新しいメッセージをサーバーに投稿するための子ビューと、テーブル ビューでメッセージを表示するための 1 つの子ビューが必要です。

Interface Builder で両方の子ビューを XIB:s として作成しました。しかし、メインのView Controllerでこれらを使用する方法がわかりません。IB を使用してカスタム ビューをデザイン サーフェイスに追加できますか? または、これらをプログラムで追加する必要がありますか?

これら 2 つの子ビュー間でメッセージまたはカスタム イベントを送信する最良の方法は何ですか? それらを可能な限り分離したいと思います。ほとんどの場合、ユーザーがログオンまたはログオフしたときにイベントを送信して、UI がこれらの変更に反応できるようにしたいと考えています。また、書き込みビューから新しいメッセージが投稿されたときに、メッセージを含むテーブル ビューに知らせたいと思います。

//ヨハン

Javaで、さまざまな機能を持つEventHandlerを持つクラスを持つことは可能ですか? たとえば、button1 でログインし、button2 でログアウトしますが、これは可能ですか? これが私が作ったコードで、動作していないようです。

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