SOLID原则或无SOLID

Question

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

问题在于很多课程的内聚力很低，并且高度耦合，很多课程都没有一个责任（他们有很多）。我的具体问题是：我应该开始遵循SOLID原则，还是继续通过tweeking并在类中添加更多内容来开发？我一直试图遵循像SOLID这样的原则，但我所说的应用程序非常庞大而且复杂。我是这个项目的唯一开发人员。

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

更新15/07/2012 到目前为止，我发现SOLID是一个设计原则，GRASP是一种设计模式，它可能更适合MVC而不是页面控制器类型的应用程序。根据此链接，模拟对象也可能更适合MVC：http://www.asp.net/mvc/tutorials/older-versions/overview/asp-net-mvc-overview。根据迄今为止的反应，遵循SOLID原则始终是一种良好的做法。但是，到目前为止，答案并不建议基于表单的应用程序的设计模式。

Answer 1

尝试一点一点地重构。

如果您正在处理模块，请尝试在此处添加一些接口;-)随时随地。您编写的任何新代码都应该是SOLID。尝试尽可能地封装旧代码，将旧垃圾放在外观后面。你现在不必重写它，也许永远不会。只要您可以将旧代码封装在外观后面并为外观编写单元测试，您应该感觉好多了。

示例：假设您有一组实现某些功能的类，即。发票处理。现在我想象这些类在许多地方使用，并且有很多重复。计算总发票金额的代码将复制到显示它的每个页面上。在这种情况下我要做的是创建一个Invoice服务，它将公开获取发票，添加新行，计算总金额等方法。您可以将您拥有的代码放在此服务中而不需要太多重构，您将保持相同的数据库架构等。但是从现在起，您的页面将仅与IInvoiceService界面进行交互，您可以很好地模拟它。它有点“在地毯下刮尘”，但至少可以阻止垃圾蔓延。下次您需要在开票模块中执行某些操作（修复错误，实现新功能）时，请稍微清理现有代码。随着时间的推移，地毯下的灰尘量变得越来越小。你只需要坚持你的枪支，并确保服务界面保持良好和干净。

您可能需要进行更多系统范围的更改，例如引入DI框架，但请尝试将更改保持在最低限度。通常当你开始走远时，你很容易发现自己重写了一切，而你却不希望如此。

进行小的更改，经常提交。

Answer 2

这就像是在问“好吧，我刚刚从别人那里买了一套公寓，但到处都是污垢。我应该把它清理干净还是留下它？”

答案很明显。你说申请很复杂。如果它因为糟糕的架构而变得复杂 - 那么你就有机会让它更容易理解。由于业务问题的性质，它很复杂，糟糕的架构只会让它变得更糟。

SOLID是非常重要的原则。同时注意GRASP指南，我猜你是这样做的，因为你提到了低耦合和高内聚，这些属于GRASP而不是SOLID。

最明显的方法是一步一步地重构正确的方向。解耦类，定义它们的职责，使它们更具凝聚力，引入接口和代码来对付它们。这些比SOLID的开放闭合原则或Liskov替代原则重要得多。

Answer 3

我的建议是选择一个功能并启动单元测试并引入一个模拟库，如Moq或FakeItEasy。

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

您已经开始实施DI，但也使用类似AutoMapper的东西可以节省大量时间并使代码更小更清晰

当我像你的情况一样被移交时我所做的就是阅读鲍勃叔叔的书http://www.amazon.co.uk/Working-Effectively-Legacy-Robert-Martin/dp/0131177052它给你一些好主意

评论更新 前三个月的应用程序有更少的错误，更容易和更快地实施新的变化。最好的部分是现在我们拥有领域知识。阻止遗留和导致错误的新变化的一件好事是Anit-Corruption层请阅读此链接http://domaindrivendesign.org/library/peng_hu_2007_2

Answer 4

我曾在一家拥有良好的单元测试代码覆盖率（超过3000次测试）的商店工作，其编写鼓励我们的代码通常遵循SOLID原则。

我还在一家拥有0％代码覆盖率（大约0.5米代码行）的商店工作，但没有采用SOLID。

由于我们没有测试覆盖率，我们无法重构50万行代码中的任何一行（针对SOLID或任何其他原因）。因此，随着时间的推移，代码变得越来越糟糕。

我们不需要在我的第一份工作中重构，因为代码已经是SOLID，但我们可以轻松地重构并使用良好的单元测试代码覆盖率来确保没有回归。

就像魔术一样：那些认为不需要证据的人;对那些不相信没有证据的人来说就足够了。

让我们这样说：你想在某个地方工作的代码非常难以理解，维护起来很糟糕，开发人员因代码如此糟糕而离开，而且错误猖獗或者您更喜欢相反的情况？后者的代码，无论是否为SOLID，但是具有单元测试的IMHO SOLID将使得从长远来看更容易实现这一目标。