問題タブ [single-responsibility-principle]

私が書いているアプリケーションには、Policy クラスがあります。ポリシーには 4 つの異なるタイプがあります。各ポリシーは、ポリシー A > ポリシー B > ポリシー C > ポリシー D のように、他のポリシーに対して重み付けされます。

あるポリシーが別のポリシーよりも優れているかどうかを判断するロジックを実装する責任は誰にありますか? 私が最初に考えたのは、> および < 演算子をオーバーロードし、ポリシー タイプ自体にロジックを実装することです。

それはSRPに違反していますか？

情報-エキスパート、Tell-Do n't-Ask、およびSRPは、多くの場合、ベストプラクティスとして一緒に言及されます。しかし、私は彼らが対立していると思います。これが私が話していることです。

SRPを支持するが、Tell-Do n't-Ask＆Info-Expertに違反するコード：

Tell-Do n't-Ask＆Info-Expertを支持するが、SRPに違反するコード：

これらの慣行がどのように平和的に共存できるかについて私に記入してください。

用語の定義、

• Information Expert：操作に必要なデータを持つオブジェクトは、操作をホストする必要があります。

• 尋ねないように言う：仕事をするためにオブジェクトにデータを求めないでください。オブジェクトに作業を行うように指示します。

• 単一責任の原則：各オブジェクトには、狭く定義された責任が必要です。

「変更する理由が1つしかないクラス」について知っています。さて、それは正確には何ですか？クラスが単一の責任を負っていないことを示す匂い/兆候はありますか? それとも、本当の答えが YAGNI に隠され、クラスが最初に変更されたときにのみ単一の責任にリファクタリングすることができますか?

私は、OOP 設計の良い方法と悪い方法について多くのことを読んでいます。あなたのデザインが悪いか良いかを知るのは素晴らしいことです. しかし、悪いデザインから良いデザインへと移行するにはどうすればよいでしょうか? インターフェイス (xaml) とコード ビハインドをメインのビジネス ロジック クラスから分割しました。その最後のクラスは大きくなっています。私はそれを小さなクラスに分割しようとしましたが、今は立ち往生しています。大規模なクラスを分割する方法についてのアイデアはありますか? メイン クラスには、さまざまなタイプのデータのリストが 1 つあります。合計だけでなく、個々のタイプについても計算しています。コードビハインドで処理されるイベントから呼び出されるこれらの計算を実行するメソッドがあります。ここからどこへ行くべきか？

追加情報：

このプロジェクトを開始して、すでに約 6 か月が経過しました。私は何年もの間、オブジェクト指向言語 (最初は c++、java、そして現在は c#) を扱ってきましたが、このような大規模なプロジェクトに携わったことはありません。最初に間違ったターンをしたと思うし、これらを修正する必要があると思う。現時点では、このプロジェクトの詳細を特定することはできません。デザインに関する本を 1 冊か 2 冊注文します。すべてのクラスを分離した場合、それらを元に戻すにはどうすればよいですか? この方法を最初のリリースまで続けて、その後、2 番目のリリースのためにパーツを再構築する方が良いのではないでしょうか?

オブジェクトを「単一の責任」に分解する場合、同様のオブジェクトが一緒に存在するか、個別に存在するかについての基本的な考えはありますか?たとえば、私が持っている場合

これらすべてが内部に存在し、インターフェースを介して疎結合されているのは悪臭ですか?所有する Employee クラス:

それとも、コード内でこれらのクラスを完全に分離する (または少なくとも可能な限り分離する) ことを中心に考えていますか? それとも、これらの方法は両方とも SRP の有効な使用法ですか?

編集:例で与えられたオブジェクトの実現可能性について批判したくありません。質問を説明するために作成しただけです。データ、休暇、給与処理は従業員クラスのドメインではないことに同意します。

ただし、SRP は、現実世界の表現としてのオブジェクトから離れて、単一の機能概念に関するプロパティおよびメソッドとしてのオブジェクトに移動するように私に求めているようです。

基本的に、実際のコードで単一責任の原則を使用することが合理的であると考える人の割合と、実際に使用する人の数を把握したいと思います。ポッドキャスト＃38で、ジョエルはこのOOPの原則が現実の世界でどれほど役に立たないかについて語っています。さらに、これは、ボブおじさんのような人々が重要なシステムを作成していない可能性が高いことを示しています。

私はいくつかのソフトウェアプロジェクトで個人的に書いたり、大きな役割を果たしたりしましたが、若いキャリアの中でこのパターンに出くわしたのは今だけです。私はこの原理の音が大好きで、本当に使い始めたいと思っています。私はポッドキャストでのジョエルの議論が非常に弱いことに気づきました（ここでブログのコメントを読み続けると他の人もそうしました）。しかし、それに真実はありますか？

コミュニティはどう思いますか？

私は常に追加しているクラスを持っています。

これらすべての新機能が追加されているため、このクラスは開閉式ではないことに気付きました。そこで、これらの関数を Request オブジェクトにカプセル化することで、この変更に対してこのクラスを閉じることを考えました。私は次のようなものになります：

これにより、 OrderRepository が拡張用に開かれ、変更用に閉じられます。ただし、これに関していくつかの問題にすぐに遭遇しました。

1.) リクエストが操作する必要があるデータは、ユーザー提供 (実行時) と依存性注入提供の両方です。明らかに、1 つのコンストラクターで両方を満たすことはできません。私はできません：

そしてそれを呼び出します。DIフレームワークがオブジェクトを「部分的に」構築し、残りは私に任せる方法が必要です。しかし、それを行う方法はありません。この概念を「変数コンストラクター インジェクション」と呼んだブログを見ました。

2.) 次に考えたのは、これを 2 つの別々のクラスに分割することでした。ユーザーは RequestContext を作成して入力し、それをリポジトリに渡します。リポジトリは、そこから RequestProcessor (より適切な名前を思いつきません) を作成します。私は次のことを考えました：

それは良い第一歩でした。ただし、リクエスト プロセッサには、保存している正確なタイプのコンテキストが必要ですが、ここにはありません。型の辞書を型に使用することもできますが、それは Open-Closed であるという目的を無効にします。そのため、次のようなことをしなければならなくなります。

これは奇妙で、私は通常、奇妙に繰り返されるテンプレート パターンが好きではありません。さらに、名前付けの問題かもしれませんが、ユーザーがコンテキストを埋めて、それをリクエストするように私に依頼するという考えは奇妙に思えます。

3.) 上記のすべてを取り除き、次のものを用意することを考えました:

これは悪くありませんが、API は醜いです。このオブジェクトのクライアントは、いわばそれを 2 回「構築」する必要があります。また、PackArgs を呼び出すのを忘れた場合は、何らかの例外をスローする必要があります。

続けることもできますが、これらは現時点で最も混乱している問題です。何か案は？

ActiveRecordを使用してユーザーに関する情報を維持しています。Userクラスには、予想されるload（）、insert（）、update（）、およびdelete（）メソッド、setter、getter、およびその他のいくつかのメソッドがあります。しかし、他の特定のメソッドをUserクラスに含めるか、共同作業者が処理するかを決めるのに苦労しています。

次に例を示します。

ユーザーが確認を必要とする可能性のあるいくつかのトランザクションがあります。これは従来の方法で処理されます。つまり、リンクを含む電子メールをユーザーに送信します。リンクをクリックすると、ユーザーが実際にトランザクションを続行することを望んでいることを確認できます。検証キーのハッシュとその有効期限は、ユーザーレコードの一部として保持されます。

このプロセスのどこに線を引く必要がありますか？検証を処理する共同作業者が必要ですか（たとえば、クエリ文字列からプレーンテキストの検証キーを取得し、ユーザーオブジェクトをパラメーターとして受け入れることによって）？または、これをUserクラスによって内部的に処理する必要がありますか（メソッド呼び出しでプレーンテキストの検証キーを渡す）？

もちろん、検証時に発生する次のことは、トランザクションが進行し、アクティブレコードの更新が必要になることです。そこでは、Userクラスが責任を負わなければならないように思われます。

助言がありますか？