問題タブ [solid-principles]

switchステートメントを避けたかったのです。30以上のドキュメントタイプがあります。今後、さらにドキュメントタイプを追加する必要がある可能性もあります。IDocumentを渡し、IDocumentの実装で指定されたタイプを使用したいと思います。私が言及するのを忘れた他の何かはProgressNoteViewModel、LabViewModelでした...すべてWorkspaceViewModelから継承し、すべての具象実装コンストラクターはパラメーターとしてタイプIPatientを取ります。IoCコンテナとしてCastleも使用しています

コードを次のようなものにリファクタリングしたいと思います

私は次のコードを持っています：

この目的のために、xml ファイルで特定のノードを検索し、見つかった場合は削除する必要があります。検索機能を独自のメソッドに引き出し、機能を削除して独自のメソッドにする必要がありますか? xmlファイルを一度検索して存在するかどうかを確認し、再度検索して削除するため、この方法ではより費用がかかるようです。これら 2 つの機能を 1 つのメソッドに組み合わせると、見つけたらすぐに削除できます。ここで SRP を正しく理解していますか?

SRPでは、「責任」は通常「変更する理由」として説明されるため、各クラス（またはオブジェクト？）には、誰かがそこに行って変更する必要がある理由が1つだけある必要があります。

しかし、これを非常にきめ細かくすると、2つの数値を足し合わせたオブジェクトは責任であり、変更する可能性のある理由であると言えます。したがって、オブジェクトには他のロジックが含まれていてはなりません。これは、変更の別の理由を生み出すためです。

少し客観的ではない単一責任の原則である「スコーピング」の戦略を持っている人がいるのではないかと思います。

CRUD (作成、読み取り、更新、および削除) 操作を行う UserServiceImpl クラスを設計しているとします。私の見解では、作成、読み取り、更新、および削除は、クラスが変更される 4 つの理由です。このクラスは単一責任の原則に違反していますか? 違反する場合はCreateUserServiceImpl、ReadUserServiceImpl、 、 UpdateUserServiceImpl、 のような 4 つのクラスが必要DeleteUserServiceImplです。授業が多いのはやり過ぎじゃない？

作成、読み取り、更新、および削除操作用にそれぞれ 4 つのインターフェースを定義し、サービス クラスが 4 つのインターフェースすべてを実装するとします。現在、実装クラスは 1 つしか持てませんが、それらのインターフェースを分離することで、アプリケーションの残りの部分に関する限り、概念を切り離しました。これは正しい方法ですか、それとも問題がありますか?

ウィキペディアでは、単一責任の原則について次のように説明しています。

単一責任の原則は、すべてのオブジェクトが単一の責任を持つべきであり、その責任はクラスによって完全にカプセル化されるべきであると述べています。そのすべてのサービスは、その責任と密接に連携する必要があります。

MVC でのコントローラーの従来の使用法は、プログラマーをこの原則に違反する方向に導くようです。シンプルなゲスト ブック コントローラーとビューを使用します。コントローラーには、1) Index() と 2) Submit() の 2 つのメソッド/アクションがある場合があります。Index() はフォームを表示します。Submit() がそれを処理します。これらの 2 つの方法は、2 つの異なる責任を表していますか? もしそうなら、単一の責任はどのように作用しますか?

この頭字語の最初の文字が表すデザインパターンは、単一責任の原則です。ここに引用があります：

単一責任の原則は、すべてのオブジェクトが単一の責任を持つべきであり、その責任はクラスによって完全にカプセル化されるべきであると述べています。

コーディングを開始するまでは、これは単純明快です。明確に定義された単一責任を持つクラスがあるとします。クラスインスタンスをシリアル化するには、そのクラスに特別な属性を追加する必要があります。そのため、クラスには別の責任があります。それはSRPに違反していませんか？

別の例、つまりインターフェースの実装を見てみましょう。インターフェイスを実装するときは、リソースの破棄やインスタンスの比較など、他の責任を追加するだけです。

だから私の質問。SRPを厳守することは可能ですか？どのようにそれを行うことができますか？

仮想メソッドの使用はLSP （ SOLID原則のL部分）に違反しますか、それともいくつかの例外がありますか？

よろしくお願いします、Saghar Ayyaz

私のチームは、自作の DI コンテナーを使用して PHP プロジェクトに依存性注入を実装することで混乱しています。DI の最初のイテレーションはおそらく極端に行われ、それらに依存するクラスに例外が注入されています。

これは良い習慣ですか、それともやり過ぎですか？

私は初めて Robert Martin の SOLID 設計原則に固執しようとしていますが、それが苦手です。

本質的に、「ノード」オブジェクトの階層が必要です。一部のノードは NodeHosts、一部は NodeChildren、一部は Both です。誰もがこれを以前に行ったことがありますが、設計を過度に複雑にしたり、ノードのサブタイプで次のようなことをしたりせずに、SOLID で行う方法がわかりません。

これはリスコフの置換原理に違反していますよね？より良い方法は何ですか？これが私が今持っているものです。

システムにいくつかの大きな変更を行っています。SOLID の原則を尊重して、これらの新しいビジネス ロジック ルールを実装する最善の方法を知りたいです。

オープン/クローズの原則は、「拡張にはオープン、変更にはクローズ」と言いますが、変更するにはどうすればよいですか? つまり、古いビジネス ロジックを保持したくないということです。私の考えでは、「拡張」は主に「コードを変更する」ではなく「コードを追加する」ことを意味します。