你開始欣賞到純 C程式碼所帶來的 「美感」 了，即簡單性和可拆分性。程式碼是自底向上構造，一個模組只做好一個模組的事情，任意拆分組合。對於有參考的 OOP系統建模，自頂向下的構造程式碼抽象方法是有效率的，是方便的，對於新領域，沒有任何參考時，刻意抽象會帶來額外負擔，並進一步增加系統耦合性，設計調整，往往需要大面積修改程式碼。
有興趣你可以讀讀【Unix編程藝術】，OOP的思維模式，是大一統的；C的思維模式，是分離的。前者方便但容易造成高耦合，後者靈活但開發開發太累。用 C開發，應該刻意強調 「簡單」 和 「可拆分」。一個個象搭積木一樣的把基礎系統搭建出來，哪個模組出問題，局部替換即可。
自底向上的開發模式，並不是從不站在大局考慮問題，而是從某個子系統具體實作開始，從局部叠代，逐步反思全域設計，刻意保持低偶合，一個模組一個模組的來，再逐步嘗試組合。
自底向上強調先有實踐，再總結理論，理論反過來指導實踐，又從實踐中叠代修正理論。這和人類認識世界的順序是一樣的，先捕獵築巢，反思自然是怎麽回事，又發現可以生火，又思考自然到底怎麽回事情。
它的反面，是指大一統設計，你一開始用 UML畫出整套系統的類結構，然後再開工設計。這種思維習慣，如果是參考已有系統做一個類似的設計，問題不大，全新設計的話，他總有一個前提，就是 「你能完整認識整個大自然」，就像人類一開始就要認識捕獵和築巢還有取火一樣。否則每次對世界有了新認識，OOP的自頂向下設計方法都能給你帶來巨大的負擔。
所以有些人才會說：OOP設計習慣會依賴一系列設計靈巧的 BaseObject，然而過段時間後再來看你的計畫，當其中某個基礎抽象類出現問題是，往往面臨大範圍的程式碼調整。這其實就是他們使用自頂向下思維方法，在逐步進入新世界時候，所帶來的困惑。
當然也有人批判這種強調簡單性和可拆分性的 Unix思維。認為世界不是總能保持簡單和可拆分的，他們之間是有各種千絲萬縷聯系的，你一味的保持簡單性和可拆分性，你會讓別人很累。這裏給你個藥方，底層系統，基礎組建，盡量用 C的方法，很好的設計成模組，隨著你編程的積累，這些模組象積木一樣越來越多，而彼此都無太大關系，甚至不少 .c檔都能獨立執行，並沒有一個一統天下的 common.h讓大家去 include，介面其他語言也方便。
然後在你做到具體套用時根據不同的需求，用C++或者其他語言，將他們象膠水一樣粘合起來。這時候，再把你的 common.h，寫到你的 C++或者其他語言裏面去。當然，作為膠水的語言不一定非要是 C++了，也可以是其他語言。
-------------
PS: 這裏主要在探討 OOP存在的問題，並沒有討論嵌入式這種資源限制的情況，以及作業系統和底層等需要精確控制硬體和記憶體的情況，更沒有討論 C++在語言設計層面的事情。
---
