SOLID原则与YAGNI

SOLID原则何时会成为YAGNI？

作为程序员，我们始终在复杂性，可维护性，构建时间等之间进行权衡。在我看来，其中两项最明智的选择准则是SOLID原则和YAGNI。如果您不需要它；不要建造它，并保持干净。

现在，例如，当我观看SOLID上的dimecast系列节目时，我看到它开始时是一个非常简单的程序，然后结束时是一个非常复杂的程序（当然，在旁观者看来，复杂性也是如此），但是它仍然使我想知道：SOLID原则何时会变成您不需要的东西？所有坚实的原则都是可以使用户在以后进行更改的工作方式。但是，如果要解决的问题是一个非常简单的问题，并且是一个一次性应用程序，该怎么办？还是SOLID原则始终适用？

如评论中所述：

• SOLID原则
• 亚尼

始终很难根据截屏视频来判断方法，因为为演示选择的问题通常很小，以至于很快应用SOLID之类的原理会使解决方案看起来完全过分设计。

我想说SOLID原则几乎总是有用的。一旦您精通它们，似乎就不必刻意考虑使用它们了。它变得自然。我已经看到许多一次性的一次性应用程序变得不仅仅如此，所以我现在害怕说我会扔掉一些东西，因为您永远都不知道。

我通常采用的方法是，如果我为某个特定的任务编写一个简单的应用程序，有时我会放弃大名鼎鼎的原则，而转而使用几行有效的代码。如果我发现我要回到该应用程序进行进一步的更改，我将花一些时间使它变为SOLID（至少要稍作调整，因为100％应用该原理很少可行）。

在较大的应用程序中，我从小处着手，随着程序的发展，我尽可能使用SOLID原理。这样，我不会尝试从头到尾设计整个对象。对我来说，这是YAGNI和SOLID共存的最佳地点。

首先要考虑当前的问题。如果您盲目地应用YAGNI或SOLID的原理，以后可能会伤害自己。我希望我们大家都能理解的是，没有适合所有问题的“一种”设计方法。您可以看到有证据表明，一家商店出售标有“一种尺寸适合所有人”的帽子，但不适合您的头部。它太大或太小。

相反，最好了解SOLID试图解决的原理和问题。以及YAGNI试图解决的原理和问题。您会发现一个与应用程序的体系结构有关，另一个与整个开发过程有关。尽管在某些情况下可能存在重叠，但是它们是截然不同的问题。

YAGNI（您不会需要它[古朴的美国首字母缩写词]）与节省开发人员的时间有关，目的是在桥梁上增加钢筋混凝土基础，该基础仅打算跨越3英尺宽的小溪，而更简单的木桥只会精细。如果我们横跨一英里宽的河流，并且需要支撑多辆拖车，那么我们当然需要进行额外的基础工作。本质上，YAGNI告诉您要从更大的角度出发，并针对当前需求进行设计。它正在解决使某些事情变得过于复杂的问题，因为我们预计客户还没有发现许多潜在的需求。

SOLID与我们如何确保桥的各个部分正确装配在一起以及如何随时间进行维护有关。您可以将SOLID原理应用于木桥以及钢筋混凝土桥。

简而言之，这两个概念不一定相互冲突。当您遇到自己认为是的情况时，就该看看全局了。根据您的结论，您可能决定取消部分SOLID原则，或者可能确实确定确实需要它。

当是一次性应用程序时，不需要SOLID原理。否则，总是需要它们。

SOLID和YAGNI并不矛盾：良好的类设计使应用程序更易于维护。YAGNI只是声明您不应该为应用程序添加功能，使其成为可以在阳光下做所有事情的可配置怪兽，除非它确实需要它。

这是具有明确定义的边界（SOLID）的汽车类与具有自愈能力（YAGNI）的汽车类（在客户提出要求之前）之间的区别。

没有什么总是适用的！不要让建筑宇航员吓到您！重要的是要尝试了解这些原则要解决的问题，以便您可以就应用这些原则做出明智的决定。

最近，我试图了解何时应该使用“单一责任原则”（这是我想出的。）

希望这可以帮助！

爱因斯坦（Einstein）引述了一个报价（可能是对实际报价的一种变体）：

“一切都应该尽可能简单，但不要简单。”

而这几乎是我在SOLID与YAGNI权衡中所采用的方法：交替应用它们，因为您永远不知道程序是否是“扔掉”的代码。因此，只需添加一层可以使用的污垢，然后将其抛光到更清洁的界面...，然后重复进行，直到收敛到正确的熵水平为止。希望。

针对给定问题设计程序的方法有很多。SOLID是一种尝试识别良好设计的属性的尝试。正确使用SOLID应该可以使程序更易于推理和修改。

YAGNI和KISS关注功能范围。解决更多类型问题的程序更加复杂和抽象。如果您不需要这种通用性，那么您就花了很多时间和精力来创建难以理解和维护的代码，但没有附加值。

设计良好的程序不一定只关注其所需的功能。仅专注于所需功能的程序不一定设计得很好。没有权衡取舍，决策空间中只有两个正交轴。理想的程序既是模块化的，也只有基本功能。

我认为您应该启动YAGNI，并在需要时进行SOLIDify。

我的意思是说SOLID在那里，所以当您添加一个新类时，您无需进行重构，只需切换一个实现（例如），我认为，可以简单地编写代码，并且当您看到要更改时东西-用SOLID进行更改（即，担心重构SOLID应该可以使您免于遭受损失-当您刚入门时，它并没有那么糟糕）。

您并没有在浪费时间，因为无论如何（一开始）您都必须要做工作，并且无论何时何地，您的代码都非常整洁。

我猜您可以称其为SOLID的惰性评估。