开始做了两年web、期间也整了一段时间winform。后来做了两年工控上位机，也就是做工控这两年发现机器跟面向对象真是如此贴切，也是我从处理数据和流程的思维转变为面向对象思维的开始。这对我后来学习mvc5、owin、.net core以及其它各种框架的学习有非常大的帮助，我发现我能看懂源码，也能理解这些大牛为什么要这么去设计这些类，这些类是如何协同工作去实现一个复杂的可扩展的框架，因为这些框架、设计模式最最根本还是以面向对象的思维来处理具体场景的具体问题。这一瞬间有一百万种可能，转变思路也许就在一瞬间。

本篇以一个机器上的一个组件来聊下面向对象这回事。以及c#开发工控是多么的方便，其它方式我不咋懂，大概晓得有MFC/QT/PLC之类的

二、案例

动态称重鱼分选机

视频：案例视频

初代版本，虽然看着挺low，但是功能性和效率还是挺高的。分拣效率150条/分钟 精度±0.5g，带按数量或重量自动分包功能

功能：人工摆鱼上料，经过称重台称重，上位机实时获取重量计算得到鱼的重量，根据设置决定应该分拣到哪个料斗。上位机程序发送开关量指令控制分选。

物流包裹分拣系统

视频：案例视频 视频没拍全

功能：人工上包裹，经过扫码、称重、 由上位机将条码发往海关接口 ，海关返回包裹状态，由上位机根据状态控制分拣设备进行分拣

别人家的是视频，但是看样子不如我们公司的，我们分拣速度比它快，而且是双边分的

二、面向对象在自动化设备中的应用

省略扫码、称重、API请求等步骤，我们单单来看看这个分拣机部分，从图中我们可以看到有包裹、光电、分拣机。
包裹一个接一个从左往右传输，包裹之间有一定间隔；
包裹触发到红外线（光电）时，程序就知道包裹的状态了，此时程序根据包裹状态控制分拣机进行左分拣/右分拣 还是流向下一个分拣机

流程和功能非常简单，现在想想你会怎么来实现.......

问题来了，公司考虑成本，和机器不断改进，无论是结构上还是选用的设备上都可能不断变化
包裹状态是根据条码和重了发到一个api接口，有接口返回状态的；接口某些客户可能自己公司给你提供了，也有可能要你直接调用政府部门给的那个
光电传感器可能会用不同厂家的，有时候可以将光电接到主机上，有时候需要一个输入输出模块
分拣机控制往左分、右分、直行 可能直接用开关量，也可能用伺服电机，如果用开关量可能直接连电脑或中间加一个输入输出模块，用伺服电机可能厂家也不一样

现在再思考下，这些要求合理吗？你会怎么做？

面向对象的思想来说就是每个东西对应一个对象，变化地方用接口隔离
包裹类：

条码、重量、状态、等熟悉；
当状态变化时触发、当条码被赋值时触发、当重量被赋值是触发等事件；
相关方法...
当然还是涉及到对象的转换问题，因为机器检测到衣蛾包裹，软件界面上要有个方块或包裹图片显示出来，包裹在机器上传输时界面也要有体现，包裹的各种状态触发时也要有体现；主要使用c#的委托、事件和多线程来完成

光电：

将它定义为一个抽象类或接口，因为它内部包含一个通讯接口，比如某些时候我们用的输入模块来作为信号采集，那么我们同学组件要有一个实现类，某些时候我们是通过工控电脑直接连的光电，就直接调用win32API。但是对于我们光电类，它只要关心获取当前光电状态就行了，不关心到底通过什么样的方式去获取
光电有个线程一直在获取状态， 当发现状态变化时触发相应的事件就行了。这样我们的光电可能被多种其它机器结构来使用，而且能应对通讯方式变化的情况
属性包含：当前状态；方法包含：开启监听、事件包含：停止监听等方法；上升沿事件；下降沿事件；（就是光电从被挡住到没有被挡住的事件，里面包含这个状态变化的时长）

分拣机：

分拣机的主要工作是当光电触发时从包裹队列去除第一个包裹，检查状态，调用通讯模块发送指令。因此它内部包含一个光电对象，并注册光电的相关事件。关于通讯又得做成接口，以应对不同的控制方式

三、总结

哈哈，触不及防的总结。因为不想写了。总之就是这个场景，如果你来做会怎么做？思考下把机器的各个部件都定义为类，会怎么样，整个机器哪些地方会可能变化，类与类之间尽量用组合，界面与这些机器对象如何保持同步。

这样设计出来的上位机控制程序，相比PLC还是有极大的优势，至少应对变化，比如换另外一种机器，你的大部分组件可能都可以复用。

我们的思想被三层机构坑了，看了太多的分层业务逻辑要么在aspx.cs里 要么在controller里，要么在dal里 还有很多车主存储过程里。如果你考虑下所有对象都在内存里，不考虑持久化，也许更能理解。

我TM写了些啥...