要編制一亇裝備執行的軟體是一亇系統工程。僅僅學習一些程式設計的語言，有如學習了語文的詞彙，不能匯及成文章。

數控機床的軟體，是國外企業賣給我們的一畢收入。在88年去德國，看到每一個機床廠的產品都有有已廠家的軟體。

在學習操作軟體程式設計時，也曾尋問過程式的組織結構是怎樣的？囬答是有四部分：組織模組，功能模組，資料模組和報警模組。

在退休以後，看到用系統論科學統一觀指導下的機械工程設計方法的論述以後，終於看清楚軟體的設計是一個系統工程。理工科的學生依靠計算機語言課的知識，沒有能力編制一個完整的軟體。

所謂組織模組，是指在電腦螢幕上顯示用方向樹結構排序的各種基本動作。

對應這些基本動作，有各種子程式的功能動作。這些功能動作，可以是看做作業系統時的工藝程式。對於其它軟體由於工作物件不同，也可以歨使用時的操作順序。

功能模組集合了組織模組中每一個動作所對應的技術方法。可以是數學表示式及其運算，物理方程式及其運算，閱讀某個指令、顯示某些內容…。

資料模組足集合了所有功能模組的計算的動態資料和指令，為主程式提供判斷和決策的依據。

報警模組是限制軟體操作過程中，出現不適應的狀態。

所以，編制一個系統軟體，不是僅僅掌握了程式語言就可以進行的。它需要工程裝備的設計師提出完整的裝備的框圖和各個子系統的動作、原理.資料和指令的關係圖，作為系統軟體的設計依據。

一個完整的軟體所以能控制柔性化操作，還需要有數學運算方法和布林代數判斷功能。

編制國家自有的軟體，是一亇迫切的技術需求。希望年青的IT工作者儘早做出中中國人的軟體。

總體而言，看你解決什麼問題，適合的就是好的。

優缺點，可以參考計算機程式語言的發展歷史來總結。可以按照幾個步驟來思考：

一個新的程式設計正規化出現的背景是什麼、要解決了什麼問題、解決的怎麼樣、帶來了什麼新的問題、新的問題怎麼解決。

面向物件程式設計的產生：

背景：當年面向過程的程式語言盛行，隨著資訊化加速，需要的軟體越來越“業務化”、功能越來越膨脹。軟體是給人用的，那麼為什麼不設計，更符合人類思維習慣的思想、語言工具來抽象、設計和表達新的軟體？

解決的問題：對人更直觀，提供對設計複雜系統時更好的抽象能力。

評價：很不錯、也引入了複雜性（主要是資料和行為融合帶來的狀態複雜性）

新的問題：執行時物件之間的依賴、物件的狀態管理

怎麼解決：融合多種程式設計思想正規化。函數語言程式設計：計算邏輯和資料分離。設計機制來保證共享資料的訪問和同步。

在真實的程式語言實現和軟體開發中，多種程式設計思想或者說正規化都是並存的。

比如：c語言你也可以進行用面向物件思想進行抽象開發，只不過因為語言特性有限，更費力一些（相比於抽象層次更高的程式語言，比如java）。java開發中，一些方法和業務邏輯的編寫也是面向過程的。

但是真實的業務邏輯問題永遠是存在的，不會因為你採用了什麼程式設計技術/思想而改變。只能綜合應用多種正規化來儘可能合理的優雅解決問題。

機器效能過剩的今天，面向物件程式設計沒什麼弊端吧？這個年代了，難道你要為了感受不出來的效能，自己大費周章的去畫控制元件，自己去寫外掛嗎？一個系統別人半個月做完，你花半年，還沒人家美觀，也沒人家穩定

真要說弊端，估計就是對研發而言，更底層的原理不會懂了

說起弊端，有一個比較大的，就是沒有具體說明和樣例，你不會用。打個比方，把字串按照分號分割成陣列，及反之。你可能需要查string類和arrays類，來確定到底是哪個類的方法支援。複雜一點，給你一個PDF加水印的需求，不看說明，你都不知道要用哪個類，方法的呼叫順序。而函式式開發，雖然結構不咋地，但是，功能和所需引數都很明確，順藤摸瓜，就能找到所需的函數了。

物件資料和資料庫保持同態是一個難以解決的問題。對於銀行等多使用者transaction系統、這個問題就更加突出了。

面向物件程式設計的弊端就是沒有數學理論支撐，而函式程式設計都可以找到數學理論支撐的。事實上面向物件程式設計純粹上是程式設計經驗的總結，由於缺乏數學理論支援，其定義相當模糊，這在程式設計時容易帶來混亂。在面向物件產生初期，由於濫用繼承而導致系統臃腫、難以維護的專案比比皆是。這也預示著即使使用面向物件程式設計，也會產生一堆垃圾。所以後來產生一系列設計模式作為補充，而設計模式的出現也預示著面向物件程式設計的侷限性。

個人觀點，我覺得OO的弊端是可能對於 效率有些許影響，因為相當於萬物套了一層類結構，他有維護開銷，有很多專案是為了面向物件而面向物件，可能有裝X的嫌疑！

繼承層次達到五層以上時，如果還有多繼承，對程式碼的理解非常不利，帶來了很大困難。特別是又加了過載和虛擬方法的話，就更分散了。這一點在看spring原始碼的時候非常明顯，即使spring的封裝做得非常好，閱讀起來檔案間跳轉次數還是非常多。這是第一個弊端，就是繼承層次的問題。第二個弊端就是，泛型帶來的難度，有一些通用演算法和資料結構，泛型化是應該的，但是也帶來了使用和編寫上的難度。這一點以cxx為代表，有時候編譯時泛型報個錯，一螢幕都裝不下。第三個就是類太多，類和方法的結合緊密，以至於出現了aop這種方法，用於解耦。想要新增修改一個功能點，有時候需要修改很多類，因為是面向物件的，不是面向過程的，所以要根據流程圖，去抓出所有涉及的物件，然後修改成員和方法。go語言的鴨子型別一定程度上緩解了這種情況。

做了好多年面向物件程式設計，最近做嵌入式軟體開發，純C語言，突然發現了面向過程程式設計，在這些方面比面向物件更有優勢：

1. 讓您能夠自頂向下，完全掌握軟體的架構；

2. 軟體的每一個細節，您都清楚；

3. 生成的二進位制檔案非常緊湊，執行效率比JAVA和C++都要高。

但是面向物件有個非常大的好處，就是軟體開發速度快，而且符合人的邏輯思維方式。

面相物件，其實是一套方法論體系。在計算機程式設計領域，通過這一套方法論來模擬真實世界。可以說，面向物件吸取了人類至今所有的哲學成果，是以“上帝”視角來觀察、模擬世界的。

事實上面向物件主要在面向物件分析、設計這兩塊，而面向物件程式設計只是最後的實現。

如果說面向物件的優點，可以說目前所有技術產品都有面向物件的影子，這種方法論已經稱為IT包括網際網路領域最基礎的思維方式，其影響無時無處不在。

要說它有哪些缺點，這個還真不能說是缺點，只能和麵向過程方法進行比較。相較於面向過程，面向物件相對更為複雜一些，所需的程式碼量更大，CPU的計算量也更大。但這些代價都是有明確好處的。