我正在开发一个非常大的ASP.NET应用程序。问题是设计背后没有很多逻辑。最初的开发人员选择了大约十个类，就是这样。具有高耦合和低内聚力。例如，clsPerson保存了Person的所有功能，并破坏了SOLID的大部分规则。
我已经开始将设计模式合并到我的工具包中。我的问题是：将设计糟糕的类合并到更好的设计中的最佳方法是什么。例如，如果你有一个clsStudent类，它包含了迄今为止所有的Student功能，然后创建了一个名为clsUndergraduate的类，那么你只需要派生clsStudent吗？我意识到很多这取决于背景，但我正在寻找一般准则。
网上有很多关于SOLID的信息，但谈论如何使现有应用程序适应SOLID并不是很多。
答案 0 :(得分：0)
可以说，您应该只在实现SOLID原则时，并在需要时实施。但是，我是一名倡导者，并且相信在没有太多开销或心痛的情况下为您的设计添加SOLIDity元素并不困难。
尝试将现有模型移动到更多SOLID模型可能很困难。我建议采用小型，易处理的部件并逐步重构。如果您拥有自动化测试的安全网，那么这应该可以放心地实现。如果没有，请确保您完全了解所做更改的范围。引入微妙的错误很容易。最终，严重的变化可能会引入新的测试。
遵守SRP可能是最容易开始的地方。尝试定义每个类的主要职责。如果他们目前有多个责任，请记下这些责任并查看如何将这些责任转移到其他地方。例如，许多“上帝”类将管理持久性，验证，初始化等以及业务逻辑。看看你是否可以开始使用持久性代码并将其放入映射器/存储库/等。
如果按逻辑顺序执行此操作，我的经验是，随着时间的推移，在此过程中会犯很多错误，其他原则的相关性和重要性将会出现并使其自身变得明显。
我发现，当我尝试使用SOLID原则时，通过阅读和重新阅读（主要是Bob Martin和ObjectMentor），您可以获得更多的清晰度，因为您具有实施的实践经验。不要忘记四人帮中定义的开放原则。像'赞成组合而非继承'这样的概念与SOLID OO原则齐头并进。
请记住，SOLID代码通常比非SOLID代码更复杂，因此，那些不熟悉它的人更难维护和调试。怀疑论者可能会在你的门口指责“过度工程化”，这可能很难与那些没有加强/修复紧密耦合，不连贯的代码的人争论。
祝你好运。请随意多问一下，因为我很乐意听到其他人对此主题的意见。它的范围广泛而多样。