在做实验搞一个简单电机控制块时，突然成心地想把它写得复杂一些，又成心地赶时髦想容易“复用“容易”扩展“容易修改等容易XX系列，于是也想起了XXX和XXX认为很深不可测的东西，我觉得也就那么回事儿，不知是我看不懂还是咋着，想起来了，就干脆写一写吧，写出来大家都看看，评评。

不啰嗦，大体结构就是弄了个父FB，暂且称之为FB_0，在FB_0中又以多重实例的模式调用了多个子FB，暂且称之为FB_1，FB_2，FB_3，至于父与子的，仅表示层级结构，没有任何生物学上的关系。

FB_0内的代码呢，按照功能（命名控制、故障检测、状态机等）划分”打包“成FB_1，FB_2，FB_3，而它们又使用FB_0管脚中不同管脚的组合作为各自的参数；为了让FB_1,FB_2,FB_3可以在不同的电机类型FB中复用，应该如何处理？

我们通常将这种一个功能块（FB）调用其他多个功能块，并且这些被调用的功能块共享调用者FB的接口参数的情况，称为“共享耦合”或“公共耦合”。就像戴胜鸟头顶的毛，你用我用它也用，谁知道谁用的是哪**？它不就臭了？你严肃点儿！

在软件工程中，耦合是指模块之间相互依赖的程度。公共耦合指的是多个模块共享同一个全局数据区（或同一数据项）。在这里，FB_1, FB_2, FB_3都直接使用了FB_0的接口参数，这意味着它们都依赖于FB_0的接口，形成了较高的耦合。

具体来说，这种耦合可能导致以下问题：

可维护性差：如果FB_0的接口发生变化，那么FB_1, FB_2, FB_3都可能需要修改。

可读性差：因为多个FB都直接使用FB_0的接口，所以很难理解每个FB具体使用了哪些数据，以及如何使用的。

难以复用：这些FB因为依赖于FB_0的接口，所以很难在其他上下文中复用。

解决这种耦合的方法通常是降低模块之间的依赖，具体可以采取以下措施：

封装数据：将共享的数据封装成一个独立的FB或数据结构，然后通过参数传递的方式传递给FB_1, FB_2, FB_3，而不是让它们直接访问FB_0的接口。

接口最小化：确保每个FB只接收它所需的最小数据子集，而不是整个FB_0的接口。即，每个被调用的FB应该有自己的接口，只包含它需要的数据。

使用局部变量：在FB_0中，将需要传递给其他FB的数据先赋值给局部变量，然后通过局部变量传递，而不是直接传递整个接口。

依赖注入：通过参数传递的方式将所需的数据传递给每个FB，这样每个FB就不直接依赖于FB_0的接口，而是依赖于传递给它们的参数。

举例说明：

假设FB_0有一个输入接口Input和一个输出接口Output，而FB_1, FB_2, FB_3都直接使用了Input和Output中的一些元素。

改进方法：

我们可以为每个被调用的FB定义专门的输入输出参数，然后在FB_0中调用它们时，只传递它们所需的数据。

例如，FB_1只需要Input.A和Output.B，那么FB_1的接口就定义为：
Input: A (类型)
Output: B (类型)

在FB_0中，调用FB_1时，将Input.A传递给FB_1的输入，将FB_1的输出赋值给Output.B。

这样，FB_1就不再依赖于FB_0的整个接口，而只依赖于自己需要的部分。如果FB_0的接口发生变化，只要FB_1所需的部分不变，FB_1就不需要修改。

另外，如果FB_1, FB_2, FB_3之间有共享的数据，可以考虑将这些共享数据封装成一个结构体，然后通过参数传递。但要注意，如果封装的结构体过大，也可能导致不必要的依赖。

总之，解决这种耦合的关键是让每个模块只依赖于它所需的最小数据集合，而不是一个庞大的共享接口。

说人话就是，把大包里的东西，分别按需要拆成小包，然后再分给每个使用者。

就是，薅几**安在它头上，

再薅几**安在它头上，

可以把这种操作戏称为“植毛”！

    说到底，还是现在的REF_TO不给力啊，哪天REF_TO_FB解开了封印，也就不用“植毛”了。

    大家看看，能够笑笑就可以了。