一、前言

開始做了兩年web、期間也整了一段時間winform。後來做了兩年工控上位機，也就是做工控這兩年發現機器跟面向對象真是如此貼切，也是我從處理數據和流程的思維轉變為面向對象思維的開始。這對我後來學習mvc5、owin、.net core以及其它各種框架的學習有非常大的幫助，我發現我能看懂源碼，也能理解這些大牛為什麼要這麼去設計這些類，這些類是如何協同工作去實現一個複雜的可擴展的框架，因為這些框架、設計模式最最根本還是以面向對象的思維來處理具體場景的具體問題。這一瞬間有一百萬種可能，轉變思路也許就在一瞬間。

本篇以一個機器上的一個組件來聊下麵向對象這回事。以及c#開發工控是多麼的方便，其它方式我不咋懂，大概曉得有MFC/QT/PLC之類的

二、案例

動態稱重魚分選機

視頻：案例視頻

初代版本，雖然看著挺low，但是功能性和效率還是挺高的。分揀效率150條/分鐘 精度±0.5g，帶按數量或重量自動分包功能

功能：人工擺魚上料，經過稱重台稱重，上位機實時獲取重量計算得到魚的重量，根據設置決定應該分揀到哪個料斗。上位機程式發送開關量指令控制分選。

物流包裹分揀系統

視頻：案例視頻 視頻沒拍全

功能：人工上包裹，經過掃碼、稱重、 由上位機將條碼發往海關介面 ，海關返回包裹狀態，由上位機根據狀態控制分揀設備進行分揀

別人家的是視頻，但是看樣子不如我們公司的，我們分揀速度比它快，而且是雙邊分的

二、面向對象在自動化設備中的應用

省略掃碼、稱重、API請求等步驟，我們單單來看看這個分揀機部分，從圖中我們可以看到有包裹、光電、分揀機。
包裹一個接一個從左往右傳輸，包裹之間有一定間隔；
包裹觸發到紅外線（光電）時，程式就知道包裹的狀態了，此時程式根據包裹狀態控制分揀機進行左分揀/右分揀 還是流向下一個分揀機

流程和功能非常簡單，現在想想你會怎麼來實現.......

問題來了，公司考慮成本，和機器不斷改進，無論是結構上還是選用的設備上都可能不斷變化
包裹狀態是根據條碼和重了發到一個api介面，有介面返回狀態的；介面某些客戶可能自己公司給你提供了，也有可能要你直接調用政府部門給的那個
光電感測器可能會用不同廠家的，有時候可以將光電接到主機上，有時候需要一個輸入輸出模塊
分揀機控制往左分、右分、直行 可能直接用開關量，也可能用伺服電機，如果用開關量可能直接連電腦或中間加一個輸入輸出模塊，用伺服電機可能廠家也不一樣

現在再思考下，這些要求合理嗎？你會怎麼做？

面向對象的思想來說就是每個東西對應一個對象，變化地方用介面隔離
包裹類：

條碼、重量、狀態、等熟悉；
當狀態變化時觸發、當條碼被賦值時觸發、當重量被賦值是觸發等事件；
相關方法...
當然還是涉及到對象的轉換問題，因為機器檢測到衣蛾包裹，軟體界面上要有個方塊或包裹圖片顯示出來，包裹在機器上傳輸時界面也要有體現，包裹的各種狀態觸發時也要有體現；主要使用c#的委托、事件和多線程來完成

光電：

將它定義為一個抽象類或介面，因為它內部包含一個通訊介面，比如某些時候我們用的輸入模塊來作為信號採集，那麼我們同學組件要有一個實現類，某些時候我們是通過工控電腦直接連的光電，就直接調用win32API。但是對於我們光電類，它只要關心獲取當前光電狀態就行了，不關心到底通過什麼樣的方式去獲取
光電有個線程一直在獲取狀態， 當發現狀態變化時觸發相應的事件就行了。這樣我們的光電可能被多種其它機器結構來使用，而且能應對通訊方式變化的情況
屬性包含：當前狀態；方法包含：開啟監聽、事件包含：停止監聽等方法；上升沿事件；下降沿事件；（就是光電從被擋住到沒有被擋住的事件，裡面包含這個狀態變化的時長）

分揀機：

分揀機的主要工作是當光電觸發時從包裹隊列去除第一個包裹，檢查狀態，調用通訊模塊發送指令。因此它內部包含一個光電對象，並註冊光電的相關事件。關於通訊又得做成介面，以應對不同的控制方式

三、總結

哈哈，觸不及防的總結。因為不想寫了。總之就是這個場景，如果你來做會怎麼做？思考下把機器的各個部件都定義為類，會怎麼樣，整個機器哪些地方會可能變化，類與類之間儘量用組合，界面與這些機器對象如何保持同步。

這樣設計出來的上位機控製程序，相比PLC還是有極大的優勢，至少應對變化，比如換另外一種機器，你的大部分組件可能都可以復用。

我們的思想被三層機構坑了，看了太多的分層業務邏輯要麼在aspx.cs里 要麼在controller里，要麼在dal里 還有很多車主存儲過程里。如果你考慮下所有對象都在記憶體里，不考慮持久化，也許更能理解。

我TM寫了些啥...