經常聽見別人說面向對象的程序設計，以前在學校上課的時候，也有開面向對象程序設計這門課。可是不幸的是，這些都是以C＋＋，甚至VC＋＋為基礎的。而更加不幸的是，多年以來我一直是一個C的使用者。在學校的時候，我主要做的是硬件上的驅動層，和底層功能層。在工作以后，又做的是手機上的軟件開發，所有這些都是和C離不開的。雖然我不得不說，C＋＋是一門很好的語言，但是它的編譯速度，代碼效率，編譯后的代碼大小都限制了它在嵌入式上的應用。（但現在的嵌入式CPU越來越快，內存容量變大。我覺得用C＋＋也應該沒有什么問題。這使我覺得似乎是嵌入式編譯器的限制。雖然菲利普和TI好像都有C＋＋的編譯器，但是似乎沒人用這個。難道是太貴了？ 但不管怎么說，嵌入式應用中，C語言的普遍使用是肯定的）
　　
　　那么在面向過程的時代產生的C語言能否使用面向對象的思想呢？我認為是肯定可以的，C＋＋不過是在語言級別上加入了對對象的支持，同時提供了豐富的對象庫。而在C語言下，我們只好自力更生了。
　　
　　一、面向對象思想的目的是框架化，手段是抽象
　　
　　相信很多人都明白面向對象講了什么：類，抽象類，繼承，多態。但是是什么原因促使這些概念的產生呢？
　　
　　打個比方說：你去買顯示器，然而顯示器的品牌樣式是多種多樣的，你在買的過程中發生的事情也是不可預測的。對于這樣的事情，我們在程序語言中如何去描述呢。面向對象的思想就是為了解決這樣的問題。編寫一個程序（甚至說是一個工程），從無到用是困難的，從有到豐富是更加困難的。面向對象將程序的各個行為化為對象，而又用抽象的辦法將這些對象歸類（抽象），從而將錯綜復雜的事情簡化為幾個主要的有機組合（框架化）。
　　
　　其實我們的身邊很多東西都是這樣組成的：比如說電腦：電腦是由主板，CPU加上各種卡組成的。這就是一個框架化。而忽略不同的CPU，不同的主板，不同的聲卡，網卡，顯卡的區別，這就是抽象。再比如說現在的教育網：是由主核心節點：清華，北大，北郵等幾個，然后是各個子節點，依次組成了整個教育網網絡。
　　
　　所以我覺得面向對象的編程思想就是：一個大型工程是分層次結構的，每層又由抽象的結構連接為整體（框架化），各個抽象結構之間是彼此獨立的，可以獨立進化（繼承，多態）。層次之間，結構之間各有統一的通訊方式（通常是消息，事件機制）。
　　
　　二、以前C語言編程中常用的“面向對象”方法

　　其實C語言誕生以來，人們就想了很多辦法來體現“面向對象”的思想。下面就來說說我所知道的方法。先說一些大家熟悉的東東，慢慢再講詭異的。呵呵
　　
　　1．　宏定義：
　　有的人不禁要問，宏定義怎么扯到這里來了，我們可以先看一個簡單的例子：
　　
　　＃define MacroFunction　Afunction
　　
　　然后在程序里面你調用了大量的AFunction，但是有，你突然發現你要用BFunction了，（不過AFunction又不能不要，很有可能你以后還要調用），這個時候，你就可以＃define MacroFunction　Bfunction來達到這樣的目的。
　　
　　當然，不得不說這樣的辦法是too simple，sometime na?ve的，因為一個很滑稽的問題是如果我一般要改為BFunction，一半不變怎么辦？ 那就只好查找替換了。
　　
　　2．　靜態的入口函數，保證函數名相同，利用標志位調用子函數：
　　這樣的典型應用很多，比如說網卡驅動里面有一個入口函數Nilan（int FunctionCode，Para*）。具體的參數是什么記不清楚了。不過NiLan的主體是這樣的：
　　Long Nilan（int FunctionCode，Para*）{
　　
　　Switch(FunctionCode){
　　
　　Case SendPacket:　　　　 send(….)
　　
　　Case ReceivePacket:　　　receive(…)
　　
　　…..
　　
　　}
　　
　　寫到這里大家明白什么意思了吧。保證相同的函數名就是說：網卡驅動是和pNA+協議棧互連的，那么如何保證pNA+協議棧和不同的驅動都兼容呢，一個簡單的辦法就是僅僅使用一個入口函數。通過改變如果函數的參數值，來調用內部的各個函數。這樣的做法是可以進化的：如果以后想調用新的函數，增加相應的函數參數值就好了。如果我們將網卡驅動和pNA+協議棧看作兩個層的話，我們可以發現：
　　
　　層與層之間的互連接口是很小的（這里是一個入口函數），一般是采用名字解析的辦法而不是具體的函數調用（利用FunctionCode調用函數，Nilan僅僅實現名字解析的功能）――！接口限制和名字解析
　　
　　接口限制：層與層之間僅僅知道有限的函數
　　
　　名字解析：層與層之間建立共同的名字與函數的對應關系，之間利用名字調用功能。