【万泉河】论PLC面向对象编程方法中的封装和继承

我在推广标准化编程方法，向同行们解释所用到的面向对象的概念的时候，经常有人提出质疑，面向对象编程的三个特性：封装、继承和多态，PLC编程能都支持吗？

我猜，质疑者可能是一知半解地了解过一些面向对象的编程理念，而实际上并没有真正理解。当然啦， 我能做出这样的判断是因为，包括我自己，也并没有完全毕业成为面向对象编程的高手。否则我早就不在工控行业混了。早就杀向IT行业了。那里挣大钱的机会多多了。

所以简要谈一下我的理解，面向对象三大特性的关系，是与的关系还是或的关系？是三者必须兼顾，缺一不可呢，还是有其一即可称之为面向对象呢？

面向对象是一种编程实现方法，是指相对于面对过程来说的。

打一个比方，要从A城市的一个乡镇，到B城市的另一个乡镇，交通方式首先有两大类，一类为乘坐公共交通，另一类为自由出行方式。

那么，首先要确定类型。如果选择公共交通方式，就会在此基础上，有多重选择，火车，飞机，公共汽车等等，以及多重方法的组合。

而如果选择自由出行，则会有自驾，包车，自行车， 甚至徒步等等。当然也可以多重组合。

我认为，编程中选择面向对象方法的时候， 就相当于定下了公共交通出行的基调。

而其中的封装，继承，多态等，则相当于你选择的飞机，火车，以及公共汽车。其中最为基础的是封装，就相当于公共汽车。如果你不在乎时间，距离，效率，只靠公共汽车换乘，而不选择飞机和火车，也一定能实现。

所以我认知里，面向对象三大特性的关系是或的关系。根据系统的性能，以及自己的偏好与特长，选择其一即可。就好比， 两个城市之间根本不通飞机，甚至两个城市是公用同一个机场的，你偏要强调没做飞机就不算圆满的公共出行，那就非常搞笑了。

而在一个控制系统里，分明用不到复杂的功能，你还非要弄些花架子，就为了名义上满足定义，也同样搞笑。

曾经看过一个程序员讲的笑话。大意是他有过一个尼泊尔籍的同事，离职了，工作内容交接给了他。他拿到手里一看，大吃一惊，这家伙竟然完全不会继承和多态。就在那儿只要有需要，就封装新功能，一个项目，做了几百个类，而他拿到手里优化一通之后，只剩下了十几个类，系统又快，维护工作量还小多了。

我看过之后，没觉得好笑，反而觉得，对于PLC编程来说，好像这才是正确的实现方式。那位被编到笑话里的尼泊尔人，应该转行来做PLC编程。

计算机领域里，大量无穷尽的继承的基础，是在同一个系统里的代码功能重复使用。而PLC都是一个个的小系统，资源有限。要使用一个子类，还要把其父类，父类的父类，爷爷的爷爷，也都一起带着，最终，系统中只用到最外层的子类的一个实例，先不说浪费，CPU的资源恐怕都放不下。

所以，我分享的标准化编程示范项目，主要的三板斧就是封装。以封装的类以及其实例化，来实现了程序的标准架构。而其中的继承和多态方法，则基本没有使用。但我以前文章中也提到过，库函数的实现方法中可以有继承。

这次以示例的形式演示一下通过对一个电机块的再封装，即继承其原有框架，并增加新的功能，以及隐藏用不到的功能（管脚）。

请PLC标准化学员营的学员跳转阅读，这是给你们的福利教程，课后有作业：

【万泉河】PLC标准化编程方法演示：再封装（继承）一个电机块

这个说法非常典型。

在排除了个人之间的互相攻击对骂之外，客观来说， 这两种不同的实现方法， 确实有这样的相互的鄙视链。

即，互相认为对方的程序垃圾。

我方的辩词是，在CPU容量远远大于22K的情况下， 假设，你做22K的程序需要半天， 而做1.2K的程序需要一个周。

对于老板来说，见到的是两个效率高低不同的工程师。

对客户来说， 见到的是两套稳定性，调试周期长短不同的控制程序。

哪一个更垃圾？

谁更关心程序的容量呢？我猜如果CPU是个有灵性的头脑， 让它常年20%的负载跑程序，和10%的负载跑程序， 他可能会骂前者是垃圾。
除此之外，我想不出谁会骂大一点的程序是垃圾了。

否则的话，以楼上这种观点来评判微软的各种软件的话， 那无一例外， 全部都是大垃圾。

我们更崇拜的还是直接使用汇编语言编程的高手。

那些使用VISUAL STUDIO 编程的，都太菜了。

标准是分层的。

每个标准关注的层面不一样。