fegin 参数丢失_许多参数和丢失的信息

fegin 参数丢失

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

在某些情况下，通过添加更多内容，我们会添加不必要的复杂性。当我们仅出于“将来可能需要这种额外的灵活性”而创建接口或其他抽象时，就会发生这种情况。当我们忘记了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

fegin 参数丢失