对于装饰器和高阶组件

计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决.

当然，我并不想说这么大的话题，也没那个能力。

只是最近做了一些关于高阶组件和装饰器的一些问题有点想法想表达一下而已。

其实装饰器和高阶组件都是利用一个中间层来解决实际问题的，只不过方式不太一样而已。

装饰器可以装饰类，可以装饰方法，可以装饰属性，不过高阶组件就只能是组件了，因为如果传入的是函数应该叫高阶函数。

我一直是认为任何事情都是有代价的，代码也不例外——方便的代价可能是慢，也可能是难以维护，也可能是无法做复杂的事情（PS：我并没有在说JS，-_-||）。然而高阶组件和装饰器看起来好像并不是这样，他们并不慢，也没有特别的复杂度，也让业务之间解耦。比如我现在的项目，对组件装饰了好多层，每层有每层的实现，除了权限部分别的顺序和实现都是很自由也互不影响的。

不过实际上，高阶组件和装饰器复杂度在于对其的理解上。还记得我刚听说高阶组件的时候的一脸懵逼，就和刚学js的时候没有太大区别。而且理解后也要权衡装饰器是不是应该使用，因为我上边说了，任何事情其实都是有代价的，用了装饰器、高阶组件就决定了这个组件可能是比较复杂——至少是承担了不少的业务内容。否则我直接在组件内部处理就好了，根本没必要去搞个装饰器或者高阶组件之类的内容。这个时候要考虑的问题有以下几个：

装饰器的顺序问题，他们不同的顺序是否会有影响，否则就要注明，否则别人不小心改了一点会引起系统的错误；
关于装饰器的职责问题，每个装饰器只做一件事，不要让一个装饰器承担太多的任务，导致逻辑耦合；
装饰器要返回新的组件，而不要修改原有组件，当然这个是基本原则；

所以任何内容有存在的必要，自然也会有限制，软件在发展，那么他就是在不断的寻求边界。你说我有一个包含所有功能的软件好不好，当然好，但是会不会有人用，我想不会的，每个产品就像一个个函数，短小精巧才是最好的，包含一切的结果就是一切都解决不了。

回到装饰器和高阶组件，他们是不是好东西——是，用的好了确实能解决很多问题。但是，再好的东西也要看使用方法和水平。所以最终结论其实还是基础和方案——方案是指在陷入困境的时候能有想法去解决问题，基础就是有了方案有能去实现的能力。