面向對象的本質是什麼？

　　什麼是面向對象的本質呢？

　　萬物皆對象？No

　　抽象？No

　　複用？No

　　那到底是什麼呢？

　　萬物皆對象。問了幾位網友，這是答複之一。看到了某個事物就來一個class？顯然沒有那麼簡單。至少也要抽象一下呀。

　　抽象。比如一些文章裡說，可以根據貓貓、狗狗抽象出來一個Animal出來，然後定義Cat，繼承Animal，在定義Dog，也是繼承Animal。抽象就是本質了嗎？那麼為什麼要抽象，而不直接定義Cat、Dog呢？這麼“折騰”一下的目的是什麼呢？或者說有什麼好處？

　　複用。Cat可以複用Animal裡的屬性、方法等，Dog也可以複用Animal裡的屬性方法。這樣看來複用好像就是本質了。

　　哎，說道複用我就比較郁悶。我是從面向過程學過來的，經過漫長艱苦的學習，現在還沒有完全轉到面向對象。好像跑題了。

　　面向過程裡就解決了複用的問題，定義一個過程（過程、函數）就可以達到複用的目的。别人有的，你也有，那不算什麼優勢。别人沒有的你有，那就是優勢了。既然面向過程已經可以服用了，那麼在面向對象裡面也談複用，那還有什麼優勢呢？

　　面向過程可以達到複用的目的，但是有一個緻命的缺點：混亂。定義出來的函數沒有層次，沒有管理。假設一個項目裡有一萬個函數，那麼這些個函數就會雜亂無章的出現。要管理的話也隻能按照頁面、窗體等來劃分。總之呢，想要管理好面向過程裡的衆多函數是一件頭痛的事情。

　　我覺得面向對象是有面向過程“進化”過來的，但是有人說面向對象是直接“蹦”出來的，不管他是怎麼出來的了，總之他是很好的解決了“管理複用”的問題。

封裝（Class）：把相關的屬性、方法、事件放在一起，化零為整，統一管理。該隐藏的隐藏，該暴露的暴露。這是管理的第一步。

====================

　　繼承：都封裝起來了，那麼就失去了靈活性。如何保證靈活性呢？繼承（還有函數重載等）。也就是多态了。相同的放在父類，不同的放在子類。這是我的了解，當然你可以說這種了解是錯誤的。Class就好比一個大的家族，父類是根基，子類各有各的特點。正所謂：龍生九子各有不同。

　　子類可以複用父類裡的屬性、方法、事件，這就是一種複用的管理方法。

　　組合（合成）：父類、子類、抽象基類，這些都是一個家族裡的關系，那麼兩個家族有如何呢？組合。Has A，一個類裡包含另一個類，通過這種方式來實作複用。這又是複用的一種管理方法。

　　接口：抽象基類是一個很好用的東東，比如DbCommand，用過的兄弟們都會體會到他的友善吧。但是他隻能管同一個家族裡的，另一個家族的就不行了。如果哪個資料庫（比如PostgreSQL）沒有繼承DbCommand怎麼辦呢？接口就可以跨越不同的家族。當然接口也有一個緻命的弱點，本身不能有任何的實作部分，他隻能定義。

　　面向對象的各種特點都是為了“管理複用”，是以我覺得面向對象的本質就是“管理複用”。至于對象隻是一種“表象”。

　　在多說幾句，我是不喜歡被所謂的“對象”所束縛的。以前問過，SQLHelp為什麼要寫成靜态函數的形式，答曰：資料通路是一個對象嗎？怎麼執行個體化呢？

　　我覺得資料庫就是一個對象，資料通路也是一個對象。資料通路就是資料庫的一個“代言人”。我的資料通路函數庫就是以DbCommand為中心人物，用起來非常的友善。