大量参数与信息丢失之间不可不说的故事

代码越少就越好？对象越少就越好？这些都是真的吗？由绝大多数情况来看，这还真的都不一定。

在我们向代码中添加不必要东西的时候，很有可能就把这个原本简单的事情搞复杂了。在我们制作接口或是一些其他抽象东西的时候，不知道谁这样说了一句：“要是我们将来用更多的东西，现在添加进去会更方便”，上述的问题可能就这样产生了；有时我们忘记了YAGNI（ You Ain’t Gonna Need It即你不需要它）原则，故而在写代码的时候我们会添加一些自以为会让生活更加方便的东西，刚才的问题它也可能会因此而出现……此类情况真是太多了。

但是从另一个方面来说，之前在我的近期文章当中描述过一些类似的情况，给大家展示了把几个功能几乎一样的方法添加进同一段代码当中的例子。正因如此，我们受益颇多：代码变得更易于理解了。这些额外添加的代码也让我们更多地了解了这个对象是“做”什么的，而不是它是“如何”做到的。

在这篇文章当中我会给大家展示另外一个例子：更少的代码有时可能意味着更不易阅读。

曾几何时……

今天我来给你们说说这段黑历史：

你可以很容易看出来这个存储方法存储的是什么吗？这个很好理解吗？好吧，就算是可以认出来，但是我们不得不承认这还是很困难的。

如何在方法声明当中提炼出关键信息呢？我敢肯定的是第一步你会去阅读类与方法的名称来弄清楚这个环境。“很好，明白了，我们接下来存储一些历史信息。”现在困难的地方就出现了：你需要把我们想存储的信息给找出来。不能只是仅仅阅读这些信息，因为这些信息没有在代码中呈现出来。在这种情况下，你就需要在一串参数当中找出这些有用信息。你要满怀信心的去阅读，因为只有这样你才可以搞清楚代码的作者到底是想存储什么东西。

或者是去看commit出来介绍代码的信息。

亦或是看一下方法的定义，然后在implementation当中找到问题的答案。

尽管不是最好的方法，但是还能用。

难道你还认为这是一种获取信息的便捷方法吗？我们可以不做任何额外的工作就理解某段代码吗？毫无疑问是可以的，这正是我写下这篇文章的目的。

用参数对象施加援手

为什么我们总是在读了方法声明之后才对它们有所了解？

不知怎么地，我们都能找到一些历史信息——这是因为类的名称给了我们这些信息。

我们可以了解到这是关于存储一些东西的——因为方法的名称总是那么易于描述。

现在的问题是，我们不知道我们想在历史中存储些什么。为什么呢？因为输入参数并没有给我们这些信息。

那些参数表明了我们想存储的pieces，但没有解释当那些pieces放在一起的时候我们需要知道什么。我们获取了implementation（已被使用的部分）的信息，但我们也不知道这个代码到底是干嘛的。

那么我们需要做些什么呢？我们需要隐藏implementation，并且解释我们想让这个代码实现什么样的功能。除此之外，这也是参数对象开始发挥作用的时候了。你可以将它视为一个为不同对象服务的盒子，或是一种降低相关性的解决办法。然而对我来说，用这种方法最大的好处在于需要你命名该对象，并且你这样做了之后会被强制提供有价值的信息。

我来展示一下：

现在我们想存储的信息已经很明显了。我们给阅读我们代码的人共享有用的信息，同时也隐藏了implementation。这样一来读者就可以把注意力放在关键的地方，不会被额外添加的细节所打扰——而这些细节只是你自己写着或者修改方法时有趣罢了。