問題タブ [single-responsibility-principle]

SRP ( PDF版; HTML版) は次のように述べています。

クラスを変更する理由は複数であってはなりません

Outlookのカレンダーイベントウィンドウを見ると、「保存して閉じる」ボタンがあります。

そのため、保存または閉じるのいずれかまたは両方の機能が変更された場合、そのボタンも変更する必要があります。明らかに SRP に違反しています。この機能は、ほとんどのユーザーが予定をカレンダーに保存するときに行うことを期待

しているため 、時間の節約と便利さの両方を実現します。

しかし今、私の質問は、機能を Outlook で使用可能にする必要がある場合以外に、SRP に違反するのはどのような場合ですか?

さまざまな種類の構成ファイル (テキストや xml など) からのパラメーターを持つコンテナー クラスがあります。

そこで、textConfigurationFiles 用のクラスと xmlConfigurationFiles 用のクラスを作成しました (このためのインターフェイス IConfigFile を後で実装すると思います)。

コンテナ クラスの初期化は次のようになります。

またはxmlの場合

しかし、すべての単一の値を割り当てる代わりに、何らかの変換を行いたいと考えています。型キャストを実装する必要があるのか​​、ContainerClass オブジェクトを返す単純なメソッドを実装する必要があるのか​​ わかりません。

また

あなたの提案は何ですか？

私は単一責任の原則を実装しようとしているので、ContainerClass が単純なコンテナを表すようにしたいと考えています。だから私は次のようなものだと思います

SRPで壊れますか？

おそらく、ContainerClass はテキストファイルまたはxml ファイルによって初期化されることに言及する必要があります。パラメーターがテキストファイルとxml ファイルの両方から得られるわけではありません。

[編集: 追加情報]

ContainerClass は、データベース構成情報 (パス、名前など) を持つコンテナーを表します。

textFile はデータベース構成を表します。

xmlFile にもデータベース構成が含まれていますが、textFile よりも多くの (データベース構成) パラメータがあります。

私はsthについて考えます。お気に入り：

また

TextFileConfig で:

では、convert メソッド、typecast、またはその両方を優先する必要がありますか?

最初に、パフォーマンス、最適な使用法、および個人的な習慣について考えます。

単一責任の原則は、検証ルールがエンティティの外部にある必要があることを意味しますか？

その場合、検証ルールごとに1つのクラスを使用しますか？

コントローラーとアクションで承認属性を使用する ASP.NET MVC アプリケーションがあります。これはうまく機能していますが、新しいしわが現れました.

オブジェクト: 出荷

役割：出荷、経理、一般ユーザー

出荷はワークフローを移動します。状態Aでは配送のみ編集可能です。状態 B では、経理のみが編集できます。

ShipmentController と Edit Action があります。編集アクションをこれら 2 つのロールのみに制限するために Authorization 属性を設定できますが、これでは、Shipment がどちらの状態にあるかが区別されません。サービス呼び出しの前に、アクション内でいくつかの Authorization を実行して、ユーザーが編集アクションの実行を実際に許可されています。

だから私は2つの質問が残っています：

1）アクション内で承認を得る良い方法は何ですか。コントローラ アクションがサービスを呼び出すと、サービスが適切な呼び出しを Shipment オブジェクト (更新数量、更新日など) に行います。Shipment オブジェクトが承認要件にとらわれないようにしたいことは確かです。一方で、サービス オブジェクトに承認について知らせたいかどうかはよくわかりません。これに適したパターンはありますか？

2) 私の問題は実際には悪い設計の兆候ですか? ShipmentController の代わりに、StateAShipmentController と StateBShipmentController を使用する必要がありますか? Shipment オブジェクトに組み込まれたポリモーフィズムはありません (状態は単なる列挙型です)。

私の場合の特定の解決策ではなく、より一般的な解決策を求めていると思います。質問を説明するための例を提供したかっただけです。

ありがとう！

カウボーイ コーダーは、SO ベテランの助けが必要です。

ファイルから読み取られる参考文献を使用する特定のアプリケーションがあります（実際には、異なるファイルである可能性がありますが、単一のファイルのみを想定しましょう）。

アプリケーションと同じ方法で参考文献を使用する必要がある新しいアプリケーションを作成するため、対応するクラスをコピーしました。

数日後、私は物事を実行しました %-| ...

問題は次のとおりでした。

Bibliography クラスには、参考文献を読み取り、書き込み、保持するためのコードがあります。参考文献を読み取るためのクラスが 1 つと、すべての値を保持するコンテナー クラスがあれば、私の作業はずっと簡単だったでしょう。参考文献を書いたり編集したりしたくありません。ただ読み込んで値を保持するだけです。

参考文献クラスをBibliographyReader、BibliographyWriter、およびBibliography(Container)クラスに分割するのが最善であるという私の考えは正しいですか?

PS: 誰か「カウボーイ コーダー」、「カウボーイ コーディング」などのタグを付けてもらえませんか? このタグが本当に恋しいです ;)

次のようなクラスがあるとします。

そして、関連しているが、その目的を達成するために別の依存関係を利用する機能を追加したいと考えています。おそらく、次のようなものです。

この新しい機能の単体テストを作成する (または既存の機能の単体テストを更新する) と、必要のない依存関係に null を渡しながら、SomeClass (SUT) の新しいインスタンスを作成していることに気付きます。私がテストしようとしている特定の機能について。

これは私には悪臭のように思えますが、私がこの道をたどる理由は、導入する新しい機能の各部分に対して新しいクラスを作成していることに気付いたからです。これも悪いことのように思えたので、同様の機能をグループ化する試みを始めました。

私の質問: クラスのすべての依存関係は、そのすべての機能によって消費されるべきですか?

次のビデオでは、作成者は既存のクラスを取得し、それに単一責任原則を割り当てています。彼は、データへのアクセス、フォーマット、およびレポートの印刷を担当する印刷クラスを受講します。彼は各メソッドを独自のクラスに分割するため、データアクセスを処理するDataAccessクラスを作成し、レポートのフォーマットを処理するReportFormatterクラスを作成し、レポートの印刷を処理するReportPrinterクラスを作成します。次に、元のReportクラスには、ReportPrinterのクラスメソッドPrintを呼び出す1つのメソッドPrint（）が残ります。DataAccessとReportFormatterに責任があるように見えますが、ReportPrinterはDataAcessとReportFormatterに依存しているので、これはSRPを壊しませんか、それとも私はそれを誤解していますか？

私は、単一責任の原則をかなり真剣に受け止めているプロジェクトに参加しています。少人数制のクラスが多く、物事はとてもシンプルです。ただし、貧血ドメイン モデルがあります。どのモデル クラスにも動作はありません。それらは単なるプロパティ バッグです。これは私たちの設計に対する不満ではありません - 実際にはうまく機能しているようです

設計レビュー中に、新しい動作がシステムに追加されるたびに SRP が提示されるため、通常、新しい動作は新しいクラスになります。これにより、物事を非常に簡単に単体テストできますが、関連する場所から動作を引き離すように感じるので、時々当惑します。

SRP を適切に適用する方法についての理解を深めようとしています。SRP は、同じコンテキストを共有するビジネス モデリング動作を 1 つのオブジェクトに追加することに反対しているように思えます。そのオブジェクトは必然的に、複数の関連することを行うか、1 つのことを行うが形を変える複数のビジネス ルールを知っているためです。その出力の。

もしそうなら、最終結果はAnemic Domain Modelのように感じられます.これは確かに私たちのプロジェクトに当てはまります. しかし、Anemic Domain Model はアンチパターンです。

この 2 つの考えは共存できますか?

編集:コンテキスト関連のリンクのカップル:

SRP - http://www.objectmentor.com/resources/articles/srp.pdf
貧血ドメイン モデル - http://martinfowler.com/bliki/AnemicDomainModel.html

私は、預言者を見つけて、彼らの言うことを福音として従うのが好きなような開発者ではありません。したがって、「これがルールだ」と述べる方法としてこれらへのリンクを提供するのではなく、2 つの概念の定義のソースとして提供します。