oop - SOLID 与 YAGNI

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

---

想要改进这个问题吗？更新问题，以便 editing this post 可以用事实和引文来回答它。 .

已关闭 4 年前。

Improve this question

我听到的最常见的关于不遵守 SOLID 的争论之一面向对象设计的原则是YAGNI (尽管争论者通常不这样调用它):

“我可以将功能 X 和功能 Y 放入同一个类中。这么简单，为什么要费心添加一个新类(即复杂性)。”

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

“如果在不太可能出现的新需求情况下，我的代码变得太困惑，我仍然可以针对新需求进行重构。所以你的‘如果以后需要……怎么办’的论点不算数。”

您反对这种做法的最有说服力的论据是什么？我怎样才能真正表明这是一种昂贵的做法，特别是对于那些在软件开发方面没有太多经验的人来说。

Answer 1

设计是权衡的管理和平衡。YAGNI 和 SOLID 并不冲突:前者说何时添加功能，后者说如何，但它们都指导设计过程。下面，我对您的每个具体报价的回复都使用了 YAGNI 和 SOLID 的原则。

1. It is three times as difficult to build reusable components as single use components.
2. A reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.

  — Robert Glass' Rules of Three, Facts and Fallacies of Software Engineering

重构为可重用组件的关键要素是首先在多个位置找到相同的用途，然后然后移动它。在这种情况下，YAGNI 通过在需要的地方内联该目的来应用，而不用担心可能的重复，而不是添加通用或可重用的功能(类和函数)。

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

<小时/>

Yes, I can put all my business logic directly into the GUI code it is much easier and quicker. This will always be the only GUI and it is highly unlikely that signifcant new requirements will ever come in.

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

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

It is OK that I put both feature X and feature Y into the same class. It is so simple why bother adding a new class (i.e. complexity).

您能指出一个需要避免的常见错误吗？有些事情很简单，例如对一个数字进行平方(x * x 与 squared(x))作为一个过于简单的示例，但如果你能指出一个具体的例子某人所犯的错误(尤其是在您的项目中或您团队中的错误)您可以展示公共(public)类或函数将如何在将来避免这种情况。

If, in the unlikely case of new requirements, my code gets too cluttered I still can refactor for the new requirement. So your "What if you later need to..." argument doesn't count.

这里的问题是“不太可能”的假设。你同意这不太可能吗？如果是这样，那么您同意这个人的观点。如果不是，那么你的设计理念与此人的设计理念不一致——解决差异就能解决问题，或者至少告诉你下一步该去哪里。 :)