代码越少越好？ 对象越少越好？ 是真的吗 像往常一样，这取决于。

在某些情况下，通过添加更多内容，我们会添加不必要的复杂性。 当我们仅出于“将来可能需要这种额外的灵活性”而创建接口或其他抽象时，就会发生这种情况。 当我们忘记YAGNI原理而我们编写的代码可能会使我们的生活变得更轻松，如果出现了新的需求，这些需求可能永远不会发生。

另一方面，我们遇到的情况与我在最近的文章中描述的情况类似。 我向您展示了一个示例，其中我们添加了一些内部执行几乎相同的方法。 但是，通过添加它们，我们获得了很多好处–代码变得更易于理解。 此附加代码为我们提供了有关对象正在执行的操作的信息，而不是如何实现的。

今天，我想与大家分享另一个例子，该例子表明更少的代码有时可能意味着更少的可读性代码。

很久以前…

今天，我想和您谈谈历史：

public class History {public void store(
Author author, RefactoringType type, Scope scope, 
RefactoringJustification justification, Date today) {// some code
}

是否容易弄清楚要存储哪种存储方法？ 有可能理解吗？ 好吧，即使是这样，我相信我们所有人都可以同意这绝对是困难的。

您如何从方法的声明中提取必要的信息？ 我可以假设，首先您要阅读类和方法的名称以查找上下文。 好，我们有。 我们想存储一些历史信息。 现在最困难的部分开始了–您必须找出我们要存储的内容。 您不能只是简单地阅读此信息，因为该信息不存在于代码中。 在这种情况下，您可能会尝试通过查看参数列表来查找此信息。 您将阅读它们，并希望能够弄清楚代码的作者想要存储什么。

或者，您可以查看引入此代码的提交消息。

或者，您可以查看方法的定义并在实现中寻找答案。

虽然不是最好的主意。

您是否认为轻松获得此信息会很棒？ 要拥有无需额外努力就能理解的代码？ 我相信这正是我们应该如何编写的方式。

救援参数对象

为什么在阅读完方法的声明后还不了解所有内容？

通过某种方式，我们可以在这里找到有关历史的信息–班级名称为我们提供了这些信息。

我们知道这与存储内容有关–该方法的名称具有很强的描述性。

问题在于我们不知道要在历史记录中存储什么。 为什么？ 因为输入参数没有给我们这些信息。

这些参数指示我们要存储的块，但是，不解释当将所有这些块放在一起时我们应该知道什么。 我们正在获取有关实现（使用的部分）的信息，我们不知道此代码应该做什么。

我们能做什么？ 我们应该隐藏实现并解释我们希望通过此代码实现的目标。 那就是那一刻
参数对象可以解决。 您可以将其视为一些不同对象的盒子，作为可以减少依赖性的解决方案。 但是，对我而言，使用此模式的最大好处是您将不得不命名该对象，并因此而不得不提供有价值的信息。

让我给你演示：

public class History {public void store(CodeDelta delta) {// some code
}

现在很明显我们要存储什么。 我们与阅读我们代码的人共享有用的信息。 我们还隐藏了一个实现。 他们可以专注于重要的事情，而不会被仅在编写或修改方法时才感兴趣的所有其他细节所打扰。

那么，您说的越少越好？

翻译自: https://www.javacodegeeks.com/2016/07/many-parameters-lost-information.html