现在所谓的模块化编程，面向对象编程，甚至于标准化编程等等理念在电气编程领域广泛宣扬，也出现了很多随便把程序分成几个模块就认为这就是面向对象编程了的同仁，没怎么搞清楚面向对象编程的概念就放手去写了。比如有些个朋友，喜欢把一个启保停的程序做成一个块，然后不同的电机调用一次这个块，蛮好吧，这是不是面向对象编程？

如下图，我是发现很多朋友喜欢这样，把每个小动作做成一个FC，然后集合一下，看，这就是面向对象编程了：

粗看还好，要是某个项目需要控制的东西非常多时，产生了大量的FC，而且上图还是举例这一个东西调用了三个FC，有些更甚，你要查个问题，得不断的进入下级FC，套娃一样，有甚者在次级FC里还套了下一次FC，有没有朋友遇到过，可以回帖讲讲，这种方式让其他人监控调试程序引起极大不便。

假如这个电机FB测试没有问题了，其他人可以调用，那么他必须同时调用下面包含的三个FC,否则如果他不清楚的情况少调用一个，就懵了。

这样写程序的人大有人在，他们认为把动作分解，各自独立成一个FC，然后这就是好的程序了，也很标准了。大错特错！

上面的例子，我们可以尝试用下面的方式体现，对比一下是否比它要好：

这个把这个电机的控制和速度还有状态封装，它是不是比上面的方式更好呢，起码其他人只需要调用这一个FB，不需要再复制其它FC，这个FB就是一个完整独立的功能块，而且其他人要进入FB监视，也不需要多次点击内部的其它套娃式FC，这样的编程方式比前面的那群人呢一点了。但这还不是好的。

虽然理解了封装的概念，但是我们还要继续升华，理解面向对象。

其实很多的电气编程的朋友经常犯一个误区，喜欢把驱动器或者执行元件当作对象，这理解我认为是错的。

其实真正的控制对象，它应当像一个人一样，手，脚只是一个人的一部分驱动，我们不能只把手或脚当作一个对象。我们要学会把一个人当对象，那么这个人除了手，脚（驱动，执行部分），还有肤色，健康状况，还有体温是否正常，还有吃饭睡觉等动作；而这些如果都去拆分成各个功能块，那么再次调用时很难将这些功能块再组合一起，特别是一千个一万个呢。

那么这个人我们编程时，不能拆分人这个对象，它有驱动执行部分，有肤色属性，有状态信息，还有其它动作。我们要面向它，用一个FB将它的所有功能包含，在引脚上赋值他的所有属性及事件即可，这样不管有多少人，我们调用这个FB即可。

那么在设备控制范畴，我们要跳出只关注执行元件范畴，要学会把某个设备或者设备的某个组件看成一个对象，这个组件它有电机，有气缸，有传感器，有指示信号等等，它拥有各类属性及各类事件，但都关联这一个组件。这个时候我们就可以将它看作一个对象。这种概念很难手把手的传达，要学会自己探索体会，等真正明白了这个之后所编写出来的程序那才是好程序。

只有学会将设备的某一部分组件当作对象，摒弃把动作肆意分解多个FC的想法，然后再开始写程序，我们在一个FB里可以完成它的状态，它包含的每个执行元件的各自动作输出，它的各类信息显示，它与其它组件联动的引脚等。这个时候，别人在调用你的这个FB，只需要对这个对象进行相关赋值，就可以完成这部分组件的各类动作和信息交换。

如现场很多的轴类控制，西门子的FB284它这个功能块相信很多人有接触过，它不是以一个伺服电机为对象，而是以一个轴为对象，这个轴它有回原点动作，有定位动作，有相对定位动作，你想执行什么只要进行相关赋值即可。同时它还可以进行速度，位置的设定和实际值显示，还包括了它的报警信息，报警代码。它是一个完整的轴对象。而它的这些各类属性和动作如果你都拆分成一个个小的独立的FC，这对其他人熟悉这个FB是非常困难的，我要控制一个轴我得熟悉七八个甚至于几十个FC，然后还得我把它们串起来才能用，这不是好程序。而FB284就只需要你调用一个FB，即可完成你需要的轴控制任务。这个朋友们体会了就能摸着门道。

上面仅用西门子的这个FB块举例让朋友们方便理解，其它品牌也有同样高效的面向对象编程的FB样例，的工程师们早就告诉我们：