非常に大規模な ASP.NET アプリケーションに取り組んでいます。問題は、設計の背後に多くのロジックがないことです。元の開発者は約 10 個のクラスを選択しましたが、それだけです。カップリングが高く、凝集度が低い。たとえば、clsPerson は Person のすべての機能を保持し、SOLID のルールのほとんどを破っています。
デザインパターンをツールキットに組み込み始めました。私の質問は、不適切に設計されたクラスをより良い設計に組み込む最良の方法は何かということです。たとえば、これまでのすべての Student 機能を含むクラス clsStudent があり、次に clsUndergraduate というクラスを作成した場合、単に clsStudent を派生させますか? これの多くは文脈に依存することを認識していますが、一般的なガイドラインを探しています.
SOLID に関する情報はオンライン上にたくさんありますが、既存のアプリケーションを SOLID に適合させる方法についてはあまり触れていません。
SOLID 原則の実装は、必要が生じたときにのみ行うべきであると主張することもできます。しかし、私は支持者であり、SOLIDity の要素を設計に余分なオーバーヘッドや心痛を伴うことなく追加することは難しくないと考えています。
既存のモデルをより堅実なモデルに移行しようとするのは難しい場合があります。小さくて扱いやすい部分を取り、徐々にリファクタリングすることをお勧めします。自動化されたテストの安全策があれば、これは自信を持って達成できるはずです。そうでない場合は、行っている変更の範囲を完全に理解していることを確認してください。微妙なバグを導入するのは簡単です。いずれにせよ、深刻な変更によって新しいテストが導入される可能性があります。
SRP への準拠は、おそらく最も簡単な出発点です。各クラスの主な責任を定義するようにしてください。彼らが現在複数の責任を負っている場合は、それらに注意し、これらの責任をどのように移動できるかを検討してください。たとえば、多くの「神」クラスは、ビジネス ロジックとともに永続性、検証、初期化などを管理します。永続化コードを取り出して、mappers/repositories/etc に配置できるかどうかを確認してください。
これを論理的かつ順番に行うと、私の経験では、途中で多くの間違いを犯しながら進むにつれて、他の原則の関連性と重要性が明らかになり、一種の明白なものになります。
SOLID の原則を試してみると、(主に Bob Martin と ObjectMentor) を読んだり読み直したりすることで、実装の実践的な経験を積むにつれて、より明確になることがわかりました。ギャング・オブ・フォーで定義されたオープニングの原則も忘れないでください。「継承よりも構成を優先する」などの概念は、SOLID OO の原則と密接に関連しています。
一般に、SOLID コードは非 SOLID コードよりも複雑であるため、慣れていない人にとっては保守やデバッグが難しくなる可能性があることに注意してください。懐疑論者は、あなたのドアに「オーバーエンジニアリング」の非難をするかもしれません.
幸運を。この件に関して他の方の意見を聞きたいので、お気軽に質問してください。その範囲は広く、多様です。