SOLID与避免过早抽象

我了解SOLID在模块化很重要且其目标显然有用的情况下应定期完成并使用的功能。但是，有两点使我无法在代码库中一致地应用它：

• 我想避免过早的抽象。以我的经验，绘制没有具体用例（现在或可预见的将来）的抽象线会导致将它们绘制在错误的位置。当我尝试修改此类代码时，抽象行会妨碍您的工作，而不是有所帮助。因此，我倾向于不画任何抽象线，直到我对它们的用处有了一个很好的认识。

• 我发现很难证明增加模块化本身是合理的，如果它使我的代码更冗长，更难理解等，并且不能消除任何重复。我发现有时，简单，紧密耦合的过程或God对象代码比构造良好的馄饨代码更易于理解，因为流程简单且线性。编写起来也容易得多。

另一方面，这种心态常常导致神的对象。我通常会保守地重构它们，仅在看到清晰的模式出现时才添加清晰的抽象线条。如果您显然不需要更多的模块化，没有大量重复且代码可读性强，那么上帝对象和紧密耦合的代码怎么办？

编辑：就个别SOLID原则而言，我想强调的是，Liskov Substitution是IMHO的常识形式化，应在所有地方应用，因为如果不是这样的话，抽象是没有意义的。同样，每个类都应该在某个抽象级别上担负单个责任，尽管这可能是一个很高的级别，将实现细节都塞进一个庞大的2,000行类中。基本上，您的抽象应该在您选择抽象的地方有意义。在模块化不是很有用的情况下，我所质疑的原则是开放式，接口隔离，尤其是依赖关系倒置，因为这些都是关于模块化的，而不仅仅是让抽象有意义。

以下是可以应用的简单原理，以帮助您了解如何平衡系统设计：

• 单一责任原则：S在SOLID中。就方法数量或数据量而言，您可以拥有一个非常大的对象，并且仍然坚持这一原则。以Ruby String对象为例。该对象拥有的方法超出了您的承受范围，但它仍然只有一个责任：为应用程序保留一串文本。一旦您的对象开始承担新的责任，就开始认真思考。维护问题是在问自己“如果以后遇到问题，我希望在哪里找到此代码？”
• 简单很重要：爱因斯坦（Albert Einstein）说：“让一切尽可能简单，但不要简单。” 您真的需要这种新方法吗？您可以利用现有功能完成所需的工作吗？如果您确实认为需要新方法，是否可以更改现有方法来满足您的所有需求？本质上，您在构建新东西时会进行重构。

本质上，您在尝试维护软件时要尽其所能，以免摔伤自己。如果您的大型对象是合理的抽象，则没有理由将它们分割开来，仅仅是因为有人提出了一个度量标准，即一个类不应超过X行/方法/属性/等。如果有的话，那是指导方针，而不是一成不变的规则。

我认为您大部分已经回答了自己的问题。当需要将概念提升到抽象级别时，SOLID提供了一组有关如何重构代码的准则。

像所有其他创造性学科一样，没有绝对的取舍。您做得越多，就越容易确定何时才足以满足您当前的问题领域或需求。

话虽这么说-抽象是软件开发的核心-因此，如果没有充分的理由不这样做，那么实践将使您变得更好，并且您会有所取舍。因此，除非它变得有害，否则请青睐它。

I want to avoid premature abstraction.In my experience drawing abstraction lines without concrete use cases... 

这是部分正确和部分错误。

错误
这不是阻止人们应用OO原则/ SOLID的原因。这只能防止过早应用它们。

那是...

正确
不要重构代码，直到重构为止。当要求完成时。或者，当您所说的“用例”都在那里时。

I find simple, tightly coupled procedural or God object code is sometimes easier to understand than very well-factored...

当单独工作或在筒仓中工作时，
不立即发现OO的问题并不明显。编写程序的第一个版本后：

Code is fresh in your head
Code is familiar
Code is easy to mentally compartmentalize
You wrote it

这些善事中的3/4会在短时间内迅速消失。

最后，您认识到您拥有上帝的对象（具有许多功能的对象），因此您会认识到各个功能。封装。将它们放在文件夹中。偶尔使用接口。请帮您长期维护。特别是由于非重构方法趋于无限膨胀并成为上帝方法。

在团队中
不执行OO的问题将立即引起注意。好的OO代码至少在某种程度上可以自我记录和可读。特别是结合良好的绿色代码时。而且，缺乏结构使得难以分离任务并使集成更加复杂。

大型对象和紧密耦合的代码在适当的情况下且不需要任何经过精心设计的代码时没有任何问题。这只是经验法则变成教条的另一种表现。

在许多常见情况下，松散耦合和小的简单对象往往会提供特定的好处，因此通常使用它们是一个好主意。问题出在那些不了解原则背后原理的人，他们盲目地试图普遍应用这些原则，即使在不适用的地方也是如此。

我倾向于从“您将不需要它”的角度来解决这个问题。这篇文章将特别关注一个项目：继承。

在我最初的设计中，我创建了一个层次结构，我知道将有两个或多个层次结构。他们可能需要很多相同的代码，因此值得一开始就进行设计。在初始代码到位之后，我需要添加更多功能/特性，然后查看一下我所拥有的，并认为：“我已经实现了相同或相似的功能吗？” 如果是这样，那很可能是一个新的乞讨被发布。

MVC框架就是一个很好的例子。从头开始，您将创建一个大页面，后面有一个代码。但是然后您想添加另一个页面。但是，后面的一个代码已经实现了新页面所需的许多逻辑。因此，您将抽象出一个Controller类/接口，该类/接口将实现特定于该页面的逻辑，而将常见的东西留在原始的“神”代码中。

如果您作为开发人员知道由于代码的未来而何时不应用这些原则，那么对您有好处。

我希望SOLID仍然在您的脑海中，知道何时确实需要抽象一些东西，以避免复杂性并提高代码质量（如果它开始降低您声明的值）。

不过，更重要的是，请考虑大多数开发人员都在做日常工作，而不是像您一样不在乎。如果您最初设置了长时间运行的方法，那么代码中的其他开发人员在维护或扩展它时会考虑什么呢？上帝的对象，他们没有记住捕捉不断增长的代码并正确封装它的原则。您“可读”的代码现在变得一团糟。

因此，您可能会争辩说，一个糟糕的开发人员无论如何都会这样做，但如果从一开始就保持简单和井井有条，至少您会拥有更好的优势。

如果它们很简单，我并不特别介意全局的“注册表”或“上帝对象”。它实际上取决于系统设计，有时您可以摆脱它并保持简单，有时则不能。

我们也不要忘记大型函数和God Objects很难测试。如果您想保持敏捷并在重构和更改代码时感到“安全”，则需要进行测试。当函数或对象执行许多操作时，很难编写测试。

神物的问题在于您通常可以从中获利分成几块。根据定义，它做的不只一件事。将其分为较小的类的全部目的是使您可以拥有一个能够完成一件事的类（并且您也不应该扩展“一件事”的定义）。这意味着，对于任何给定的类，一旦知道了它应该做的一件事，就应该能够相当容易地阅读它，并说出它是否在正确地完成那件事。

我认为是这样的东西有太多的模块，和太多的灵活性，但是这更多的过度设计和过度工程问题，在哪里你是会计的要求，你甚至不知道客户需要。许多设计思想都是围绕着使控制代码运行方式的更改变得容易而进行的，但是如果没有人期望更改，那么包含灵活性就毫无意义。

我使用一个更简单的准则：如果您可以为其编写单元测试，并且没有代码重复，那么它就足够抽象了。另外，您在以后的重构中处于有利位置。

除此之外，您应该牢记SOLID，但更多的是作为指导而非规则。

如果您显然不需要更多的模块化，没有大量重复且代码可读性强，那么上帝对象和紧密耦合的代码怎么办？

如果应用程序足够小，则任何内容都是可以维护的。在更大的应用中，上帝的物体很快成为一个问题。最终实现一个新功能需要修改17个God对象。按照17个步骤进行操作的人做得不好。上帝的对象不断地被多个开发人员修改，这些更改必须重复合并。你不想去那里。

我同意您对过多和不适当的抽象的关注，但不必一定担心过早的抽象。

这听起来像是一个矛盾，但是只要您不过早地使用它（即只要您愿意并且能够在必要时进行重构），那么使用抽象就不太可能引起问题。

这意味着在代码中进行某种程度的原型设计，试验和回溯。

也就是说，没有简单的确定性规则可以解决所有问题。经验很重要，但是您必须通过犯错来获得经验。而且总是会有更多的错误使以前的错误不会为您做好准备。

即使这样，也应将教科书的原则作为起点，然后学习编程知识并了解这些原则的工作原理。如果可以提供比SOLID之类的更好，更精确和可靠的指南，那么现在有人可能会这样做-即使有，这些改进的原理仍将是不完善的，人们会问这些规范的局限性。

也是一项好工作-如果任何人都可以提供清晰的确定性算法来设计和编码程序，那么只有最后一个程序可供人类编写-该程序可以自动编写所有将来的程序而无需人工干预。

绘制适当的抽象线条是从经验中汲取的东西。这样做会犯错误，这是不可否认的。

SOLID是那种经验的集中形式，这些经验是由很难获得经验的人交给您的。当您说在看到需要抽象之前就不要创建抽象时，您几乎钉住了它。SOLID提供的经验将帮助您解决从未出现过的问题。但是请相信我...这是非常真实的。

SOLID与模块化有关，模块化与可维护性有关，可维护性是指一旦软件进入生产阶段并且客户端开始注意到您所没有的错误，您就可以保持人性化的工作计划。

模块化的最大好处是可测试性。系统的模块化程度越高，测试就越容易，并且可以更快地建立扎实的基础来解决问题的更难方面。因此，您的问题可能并不需要这种模块化，而事实是它可以使您更快地创建更好的测试代码，这是不费吹灰之力争取模块化的事实。

敏捷就是在快速运输和提供优质产品之间寻求微妙的平衡。敏捷并不意味着我们应该走捷径，实际上，我参与过的最成功的敏捷项目就是那些密切关注此类准则的项目。

似乎已被忽略的重要一点是SOLID与TDD一起使用。TDD倾向于强调在您的特定情况下什么是“适当的”，并有助于减轻建议中似乎存在的许多歧义。