問題タブ [solid-principles]

Robert Martin は次のように述べています。

View にバインドされている ViewModel クラスを考えてみましょう。ViewModel が実際には相互に関連していないプロパティで構成されている可能性があります (または可能性さえあります)。小さなビューの場合、ViewModel は非常に首尾一貫している可能性がありますが、アプリケーションがより複雑になるにつれて、ViewModel はさまざまな無関係な理由で変更される可能性があるデータを公開します。

ViewModel クラスの場合、SRP の原則について心配する必要がありますか?

ジェネリック メソッド シグネチャの使用方法を学習するために、次のコード例を作成しました。

Customer と Employee の両方のDisplay() メソッドを取得するために、実際にIPerson インターフェイスをPerson 抽象クラスに置き換え始めました。

しかし、ボブおじさんがスコット・ハンセルマンに、それぞれが特定のことを行う小さなクラスをたくさん持つべきであるという単一責任の原則について話していたポッドキャストを思い出して、私は立ち止まりました。 ()およびCalculateSalary()メソッドを使用しますが、CustomerPrinter クラス とCustomerSaver クラスとCustomerSalaryCalculatorクラスが必要です。

それはプログラミングの奇妙な方法のようです。ただし、インターフェースを取り除くことも間違っていると感じたので (非常に多くの IoC コンテナーと DI の例がそれらを本質的に使用しているため)、単一責任の原則を試してみることにしました。

したがって、次のコードは、私が過去にプログラムしたものとは異なります(Display() メソッドを使用して抽象クラスを作成し、インターフェイスを削除したはずです) が、デカップリングと SOLID 原則について聞いたことに基づいて、この新しいコーディングの方法 (インターフェイスと PersonDisplayer クラス) これが正しい方法だと思います。

他の人がこの問題について同じように考えているかどうか、またはこれのプラスまたはマイナスの影響を経験したかどうかを聞きたいです (たとえば、それぞれが特定のことを行う扱いにくい数のクラスなど)。

この質問が主観的で申し訳ありませんが、少し行き詰まっており、以前にこの問題に対処しなければならなかった人からのガイダンスとアドバイスをいただければ幸いです。

C# 2.0 で記述された非常に大規模な RESTful API プロジェクトがあり (その後どうなったか)、私のクラスのいくつかは巨大なものになりました。私のメイン API クラスはこの例です。数十のメンバーとメソッド (おそらく数百に近い) があります。ご想像のとおり、このコードを維持するだけでなく、コードをナビゲートするだけでも雑用になり、小さな悪夢になりつつあります。

私は SOLID の原則についてかなりの初心者であり、デザイン パターンの大ファンです (しかし、私はまだそれらを実装できる段階にありますが、それらをいつ使用するかを知るには十分ではありません - それほど明白ではない状況で) .

クラスのサイズを分割する必要がありますが、それを行う最善の方法がわかりません。私の仲間の StackOverflow'ers は、既存のコード モノリスを利用してサイズを縮小する方法を提案できますか?

「インターフェイスへのプログラミング」と「new」キーワードの使用を避けるという考え方が気に入っています。

しかし、同じインターフェースを持っていてもセットアップが根本的に異なる 2 つのクラスがある場合はどうすればよいでしょうか。私の特定のコードについて詳しくは説明しませんが、メソッド「DoStuff」とのインターフェースがあります。2 つのクラスがこのインターフェイスを実装します。1つは非常に単純で、初期化を必要としません。もう 1 つの変数には、設定する必要がある 5 つの異なる変数があります。これらを組み合わせると、DoStuff が呼び出されたときにクラスが動作する文字通り何百万もの方法が可能になります。

では、いつこれらのクラスを「新しく」するのでしょうか? 工場を使用することについて考えましたが、セットアップが大きく異なるため、この場合には適していないと思います。(ところで: 実際には、インターフェイスを使用する約 10 の異なるクラスがあり、それぞれが複雑なパイプラインの一部を形成し、それぞれに異なる構成要件があります)。

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

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

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

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

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

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

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

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

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

空の NO-OP 実装を使用してインターフェイスのすべてまたは一部のメソッドを実装する、抽象的でない既定の実装が提供されるシナリオを説明する特定の設計パターンはありますか。これは、サブクラス自体が必要/使用しない可能性のあるメソッドを実装する負担をサブクラスに軽減することを目的として行われています。

SAX フレームワークの Java の DefaultHandlerやMouseAdapterなど、このパターンが何度も使用されているのを見てきました。場合によっては、そのようなクラスはアダプターと呼ばれますが、アダプター パターンは 2 つの異なるインターフェイス間で変換されるという印象を受けました。

これらのインスタンスでは、そのインターフェイスの未定義のサブセットに変換されている宣言されたインターフェイスが 1 つしかないことを考えると、これがアダプター パターンの精神にどのように含まれているかは明確ではありません。

さらに、いくつかのメソッドが実装を持つ可能性があり、NullObject は伝統的にシングルトンであることを考えると、これがNullObject パターンにどのように準拠しているかはよくわかりません。

ユーザーが作業を中止するかどうかを定期的に確認する必要があるバックグラウンド スレッドでコードを実行しています。

問題は、ほとんどSOLID環境でこれを実装する方法です。

• ICancelすべてのクラスに挿入するインターフェイス。
• どこかの public static メンバー

非定数静的は、遅かれ早かれ常に問題を引き起こすようです。一方、「標準」のインジェクション (ILogger、IProgressReporter など) の数は着実に増加しているため、cancel のような単純なものは static を使用するのに適している可能性があります。

他の/より良い方法はありますか? 誰でも共有する経験がありますか?

私は WPF と C# を使用していますが、質問は一般的です。

次に例を示します。

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

設計レビュー中に、新しい動作がシステムに追加されるたびに 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 つの概念の定義のソースとして提供します。