問題タブ [single-responsibility-principle]

タイトルが私の問題をうまく説明していない可能性があります。誰かがそれをより適切なものに編集できれば幸いです。いずれかの方法：

与えられた製品価格を返すはずのコンポーネントを取得しましたid。次のようなインターフェイスを実装します。

現在、価格は3 つの異なるソースから取得できます。

• ウェブサービス
• ウェブサイトのソースコードから直接 (スクラップ)
• 最後のフォールバック (Web サービスと Web サイトの両方にアクセスできない) として、ローカル データベースからの最新の価格が返されます。

この 3 つの異なるソースの問題を回避するために、次のようなクラスを実装しました。

もちろん、ファクトリからの各メソッドは戻りますIProductPriceFetcherが、最初の 2 つは失敗して戻る可能性があることに注意してくださいnull。私GetLocalDatabaseFetcherは常に意味のあるオブジェクトを返すと仮定しました。

私の「一般的な疑問...メン」

Web サービス/Web サイトの呼び出しが成功したら、将来のフォールバック ケースとして、取得した価格をローカル データベースに挿入したいと考えています。私の質問は、上記のコードのどの部分がそれを担当する必要があるかということです。価格を返す具体的な Web フェッチャーの 1 つにすべきでしょうか? または、「アグリゲーター」フェッチャー ( MainFetcher) は、価格のソースが何であるかについての知識も持っているため? イベントを発生させる必要がありますか？DB 呼び出しでさらに別のインターフェイスを挿入しますか? デザインをより良いものに変更しますか？

なぜそれが私の問題として発生したのですか？さて、私はコードをきれいに保とうとしました (心配しないでください。これは私の空き時間のためだけのペット プロジェクトです - まさにこのような問題を解決するためのものです) おそらく SRP/SoC を念頭に置いて。今、私はこの考え方から切り替えるのに問題があるようです-つまり、ウェブページを取得する何かがデータベースの挿入も行っている可能性があるのでしょうか? ああ、さあ！:)

現在発生している設計上の問題があります。

コンポーネントの階層があるとしましょう。これらの各コンポーネントは、次のComponentような抽象型から派生します。

ここで、これらのコンポーネントにいくつかのオプション機能を追加したいと思います。例として、コンポーネント階層内で検索し、階層内でコンポーネントを選択できるようにしましょう。

次のような基本クラスでこれらのオプション機能を提供することは悪い習慣と見なされますか?

「検索機能」と「選択機能」は、たとえば戦略パターンを使用して派生コンポーネントで管理されますか?

どういうわけか、これは SRP に違反しているように思えますが、私の意見では、唯一の代替手段は、各オプション機能のインターフェイスを持ち、この機能をサポートするコンポーネントにのみ実装することです。

私の意見では、これには、コンポーネントが特定の機能を提供するかどうかを確認するたびに、このようなコードを書かなければならないという欠点があります。

どちらの戦略を選択しますか、またはより良いアイデアがありますか?

前もって感謝します！

例として使用しましょう：

責任はいくつありますか？1または4？

シナリオ

各アイテムが 2 人の異なる人によってレビューされるシステムを構築しています。最初のレビュアーがアイテムのレビューを保存すると、次は 2 番目のチェッカーが個別のレビューを完了します。最初のレビューを送信してアイテムを再度開くと、自分の作品をレビューできないため、アイテムは読み取り専用状態になります。また、最初のレビュー担当者は、さらに情報が必要な場合にアイテムを保留状態にすることができますが、2 番目のレビューではできません。各ユーザーには、リストから項目を選択するたびに、特定のレビュー担当者ロールが与えられます。

私がこれまでに持っているもの

アイテムがエディターに読み込まれるたびに、ユーザーには 2 つの役割のいずれかが与えられInitialReviewerますSecondReviewer。

私のエディタの縮小版。

問題

私が抱えている問題は、そこに属していないクラスSave()からロジックを内部に持つことから逃れることができないように見えることです。Editor

質問

クラスSave()から関数内のロジックを取り除くにはどうすればよいですか? EditorSRP の原則に違反しているようです。現在のレビュアー オブジェクトが型ICanPutIntoPendingStateであるかどうかを確認することが大きな問題だと思います。

かなりの数があるため、すべてのロジックを省略したことに注意してください。

車のクラスがあるとしましょう。

そして、私は車のリストを保持するカスタムCarServiceクラスを持っています：

次に、車のリストをファイルからCarServiceクラスにロードします。私の古いOOPの本能は、これをCarServiceクラスのLoadFromFile（）のようなメソッドとして配置することでした。ただし、SRPとテスト容易性について学習しているので、よくわかりません。

単一責任の原則に従って、これを設計する正しい方法は何ですか？CarLoaderクラスが必要ですか？

アップデート

解決策はさまざまな言語で同じである必要があると思いますが、C++を使用します。C＃、Java、またはpythonを使用している場合、私の質問は同じです。

次のようなMVCアクションがあるとします。

不正アクセスの試みのケースをテストするには、いくつのテスト方法が必要ですか？

つまり、単一のテストを作成しますか？

または私は2つのテストを書きますか？

問題は、技術的にはコントローラーがSRPに違反していることだと思いますが、それ自体が問題であるとは考えていません（同意しない場合は修正してください）。それがテストメソッドにどのようにマッピングされるかはわかりません。メソッドの責任ごとに1つのテストですか、それともメソッドを通る単一のルートごとに1つのテストですか？

今日、いくつかのコードを DRY しようとして、いくつかの重複する File.exists を抽出しましたか? いくつかのヘルパー メソッドによってプライベート メソッドに使用されるコード

def template_exists?(*template)そして誤ってサルは、この既存の Rails ヘルパー メソッドにパッチを適用しました。これは、コードのにおいを示す非常に明確な指標でした。継承されたメソッドは必要ありませんでしたが、継承しました。その上、このヘルパーでリファクタリングされたメソッドは一体何をしていたのでしょうか?

したがって、このヘルパーはやりすぎであり、SRP (Single Responsibility Principle) に違反しています。Rails ヘルパーは本質的に SRP 内に保持するのが難しいと感じています。私が見ているヘルパーは、他のヘルパーのスーパークラス ヘルパーであり、300 行以上を数えます。これは、対話フローをマスターするために JavaScript を使用した非常に複雑なフォームの一部です。fat ヘルパーのメソッドは短くてきちんとしているので、それほどひどいものではありませんが、懸念の分離が必要であることは間違いありません。

どのように出ればいいですか？

1. メソッドを多くのヘルパーに分割しますか?
2. ヘルパー メソッド内のコードをクラスに抽出し、それらにデリゲートしますか? これらのクラス (Mydomain::TemplateFinder など) の範囲を指定しますか?
3. ロジックをモジュールに分割し、上部にインクルードとしてリストしますか?
4. 他のアプローチ？

私が見るように、偶発的なモンキーパッチに関しては、2 の方が安全です。もしかして組み合わせ？

コード例と強い意見を歓迎します!

現在のプラクティス (少なくとも WPF と Silverlight を使用) では、ビュー モデルでコマンド バインディングを介してバインドされたビューが表示されるか、少なくともビュー モデルで処理されるビュー イベントが表示されます。ビュー モデルはビュー ステートをモデル化するだけでなく、ビュー (ユーザー) に応答するため、これはSRPに違反しているように見えます。他の人は、SRP に違反せずにビュー モデルを構築する方法を尋ねたり、実装がそうするかどうかを尋ねたりしました(これは MVC のコントローラーですが、ほぼ類似しています)。

では、現在の慣行は SRP に違反しているのでしょうか? それとも、「ビュー モデル」は本当に SRP に違反しないものの集まりなのでしょうか? これを少し理解するには、単一の責任とは何か、概念に複数の責任がある場合は、SRP に準拠して個々の責任が分割されているかを知る必要があるようです。わからない。

ウィキペディアのビューモデルの定義によると

[T]ViewModel は「View のモデル」であり、View と Model の間のデータ バインディングにも役立つ View の抽象化であることを意味します。

SRP にはこれで十分だと思われますが、後でエントリに次のように記載されています (強調を追加)。

[ViewModel] は、Model 情報を View 情報に変更し、View から Model にコマンドを渡すデータ バインダー/コンバーターとして機能します。

ビュー モデルの役割に関する Prism のブログ投稿で、著者は次のように述べています (繰り返しますが、私の強調です) 。

要するに、ビューモデルは次の複合体であるということです:

• ビューの抽象化
• コマンド
• 値コンバーター
• ビューステート

私はそこに多くの定義を見逃していると確信していますが、それらは次のカテゴリに分類されるようです:

1. ビューステートのモデリングの単一の「あいまいな」責任 (つまり、状態とは どういう意味ですか)
2. 複数の責任 (ビュー ステート、ユーザー インタラクション (つまりコマンド))
3. 単一の特定の責任 (抽象化、状態、相互作用、変換) の複合体。したがって、「すべてのものを管理する」という単一の責任があります。

興味があれば、(2) は正しいと感じますが、一般的な実装に反しているように見えるので、私はこれを「気にします」。

単一責任の原則、分解などに関するこれらすべての読み物では、エンティティが肥大化するというアラーム信号がどうあるべきかを理解することは困難です。

最大数の方法を検討する必要があるか、または他の客観的な基準があるかどうかについて、どこかに良いアドバイス/読み物がありますか？

アプリケーションの設計では、通常、オブジェクトをデータベース内の重要なテーブルにマップします。オブジェクトは、そのデータに関連するすべてのもの (リンク テーブルを含む) を処理します。たとえばActivity、 と のようなプロパティ、 と のnameようdue_dateなメソッド、および と のようなメソッドload()を使用してsave()、他のオブジェクト (の配列) を返すオブジェクトを作成しました。単一責任の原則に違反しているため、これは「悪い」OOP ですか?getParent()getContributors()getTeam()