問題タブ [open-closed-principle]

私は現在、コマンドが基本的にハンドラーの.Handle()メソッドの DTO である、設計中のサービスのコマンドハンドラーパターンを実装しています。さまざまな具象クラスの実装を開始すると、Open/Closed Principle および Single Responsibility Principle を満たすために、何千もの Command および Handler クラスになる可能性があることに気付きます。これは、Don't Repeat Yourself Principle に大きく違反します。

たとえば、私がカプセル化しているプロセスの一部では、ProjectId60 個の奇数テーブルからすべてのデータを削除してそれらをリセットする必要があります。それぞれをアトミックな具象 Command オブジェクトと具象 CommandHandler オブジェクトとして実装すると、この最初のステップだけで 120 個のクラスができます。 それらはすべてSRPとOCPに完全に準拠しますが、DRYは深刻な打撃を受けます...

別の方法として、単一の多目的コマンドおよびハンドラー クラスを実装しProjectTables、個別のすべてのクラスの代わりに列挙を使用することもできます。

ただし、新しいテーブルが追加された場合、列挙とそれを使用するすべての場所の両方も更新する必要があるため、これは Open/Closed Principle に違反します。60 ケースの switch ステートメントから得られる臭いは言うまでもありません。

すっごい…どっちが勝つ？DRY または SRP & OCP?

クラスの1つで次のメソッドを作成しました

私のコードをレビューした私の友人は、「List クラスを拡張する」メソッドを作成するべきではないと言っていました。クラス List を拡張したい場合は、List を継承する新しいクラスを作成し、その新しいクラスに「マージ」メソッドを実装する必要があります。彼は正しいですか？List クラスを拡張すると、Open/Closed の原則に違反しますか?

したがって、元のコードを作成したときは、LabTest クラスと言うだけで済みました。しかし、RadiologyTest、EKGTest などを追加する新しい要件があるとしましょう。

これらのクラスには多くの共通点があるため、基本クラスを持つことは理にかなっています。

ただし、これは LabTest クラスを変更する必要があることを意味します。そのインターフェイスは以前と同じままであるとしましょう。つまり、LabTest クラスのコンシューマーは変更する必要がありません。

これはオープン・クローズド・プリンシパルの原則に違反していませんか？(LabTest は変更中です)。

私は会社のためにゲームを開発しています。私はこのゲームを 2 か月間だけ開発します。会社から、機能を追加する必要があるときに別のプログラマーを雇えるように、コードをクリーンで拡張可能にするように依頼されました。Uncle Bob の Clean Code を読みました。いくつかのコンセプトを実践するのは本当に難しいと思いました。これは私のクラスの 1 つです。

}

私の質問は、このクラスは単一責任の原則に違反していますか? すべてのアクターを独自のクラスに分離する必要がありますか? もしそうなら、どのようにコードをリファクタリングすればよいですか?

以下のクラス ProductService は、データベースから日付、国などのさまざまなフィルターに基づいて製品を取得します。ProductsService は OCP に従いません。価格で製品を取得するなどの新しいフィルターを追加するには、ProductsService コードを変更する必要があるためです。どのように修正できますか？提案やコメントは本当に役に立ちます。