この頭字語の最初の文字が表すデザインパターンは、単一責任の原則です。ここに引用があります：
単一責任の原則は、すべてのオブジェクトが単一の責任を持つべきであり、その責任はクラスによって完全にカプセル化されるべきであると述べています。
コーディングを開始するまでは、これは単純明快です。明確に定義された単一責任を持つクラスがあるとします。クラスインスタンスをシリアル化するには、そのクラスに特別な属性を追加する必要があります。そのため、クラスには別の責任があります。それはSRPに違反していませんか？
別の例、つまりインターフェースの実装を見てみましょう。インターフェイスを実装するときは、リソースの破棄やインスタンスの比較など、他の責任を追加するだけです。
だから私の質問。SRPを厳守することは可能ですか？どのようにそれを行うことができますか？
ソフトウェア開発で最もよく知られている原則のどれも、100% 従うことはできないことにいつか気づくでしょう。
プログラミングとは、多くの場合、妥協点です。抽象的な純粋さ、コード サイズ、速度、効率などです。
適切なバランスを見つけることを学ぶ必要があるだけです。アプリケーションが混乱の深淵に陥らないようにするだけでなく、多数の抽象化レイヤーと手を組まないようにしてください。
シリアライズ可能または使い捨てであることは、複数の責任につながるとは思いません。
最初に注意すべきことは、これらはソフトウェア エンジニアリングの優れた原則であるということです。判断も適用する必要があります。その意味で - いいえ、それらはしっかりしていません (!)
あなたが尋ねた質問は重要なポイントを提起すると思います-クラスが持つべき単一の責任をどのように定義しますか?
責任を定義するときは、詳細に行き詰まりすぎないようにすることが重要です。クラスがコードで多くのことを行うからといって、クラスに多くの責任があるとは限りません。
とはいえ、がんばってください。すべてのケースに適用することはおそらく不可能ですが、コードに単一の「神のオブジェクト」(アンチパターン) を含めるよりはましです。
これらに問題がある場合は、以下を読むことをお勧めします。
リファクタリング - Martin Fowler: 明らかにリファクタリングに関するものですが、この本は、問題を論理的な部分または責任に分解する方法を示すのにも非常に役立ちます。これは SRP の鍵です。この本は他の原則にも触れていますが、これまで見てきたよりもはるかに学術的ではありません。
きれいなコード - ロバート・マーティン: SOLID 原則の最大の指数よりも優れた読み手. 真剣に、SOLID の原則だけでなく、ソフトウェア クラフトマンシップのすべての分野で、この本が本当に役立つ本であることがわかりました。Fowler の本と同様に、この本はあらゆるレベルの経験を対象としているので、誰にでもお勧めします。
SOLID の原則をよりよく理解するには、SOLID の原則が解決する問題を理解する必要があります。
オブジェクト指向プログラミングは、構造化/手続き型プログラミングから生まれました。新しい組織システム (クラスなど) と動作 (ポリモーフィズム、継承、合成) が追加されました。これは、オブジェクト指向が構造化/手続き型オブジェクト指向から切り離されたものではなく、進歩であり、開発者が必要に応じて非常に手続き型オブジェクト指向を実行できることを意味していました。
つまり... SOLID は、「私は本当に OO を行っているのか、それとも手続き型オブジェクトを使用しているだけなのか?」という質問に答えるリトマス試験紙のようなものとして登場しました。5 つの原則に従えば、スペクトルの OO 側にかなり遠いことを意味します。これらのルールを満たさないからといって、OO を行っていないわけではありませんが、より構造的/手続き的な OO であることを意味します。
これらの分野横断的な懸念 (シリアライゼーション、ロギング、データ バインディング通知など)は、他のサブシステムをサポートするためだけに存在する複数のクラスに実装を追加することになるため、ここには正当な懸念があります。この実装はテストする必要があるため、クラスは間違いなく追加の責任を負っています。
アスペクト指向プログラミングは、この問題を解決しようとするアプローチの 1 つです。C# での良い例はシリアライゼーションです。シリアライゼーションには、さまざまな種類のシリアライゼーションにさまざまな属性があります。ここでの考え方は、クラスはシリアル化を実行するコードを実装するべきではなく、シリアル化する方法を宣言するべきだということです。メタデータは、他のサブシステムにとって重要であるが、クラスのテスト可能な実装には関係のない詳細を含めるのに非常に自然な場所です。
クラスの主要な責任を曖昧にすることなく、クラスが実行できるマイナーで一般的なタスクがたくさんあると思います: シリアライゼーション、ロギング、例外処理、トランザクション処理など。
クラス内のどのタスクがビジネス/アプリケーション ロジックの観点から実際の責任を構成するか、および何が単にコードを配管するかについては、あなたの判断に委ねられています。
設計原則について覚えておくべきことは、常に例外があり、シナリオ/実装が特定の原則に 100% 一致するとは限らないということです。
そうは言っても、シリアライゼーション/デシリアライゼーションコードが他のクラスにあると仮定すると、属性をプロパティに追加しても、クラスに機能や動作が実際に追加されるわけではありません。クラスの構造に関する情報を追加しているだけなので、原則に違反しているようには見えません。
「単一の責任」の定義を変更することにより、SOLID の原則は非常に流動的であり (頭字語の他のキャッチーな頭字語と同様に)、それらが意味するように見えるものを意味しません。
これらはチェックリストまたはチート シートとして使用できますが、完全なガイドラインとしてではなく、もちろん学習教材としても使用できません。
SOLIDは次の略です。
これらは、OOP について話すときに参照する標準です。ただし、これらの原則のいずれも、ソフトウェア開発で完全に満たすことはできません。
このトピックに関する非常によく説明されたプレゼンテーションをここで見ることができますhttp://www.slideshare.net/jonkruger/advanced-objectdirectionalsolid-principles