一、前言
開始做了兩年web、期間也整了一段時間winform，后來做了兩年工控上位機，也就是做工控這兩年發現機器跟面向物件真是如此貼切，也是我從處理資料和流程的思維轉變為面向物件思維的開始，這對我后來學習mvc5、owin、.net core以及其它各種框架的學習有非常大的幫助，我發現我能看懂原始碼，也能理解這些大牛為什么要這么去設計這些類，這些類是如何協同作業去實作一個復雜的可擴展的框架，因為這些框架、設計模式最最根本還是以面向物件的思維來處理具體場景的具體問題，這一瞬間有一百萬種可能，轉變思路也許就在一瞬間，
本篇以一個機器上的一個組件來聊下面向物件這回事，以及c#開發工控是多么的方便，其它方式我不咋懂，大概曉得有MFC/QT/PLC之類的
二、案例
動態稱重魚分選機
視頻：案例視頻
初代版本，雖然看著挺low，但是功能性和效率還是挺高的，分揀效率150條/分鐘 精度±0.5g，帶按數量或重量自動分包功能
功能：人工擺魚上料，經過稱重臺稱重，上位機實時獲取重量計算得到魚的重量，根據設定決定應該分揀到哪個料斗，上位機程式發送開關量指令控制分選，
物流包裹分揀系統
視頻：案例視頻 視頻沒拍全
功能：人工上包裹，經過掃碼、稱重、 由上位機將條碼發往海關介面 ，海關回傳包裹狀態，由上位機根據狀態控制分揀設備進行分揀
別人家的是視頻，但是看樣子不如我們公司的，我們分揀速度比它快，而且是雙邊分的
二、面向物件在自動化設備中的應用
省略掃碼、稱重、API請求等步驟，我們單單來看看這個分揀機部分，從圖中我們可以看到有包裹、光電、分揀機，
包裹一個接一個從左往右傳輸，包裹之間有一定間隔；
包裹觸發到紅外線（光電）時，程式就知道包裹的狀態了，此時程式根據包裹狀態控制分揀機進行左分揀/右分揀 還是流向下一個分揀機
流程和功能非常簡單，現在想想你會怎么來實作.......
問題來了，公司考慮成本，和機器不斷改進，無論是結構上還是選用的設備上都可能不斷變化
包裹狀態是根據條碼和重了發到一個api介面，有介面回傳狀態的；介面某些客戶可能自己公司給你提供了，也有可能要你直接呼叫政府部門給的那個
光電傳感器可能會用不同廠家的，有時候可以將光電接到主機上，有時候需要一個輸入輸出模塊
分揀機控制往左分、右分、直行 可能直接用開關量，也可能用伺服電機，如果用開關量可能直接連電腦或中間加一個輸入輸出模塊，用伺服電機可能廠家也不一樣
現在再思考下，這些要求合理嗎？你會怎么做？
面向物件的思想來說就是每個東西對應一個物件，變化地方用介面隔離
包裹類：
條碼、重量、狀態、等熟悉；
當狀態變化時觸發、當條碼被賦值時觸發、當重量被賦值是觸發等事件；
相關方法...
當然還是涉及到物件的轉換問題，因為機器檢測到衣蛾包裹，軟體界面上要有個方塊或包裹圖片顯示出來，包裹在機器上傳輸時界面也要有體現，包裹的各種狀態觸發時也要有體現；主要使用c#的委托、事件和多執行緒來完成
光電：
將它定義為一個抽象類或介面，因為它內部包含一個通訊介面，比如某些時候我們用的輸入模塊來作為信號采集，那么我們同學組件要有一個實作類，某些時候我們是通過工控電腦直接連的光電，就直接呼叫win32API，但是對于我們光電類，它只要關心獲取當前光電狀態就行了，不關心到底通過什么樣的方式去獲取
光電有個執行緒一直在獲取狀態， 當發現狀態變化時觸發相應的事件就行了，這樣我們的光電可能被多種其它機器結構來使用，而且能應對通訊方式變化的情況
屬性包含：當前狀態；方法包含：開啟監聽、事件包含：停止監聽等方法；上升沿事件；下降沿事件；（就是光電從被擋住到沒有被擋住的事件，里面包含這個狀態變化的時長）
分揀機：
分揀機的主要作業是當光電觸發時從包裹佇列去除第一個包裹，檢查狀態，呼叫通訊模塊發送指令，因此它內部包含一個光電物件，并注冊光電的相關事件，關于通訊又得做成介面，以應對不同的控制方式
三、總結
哈哈，觸不及防的總結，因為不想寫了，總之就是這個場景，如果你來做會怎么做？思考下把機器的各個部件都定義為類，會怎么樣，整個機器哪些地方會可能變化，類與類之間盡量用組合，界面與這些機器物件如何保持同步，
這樣設計出來的上位機控制程式，相比PLC還是有極大的優勢，至少應對變化，比如換另外一種機器，你的大部分組件可能都可以復用，
我們的思想被三層機構坑了，看了太多的分層業務邏輯要么在aspx.cs里 要么在controller里，要么在dal里 還有很多車主存盤程序里，如果你考慮下所有物件都在記憶體里，不考慮持久化，也許更能理解，
我TM寫了些啥...
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/80523.html
標籤：C#