代码越少越好? 对象越少越好? 是真的吗 像往常一样,这取决于。
在某些情况下,通过添加更多内容,我们会添加不必要的复杂性。 当我们仅出于“将来可能需要这种额外的灵活性”而创建接口或其他抽象时,就会发生这种情况。 当我们忘记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