我正在开发一个非常大的 ASP.NET 应用程序。问题是设计背后没有太多的逻辑。最初的开发者选择了大约十个类，仅此而已。耦合度高，内聚度低。例如，clsPerson 拥有 Person 的所有功能，并打破了 SOLID 的大部分规则。
我已经开始将设计模式整合到我的工具包中。我的问题是：将设计不佳的类合并到更好的设计中的最佳方法是什么。例如，如果您有一个类 clsStudent，它包含迄今为止的所有 Student 功能，然后创建了一个名为 clsUndergraduate 的类，那么您会简单地派生 clsStudent 吗？我意识到这在很大程度上取决于上下文，但我正在寻找一般指导方针。
网上有很多关于 SOLID 的信息，但没有很多关于如何将现有应用程序改编为 SOLID 的信息。
可以说，您应该只在需要时实施 SOLID 原则。但是，我是一名倡导者，我相信在您的设计中添加 SOLIDity 元素并不难，而且不会带来太多开销或心痛。
尝试将现有模型移动到更可靠的模型可能很困难。我建议采用小的、可管理的部分并逐步重构。如果你有自动化测试的安全网，这应该是可以自信地实现的。如果没有，请确保您完全了解所做更改的范围。很容易引入细微的错误。最终，无论如何，严重的变化可能会引入新的测试。
遵守 SRP 可能是最容易开始的地方。尝试定义每个类的主要职责。如果他们目前有多个职责，请注意他们并查看如何将这些职责移出和其他地方。例如，许多“上帝”类将与业务逻辑一起管理持久性、验证、初始化等。看看你是否可以开始取出持久性代码并将其放入映射器/存储库/等。
如果你按照逻辑和顺序执行此操作，我的经验是，当你在此过程中犯很多错误时，其他原则的相关性和重要性就会显现出来，并让自己变得显而易见。
我发现，当我尝试使用 SOLID 原则时，通过阅读和重新阅读（主要是 Bob Martin 和 ObjectMentor），当您拥有实施的实践经验时，就会更加清晰。不要忘记四人帮中定义的开放原则。“优先组合优于继承”等概念与 SOLID OO 原则密切相关。
请记住，SOLID 代码通常比非 SOLID 代码更复杂，因此，不熟悉它的人更难维护和调试。怀疑论者可能会在你家门口指责“过度工程”，这可能很难与那些没有与增强/修复紧密耦合、不连贯的代码作斗争的人反驳。
Good luck. Please feel free to ask more as I'd love to hear the input of others on this subject. It's scope is wide and varied.