一種語言代表了一種思維，而思維決定了問題的解決方式。

?

從程序設計語言出現到現在已經經歷了四代。大多數高級語言都對應到第三代或四代程序設計語言。按其主要支持的編程模型（思維模式）分類，大致可以分為如下類型

1 ． 過程型：這類語言把應用抽象為序列化的操作步驟，其典型代表如PASCAL，C等。

2 ． 函數型：這類語言把應用抽象為函數（按定義，函數是從一個域到另一個域的映射）；它們試圖把問題分解為集合和集合間的函數關系。典型代表是LISP。

3 ． 邏輯型：這類語言把問題抽象為事實與規則的結合，試圖通過邏輯演算解決實際問題。典型代表是PROLOG。

4 ． 面向對象型：這類語言從上世紀80年代后迅速發展，這類語言試圖將實際問題抽象為獨立的對象以及對象間的交互，典型代表是早期的SmallTalk和Eiffel。

5 ． 面向數據結構型：這類語言將問題抽象為對結構化數據的操作，例如現在常用的SQL。

?

作為一個誕生與上世紀80年代初期的編程語言，C++被廣泛的認為是一種支持面向對象的語言；但是，我認為C++的偉大之處卻更多的在于（除了所提供完備的面向對象支持）它同樣提供了C的面向過程的編程模型以及只有少數高級語言能支持的范型編程（我更喜歡叫它面向算法的編程）。在實際的應用過程中，我們往往需要不同層次的抽象，C++所支持的廣泛的編程模型為我們提供了強大和靈活的工具，使得我們在設計和實現時能自如的選擇不同的模型，以最合理的（組合）方式解決問題。

?

不可否認，在當今的程序設計中，面向對象已經基本上是一統江湖，但它往往并不是最合理的選擇；例如在針對協議棧的開發中，使用面向過程的模型往往優于使用面向對象的模型（或許這也是為什么主流的電信設備供應商堅持使用C的原因？）；而在針對算法進行抽象時，使用面向對象的思維模式幾乎完全是不可行的（算法和對象間的不同之處是顯而易見的）；如果機械的運用面向對象思維，只能使最終產品的質量、可維護性、可讀性下降。

?

或許有人會問，那么應該如何選擇抽象方式呢？我覺得這個應該是因人和問題的不同而不同的，關鍵是在使用C++的過程中，多從這些方面進行思考、總結，以體會采用不同模式解決問題的優缺點，努力使用最合理的方式（或組合）對問題進行抽象并加以解決。我也常常為這些種種選擇而迷惑，因此在這兒也希望那些已經到了“不惑”層次的哥們多多指教。

?

當然，從另一方面來說，越多的選擇往往意味著越難的選擇，這或許也是為什么現在這么多人趨騖與更單純、更簡單的JAVA，C#的原因吧；但是當我們真正理解并掌握C++提供的這些編程模型時，我想我們會更加堅定當初選擇C++的信念;D

?

時間倉促，不正之處敬請指教。