0906 【萬泉河】一個問題：匯編語言支持面向對象編程嗎？

這是一個很有意思的問題。

起因是我是首個把面向對象方法完全應用到工控行業的PLC工程師。 全世界范圍內。

先別不服。

許多人看過我的視頻講座，講座中通篇講解了面向對象的方法在PLC程序設計中的應用。以及所著的新書《PLC標準化編程原理與方法》，其實通篇都在講面向對象這件事。

有一些人，簡單看了一眼視頻后就先來杠了， 面向對象嘛，不是什么新玩意。在IT領域早就流行幾十年了。 國內也早有自動化公司在做了。

看到沒， 凡是跳出來不屑一顧的， 舉例子的時候都會是舉一個道聽途說的別人家的公司。 就沒見過誰勇敢地站出來說我我我！我做到了。

而我們從各大社區所能獲得的各行各業的PLC項目例子程序中， 也從來沒有見到過真正如煙臺方法般實現了徹底的面向對象設計的案例。

人類科學技術發展到今天， 完全原創的創新已經很難有了。 現在能把不同行業之間的應用加以融合，賣出第一步，就算很不容易的創新了。

我工作20多年，前面很多年都只能碌碌無為做寫重復性的工作， 掙點辛苦錢，養家糊口。 也就近4-5年，才有機會做出一點真正屬于自己的創新型工作，一方面自認為運氣好， 一方面也有厚積薄發的因素在里面。

所以， 我是當仁不讓要把這個首創權霸占在自己名下了。有要跟我爭這個名譽的，歡迎來爭。 但要求是本人實名，拿自己作品來爭。 而不要什么所謂路見不平者毫無證據空口為別人爭。

當然還會有另外一些人不認可面向對象方法有多奇妙， 或者認為技術上在PLC領域操作系統編程語言環境根本不可能支持， 所以質疑我是否真的做到了，可以通過本文的邏輯分析見分曉。

首先一個基本的原理。

所有編程語言，最終都要經過其編譯器或者解析器，編譯成為匯編語言，然后再成為二進制的機器代碼，交給CPU運行。通常認為匯編語言，對應的就是機器語言。  

百度百科的解釋：
匯編語言， 即第二代計算機語言，用一些容易理解和記憶的縮寫單詞來代替一些特定的指令，例如：用"ADD"代表加法操作指令，"SUB"代表減法操作指令，以及"INC"代表增加1，"DEC"代表減去1，"MOV"代表變量傳遞等等，通過這種方法，人們很容易去閱讀已經完成的程序或者理解程序正在執行的功能，對現有程序的bug修復以及運營維護都變得更加簡單方便。

所以， 假設一門完全支持面向對象的高級編程語言寫成的程序，最終編譯后得到的仍然是匯編語言。

所以，假設你手里沒有原始的高級語言的編譯器和源代碼， 而只有其生成的匯編語言代碼，那么你把這個代碼全部抄寫一遍，也自然寫的是面向對象的程序。

即，結果是完全一樣的。 無非過程中，對你的能力要求不一樣， 你需要記憶更多的指令，以及更多的程序架構安排部署。

我們來看IEC 61131標準中規定的PLC程序語言IL指令表，在西門子中稱為STL， 其語句語法基本就是如上述匯編語言用到的ADD /SUB/ INC/DEC/MOV等等。那么我們大致可以認為STL就是約等于匯編語言。

那么，如果我們認為用匯編語言可以做出面向對象的PLC程序， 自然STL也可以，那么LAD可以轉化為STL，所有STL指令在LAD中也都有對應的指令，那么LAD梯形圖自然也完全可以做出完整的面向對象的程序。

我們通常描述面向對象的三大特性，封裝繼承和多態，討論PLC平臺是否已經提供并支持這些功能的時候， 其實應當認識到的是，平臺如果提供了這些功能，那么只不過是便于我們便捷使用。 而如果平臺沒有提供， 那么需要程序員自己的能力來實現。

所以，當我們評價某個PLC系統因為不支持所以不能做出面向對象的高內聚低耦合的系統設計的時候， 其實是我們推卸責任了。 把不能做到的責任推給了平臺。 而其實那是我們自己能力不足導致。

這一點，我在研究信捷PLC的標準化架構的時候，領悟到的。 并在文章《0725 【萬泉河】所有小型PLC也都能做標準化程序了》中有所表達。

本文則是重新從頭做了邏輯的梳理。

這也是我近期開始對所有小型PLC平臺感興趣的原因。 在我眼里，所有PLC本質都是一樣的，即便我從來沒有摸過，甚至名字都沒有聽說過， 要有人問我敢不敢接開發任務， 在其平臺上實現程序標準化架構，我現在可以毫不遲疑地回答：可以！

這是我近來認知上的最大的進步。 我前幾年一些文章中，以及書中所表達的觀點，抱怨一些PLC平臺性能差而導致不能做標準化，是錯誤的。

而以往更多的同行，發表的更多的文章中，對所有PLC平臺全部判死刑，認為缺少了這個或者那個功能而不可能實現的，那些作者們現在可以回頭思考一下這個邏輯了。

究竟你要表達什么意思？打廣告就免了，你傳個樣例程序上來大家看看。