基本的に、実際のコードで単一責任の原則を使用することが合理的であると考える人の割合と、実際に使用する人の数を把握したいと思います。ポッドキャスト＃38で、ジョエルはこのOOPの原則が現実の世界でどれほど役に立たないかについて語っています。さらに、これは、ボブおじさんのような人々が重要なシステムを作成していない可能性が高いことを示しています。
私はいくつかのソフトウェアプロジェクトで個人的に書いたり、大きな役割を果たしたりしましたが、若いキャリアの中でこのパターンに出くわしたのは今だけです。私はこの原理の音が大好きで、本当に使い始めたいと思っています。私はポッドキャストでのジョエルの議論が非常に弱いことに気づきました（ここでブログのコメントを読み続けると他の人もそうしました）。しかし、それに真実はありますか？
コミュニティはどう思いますか？
私はSOLIDの原則を適用した経験があり、私の経験は主に良いものでした. ポッドキャストも聞いたのですが、ジェフもジョエルも、彼らが話していることのどれも、その利点を実際に評価するのに十分な長さで試していないようです. 反対の主な議論は、通常、「より多くのコードを書く」ことです。私が何をしているかを見ると、10 から 20% も多くのコード (通常はインターフェース定義) を書いていますが、すべてが高度に分離されているため、はるかに保守しやすくなっています。アプリケーションの一部を変更すると、他の部分が壊れるという状況はめったにありません。したがって、私が維持しなければならない 20% の余分なコードは、それだけで元が取れます。
Jeff は、コードの品質についても指摘していませんでした。彼は、コードの品質が顧客にとって大きな利益になるとは考えていません。彼の言うとおり、顧客は気にしません。顧客は新機能を迅速に実装することを気にかけているため、コード品質の出番です。コードの品質を可能な限り高く保つための投資は、常に数か月以内に元が取れることがわかりました。高品質 = 低メンテナンス。
私は、あなたがこれらのことについて実用的にならなければならないものは何でも好きだという彼らに同意します. 何かを提供する必要がある場合は、先に進んで迅速かつダーティに実行してください。でも後片付け。
Joelのコメントを読んだり聞いたりしたことがないので、具体的にコメントすることはできません。
厳密な要件ではなく、目標の観点から単一責任の原則を検討する必要があると思います。ソフトウェア開発の多くのことと同様に、努力すべき理想がありますが、コードに金銭的な利益やコストがない場合を除いて、顧客のニーズに応えるには実用的でなければなりません。
実際には、OOの状況で真のSRPを取得することは非常に困難です。複雑なシステムに存在するクラスを考えてみましょう。おそらくビジネス指向の責任（レポートの印刷など）は1つだけですが、ロギングや例外処理など、純粋なSRPの理想に違反する他の多くの責任が内部にあります。ロギングメカニズムを大幅に変更する場合は、印刷クラスが行う呼び出しを変更する必要があります。
これがAOPが考案された理由です。これを使用すると、ロギングを変更するためにロギングクラス以外を変更する必要はありません。
明らかな理由でビジネス指向のSRPを目指して努力するのは良いことですが、十分に複雑なシステムでは、OOPで真のSRPを取得することはできません。AOP、確かに、しかしOOPではありません。
それがジョエルの推論であるかどうかはわかりませんが、それが私がその考えにアプローチする方法です。
多数のプログラミング理論の最大の問題は、コードの優れた属性が実際にはコードの優れた属性であることを示唆することに焦点を当てていることです。それらは本質的に正しいため、特に有用ではありません。
はい、コードは適切に作成する必要があります。はい、物事をひどく繰り返すべきではありません。また、変更によって予期しない場所で奇妙な中断が発生するべきではありません。しかし、結局のところ、シンプルでわかりやすい方法でソリューションを表現する、非常にシンプルで一貫性のあるコードは、いくつかの厳格な原則を満たす大規模で複雑なシステムよりもはるかに価値があります。業界として、私たちは良いアイデアを行き過ぎてしまいがちで、最良のソリューションではなく「正しい」ソリューションを求めて、不必要な複雑さを大量に生み出してしまいます。
ポール。
SOLID の原則は、クラスを設計するときに通常適用される自然/ビジネス ロジックに準拠しない場合があると思います。Robert C. Martin は、Rectange クラスと Square クラスの例を挙げました (Square は Rectangle の子孫であってはなりません)。
http://www.hanselminutes.com/default.aspx?showID=163
SRPに関するものかどうかはわかりませんが、考え方は同じです。SOLID の原則は直感に反する決定につながる可能性があり、この障壁を乗り越えるのは困難です。
私にとって、「ガイドライン」は「原則」よりも適切な名前です。
一般的に、私は SOLID の原則に同意しますが、それらを文脈に取り入れる必要もあります。概念実証を作成している場合、SOLID の原則はあまり当てはまりません。
一方、何年にもわたる寿命を持つ製品を開発している場合は、SOLID の原則を注意深く見て適用することをお勧めします。そうしないと、会社の生産性に莫大な費用がかかることになります。
ジョエルと彼のコメントに関して、彼は正当な意見を持っています。製品を出荷する必要があるか、会社が失敗することがあります。仕方ないよ。
製品を出荷するのは開発者としてのあなたの仕事ですが、締め切りが厳しいからといって、貧弱なアーキテクチャを採用するわけではありません。データセットを使用するか、ビジネス エンティティを使用するかなどの選択は簡単な決定であり、どちらも同様の実装作業がありますが、長期的には、2 つの間の新機能の開発と保守は劇的です。