Uncle Bob 说：

函数的参数越少越好，最好的函数是那些没有参数的函数。

我自己也常有类似的感觉，只是一直没去想为什么。直到最近，我偶然翻到了 Uncle Bob 的书，一句话让我豁然开朗：

函数和参数处在不同的抽象层级上。

我觉得这很好地阐述了函数的精髓，即一种抽象。想像一下，购买一个产品，不是开箱即用，而是要阅读大量说明书，理解其原理，对它进行繁琐的配置，这显然是不人性的。好的产品和好的函数一样，它们是完整的抽象，并不迫使用户去理解内部细节。

上周，和朋友聊起我的一堆新协议。其中有两个协议，功能不同，面向的用户也不同，但代码非常相似，有超过 90% 的代码是重复的。

我们讨论是否应该将这两个协议合并。起初，他第一反应是当然要合并。但深入讨论后我们都意识到，合并实际上会引入更多问题。

从用户的角度来看，是应该要分开的，否则会产生认知上的负担。跟使用者的认知负担相比，代码层面的重复是完全可以接受的。

这和函数参数是同一个道理。

同样，协议与应用的关系也是如此。

有些协议因为抽象层次低，所以非常灵活。对于了解它的人来说，它可太牛逼了，能干 A，能干 B，能干 C…… 啥都能干。但对于普通旁观者而言，因为它抽象层次低，很灵活，所以反而很难理解它究竟是什么。

这个时候，上层的应用就变得非常重要。因为应用提供了更高层次的抽象，是更好理解的——它就是用来干某件事的，其他的干不了。

如果到了应用这一层，还是很灵活，很多功能，不无脑，那就有问题了。

写这篇文章的过程中，我逐渐意识到，这个抽象问题实际上是更为广泛的存在，比如在信息的传播中。

对于信息或知识的传递，基础而本质的内容往往较难传达。它们似乎无处不在，却又难以捉摸。因此，人们通过一层又一层的抽象来解释这些概念，最终产生了我们熟知的畅销书、短视频、标语和小白科普文章。

“懂的人” 觉得，这些东西太肤浅太不严谨了，让人们越来越傻；但对于大众来说，这就跟好用的产品一样，是更友好更易于理解的。细节的损失，甚至部分曲解，并不是一种缺陷，而是必要的，因为这就是抽象的意义。