固体原理或非固体原理

Question

我正在继续开发一个ASP.NET应用程序(基于web表单)，以前的开发人员没有遵循良好的面向对象设计原则，即SOLID (http://www.remondo.net/solid-principles-csharp-interface-segregation/)。我读过这样的文章：Long-held, incorrect programming assumptions。

问题是，很多类的内聚力都很低，而且耦合性很强，而且很多类没有一个单独的责任(它们有很多)。我的具体问题是:我是应该开始遵循坚实的原则，还是继续通过推特进行开发，并在课程中添加更多内容？在过去，我一直试图遵循像SOLID这样的原则，但是我所说的应用程序是非常庞大和复杂的。我是唯一在这个项目上工作的开发人员。

目前完全重写是不可能的，但总有一天是可能的。

到目前为止，Update15/07/2012已经发现SOLID是一种设计原则，抓取是一种设计模式，它可能更适合于MVC而不是Page类型的应用程序。根据这个链接：http://www.asp.net/mvc/tutorials/older-versions/overview/asp-net-mvc-overview，模拟对象也可能更适合MVC。根据迄今的反应，遵循坚实的原则始终是良好的做法。然而，到目前为止，答案并不推荐基于表单的应用程序的设计模式。

Answer 1

试着一点一点地重构。

如果您正在处理一个模块，请尝试在这里和那里添加一些接口;-)。您编写的任何新代码都应该是可靠的。尽量封装旧代码，把旧的垃圾放在门面后面。你现在不需要重写，也许永远不会。只要您能够将旧代码封装在facade后面，并为facade编写单元测试，您就会感觉好多了。

例如:假设您有一个实现某些功能的类集合，即。发票处理。现在，我想这些类在很多地方都被使用了，并且有很多重复。计算发票总额的代码将在显示它的每一页上复制。在这种情况下，我要做的是创建一个发票服务，它将公开获取发票、添加新行、计算总量等方法。您可以在不进行多次重构的情况下将您在此服务中的代码放入，您将保持相同的db模式等等。但是从现在开始，您的页面将只与IInvoiceService接口交互，您可以很好地模拟它。这有点“在地毯下扫灰尘”，但至少你可以阻止垃圾进一步扩散。下次您需要在发票模块中做一些事情(修复一个bug，实现新特性)时，您可以稍微清理一下现有的代码。随着时间的推移，地毯下的灰尘越来越少。你只需要坚持你的观点，并确保服务界面保持良好和干净。

您可能需要进行更多的系统范围的更改，比如引入DI框架，但尽量将更改保持在最低限度。通常，当你开始走远的时候，你可以很容易地发现自己重写了所有的东西，而你并不想那样做。

做一些小的改变，经常去做。

Answer 2

就像问：“我刚从别人那里买了一套公寓，但是到处都是脏东西。我应该把它打扫干净还是保持原样？”

答案是显而易见的。你说申请很复杂。如果它是复杂的仅仅因为糟糕的架构-有机会让它更容易理解。它是复杂的，因为商业问题的性质，糟糕的架构只会使它变得更糟。

固体是非常重要的原则。也要注意抓取指南，我想你这么做是因为你提到了低耦合和高内聚力，这些都属于抓取而不是固体。

最明显的方法是重构，一步一步地朝着正确的方向前进。解耦类，定义它们的责任，使它们更加一致，引入接口并针对它们编写代码。这些比SOLID的开闭原理或Liskov替换原理重要得多.

Answer 3

我的建议是选择一个特性并开始对它进行单元测试，并引入一个模拟库，比如Moq或FakeItEasy。

我完全理解这是一个交给你的代码。但是，通过单元测试，您将了解哪些代码是单个责任的良好候选代码，或者必须是服务，或者必须在存储库中移动。

您已经将实现DI，但也使用类似AutoMapper之类的工具，可以节省大量时间，并使代码更小、更清晰。

当我像你这样被移交时，我所做的就是读鲍勃叔叔的书“http://www.amazon.co.uk/Working-Effectively-Legacy-Robert-Martin/dp/0131177052”，它给了你一些好的想法。

更新您的评论：应用程序在前3个月有较少的错误，更容易&更快地实现新的变化。最重要的是，我们现在拥有了领域知识。阻止遗留和导致错误的新更改的一件好事是反腐败层，请阅读此链接2。