SOLID vs.

Question

我听到的关于在面向对象设计中不遵守实心原则的最常见的论点之一是雅格尼 (尽管论述者通常不这么说)：

“我把特性X和特征Y放在同一个类中是可以的。这太简单了，为什么还要添加一个新类(即复杂性)。”

“是的，我可以将我所有的业务逻辑直接放入GUI代码中--它更容易、更快。这将永远是唯一的GUI，而且很不可能出现重大的新需求。”

“如果在不太可能出现新需求的情况下，我的代码变得过于混乱，我仍然可以为新的需求进行重构。所以您的‘如果您以后需要…’的论点不算。”

你对这种做法最有说服力的论据是什么？我如何才能真正证明这是一个昂贵的实践，特别是对那些没有太多软件开发经验的人来说。

Answer 1

设计是权衡的管理和平衡，、YAGNI和SOLID并不矛盾:前者说什么时候添加特性，后者说如何添加，但它们都指导设计过程。下面，我对你们每个具体引文的答复都使用了YAGNI和SOLID的原则。

1. 构建可重用组件的难度是单个使用组件的三倍。
2. 一个可重用组件应该在三个不同的应用程序中进行测试，然后才能使其足够通用，可以接受到重用库中。

罗伯特·格拉斯的三条规则，https://rads.stackoverflow.com/amzn/click/com/0321117425

重构为可重用的组件有一个关键要素，就是首先在多个地方找到相同的用途，然后再移动它。在这种情况下，YAGNI的应用是在需要时插入这个目的，而不必担心可能的重复，而不是添加通用或可重用的特性(类和函数)。

在初始设计中，当YAGNI不适用时，最好的方法是确定具体的需求。换句话说，在编写代码之前进行一些重构，以表明复制不仅是可能的，而且已经存在:这就证明了额外的努力是合理的。

是的，我可以将我所有的业务逻辑直接放入GUI代码中--它更容易、更快。这将永远是唯一的GUI，而且新的需求不太可能出现。

它真的是唯一的用户界面吗？是否计划了后台批处理模式？会有一个网络接口吗？

您的测试计划是什么，您会在没有GUI的情况下测试后端功能吗？什么将使GUI易于测试，因为您通常不希望测试外部代码(例如平台-通用GUI控件)，而是集中精力于您的项目。

我可以把特性X和特征Y放在同一个类中。它是如此简单，为什么要添加一个新的类(即复杂性)。

你能指出一个需要避免的常见错误吗？有些事情很简单，比如用一个数字(x * x vs squared(x))来表示一个过于简单的例子，但是如果你能指出某人犯了一个具体的错误--尤其是在你的项目中或者在你的团队中--你可以展示一个普通的类或函数将来是如何避免的。

如果在不太可能出现新需求的情况下，我的代码变得过于混乱，我仍然可以为新的需求重构。所以你的“如果你以后需要.”争论不算数。

这里的问题是“不太可能”的假设。你同意这不太可能吗？如果是的话，你就同意这个人了。如果不是，你对设计的想法与这个人的想法不一致--解决这个差异会解决问题，或者至少告诉你下一步该去哪里。:)

Answer 2

我喜欢用“一半，而不是一半”来考虑YAGNI，借用37 YAGNI (Assed.php)的短语。它是关于限制你的范围，这样你就可以专注于做好最重要的事情。这不是草率的借口。

GUI中的业务逻辑让我感到半途而废。除非您的系统是琐碎的，否则如果您的业务逻辑和GUI还没有独立地更改几次，我会感到惊讶。因此，您应该遵循SRP (SOLID中的“S”)和refactor - YAGNI不适用，因为您已经需要它了。

关于YAGNI和不必要的复杂性的争论，如果您今天要做额外的工作以适应假设的未来需求，则绝对适用。当那些“如果以后我们需要.”场景无法实现，您将从抽象中陷入更高的维护成本，这些抽象现在阻碍了您实际拥有的更改。在这种情况下，我们讨论的是通过限制范围来简化设计--做一半，而不是一半。

Answer 3

听起来你在和砖墙吵架。我是YAGNI的忠实粉丝，但同时，我也希望我的代码总是至少在两个地方使用:应用程序和测试。这就是UI代码中的业务逻辑不能工作的原因；在这种情况下，不能单独测试UI代码的业务逻辑。

然而，从你所描述的反应来看，听起来这个人只是对做更好的工作不感兴趣。在这一点上，没有任何原则可以帮助他们，他们只想做最低限度的可能。我要说的是，这不是YAGNI驱动他们的行为，而是懒惰，而只有你一个人无法战胜懒惰(除了一个威胁性的经理或失去一份工作外，几乎没有什么可以克服的)。