許多人剛學程式設計時，想必都聽到過這樣的話：“*語言是面向物件的，而***語言是面向過程的”。那時的新人還懵懵懂懂，就被大牛或者書上的大牛騙去學了一種聽起來很厲害的語言，然而學了半天，也沒搞清楚楚自己面向了什麼，面向物件的還是沒找著物件，面向過程的找物件的過程也都還沒開始。不禁懷疑當年自己說出那句“教練，我想學這個”的時候腦袋裡都進了些什麼。

  然而學都學了，花在寫程式碼上的大把青春和大把頭髮終究是要不回來的，心痛之餘，只好再回頭看一自己那麼多年來到底面向了什麼：
  那年春節，宋丹丹問趙本山：“把大象放進冰箱，需要幾步？”——簡單，一位躲在暗處的大佬丟掉手上的菸頭，嘴角微微上揚。只見他在紙上寫道：

第一步，開啟冰箱
第二步，把大象塞進去
第三步，關上冰箱

  一個天衣無縫的解決方案，大佬看著自己的答案，志得意滿。

  這時，一個智者出現了，他看著大佬的答案，問了一個問題：

如果要把兩頭大象分別裝進兩個冰箱裡呢？

  大佬不屑地一笑：

這個問題同樣簡單，只需要將以上過程重複一遍就行了。

  智者聽到這個回答，嘆了口氣，遞給大佬一張圖紙，轉身離去。
  大佬看著這張圖紙，陷入了深思…

誰來開門？——面向過程和麵向物件的根本區別

  大佬的解決方案簡單粗暴，通俗易懂，與早期的純面向過程程式設計有著異曲同工之妙。他們都是將一個問題分解為若干小問題，再將這些小問題一一解決，這個做法看上去非常完美，並且可以解決大多數問題。
  在這一思路的指導下，程式設計師們會逐個開啟冰箱的門，每增多一個冰箱，就去開啟一次門。
  而智者給的圖紙上只有一個冰箱，這個冰箱會自己把門開啟。只要是按照這個圖紙生產出來的冰箱，就可以自己把門開啟，自己把大象裝進去，自己把門關上。人們不需要了解這一過程是如何實現的，只要在需要把大象裝進冰箱的時候，跟冰箱說一句：“嘿，你把大象裝進去吧。”

大佬也難免犯錯——封裝，讓物件的內部保持安全

  眾所周知，開門是個極為複雜的工作，這一過程涉及到了無數的零部件，即便是大佬，也很難保證在開門的過程中不影響到與之無關的零部件。有時候僅僅是改動到了一個微小的部件，也可能帶來不可估量的影響。在這種時候，我們迫切地需要一種方法，將與開門無關的部件保護起來，以免被大佬改動到。
  這種方法在面向物件程式設計中，被稱為封裝，物件為它內部的資料提供了不同級別的保護，確定了哪些資料只能由誰訪問，通過這樣的方式，我們可以有效地阻止程式執行過程中的某些意外錯誤地修改了無關的資料。

當冰箱的功能不止開門——繼承，讓物件青出於藍而勝於藍

  冰箱的流水線生產終於形成了一定規模，大佬滿意地看著這一成果。
  這時大佬腦袋中突然閃過一個想法：

我們能不能生產出可以調節內部溫度的冰箱呢？

  怎麼辦？要改動原來的圖紙嗎？還是重新畫一張圖紙？
  這時，流水線上的一個工人笑了：

你只需要告訴我們應該增加哪些零件和功能就行了。

  大佬聞言，吃了一驚，手中所執圖紙，不覺落於地下。時正值天雨將至，雷聲大作。大佬乃從容俯首拾圖紙曰：“一震之威，乃至於此。”
  工人無意中道出的，便是面向物件程式設計的第二個基本特徵：繼承。繼承賦予新建立的類一種能力：它可以使用現有類的全部功能，而不需要為了擴充套件現有類的功能而重寫程式碼。正如前面的例子所說，我們要給冰箱設計新的功能，並不需要重新畫一張完整的圖紙，我們只需要設計一張只有新功能的圖紙就行了。在這一過程中，繼承了現有類的新類（新圖紙）被稱為子類或派生類，而被繼承的類（原圖紙）被稱為基類、父類或者超類。
  繼承可以使我們將不同的物件的相同特徵（開門）提取出來，做成一個基類（原圖紙），而其餘的內容則由派生類（新圖紙）來實現，從而大大縮短了程式碼的複雜度，提高了程式設計效率。

如何生產出不同型號的冰箱？——多型，讓物件更加靈活

  隨著冰箱和大象的不斷增多，原有的冰箱已經滿足不了大象們了——大佬需要更多不同型號的冰箱，但問題來了：對於不同型號的冰箱，我們是不是還能再接著說出和“嘿，你把大象裝進去吧。”一模一樣的話呢？
  在現實世界中，這一切似乎順理成章，但在不支援面向物件程式設計的語言中，我們不得不改動這句話，因為在這些語言中，函式的名稱不能相同。
  這時候，面嚮物件語言提供的多型，正好解決了這一問題。多型是指，當我們要做一件目的相同的事（開門），但必須採用不同方法時，我們可以用同樣的方式來呼叫它們（向冰箱說同樣的話），從而統一了這些過程的呼叫方式，提高了程式碼的可讀性。

沒有銀彈——不要為了面向物件而面向物件

  縱然面向物件程式設計可以給我們帶來諸多的便利，但請切記：它始終只是解決問題的無數方法中的一種，而不是唯一一種。並非所有問題都不得不用面向物件的方法解決，應該首先明確需要解決的問題，而非首先考慮解決問題的方法。避免無意義的封裝，繼承和多型，否則你的程式將會變得一團糟。
  Fred Brooks在他最著名的隨筆《No Silver Bullet》中提到，任何神奇的理論或方法，都不是能殺死軟體危機這頭人狼的銀彈，在軟體開發過程裡是沒有萬能的武器的，只有各種方法綜合運用，才是真正的解決之道。

參考資料：