摘要：眾多面向?qū)ο蟮木幊趟枷腚m不盡一致，但是無論哪種面向?qū)ο缶幊陶Z言都具有以下的共通功能。原型編程以類為中心的傳統(tǒng)面向?qū)ο缶幊?，是以類為基礎(chǔ)生成新對象。而原型模式的面向?qū)ο缶幊陶Z言沒有類這樣一個概念。

“什么是面向?qū)ο?？”這個問題往往會問到剛畢業(yè)的新手or實(shí)習(xí)生上，也是往往作為一個技術(shù)面試的開頭題。在這里我們不去談如何答(fu)好(yan)問(guo)題(qu)，僅談?wù)勎宜斫獾拿嫦驅(qū)ο蟆?/pre>
從歷史上看，從20世紀(jì)60年代末期到70年代，分別有幾個不同領(lǐng)域都發(fā)展了面向?qū)ο蟮乃枷?。比如?shù)據(jù)抽象的研究、人工智能領(lǐng)域中的知識表現(xiàn)（框架模型）、仿真對象的管理方法（Simula）、并行計算模型（Actor）以及在結(jié)構(gòu)化編程思想影響下而產(chǎn)生的面向?qū)ο蠓椒ā?br>框架模型是現(xiàn)實(shí)世界的模型化。從這個角度來看，“對象是對現(xiàn)實(shí)世界中具體事物的反映”這個觀點(diǎn)并沒有錯。
但是不管過去怎樣，現(xiàn)在對面向?qū)ο笞詈玫睦斫馐?，面向?qū)ο缶幊淌墙Y(jié)構(gòu)化編程的延伸。
結(jié)構(gòu)化編程基本上實(shí)現(xiàn)了控制流程的結(jié)構(gòu)化。但是程序流程雖然結(jié)構(gòu)化了，要處理的數(shù)據(jù)卻并沒有被結(jié)構(gòu)化。面向?qū)ο蟮脑O(shè)計方法是在結(jié)構(gòu)化編程對控制流程實(shí)現(xiàn)了結(jié)構(gòu)化后，又加上了對數(shù)據(jù)的結(jié)構(gòu)化。
眾多面向?qū)ο蟮木幊趟枷腚m不盡一致，但是無論哪種面向?qū)ο缶幊陶Z言都具有以下的共通功能。
1 . 不需要知道內(nèi)部的詳細(xì)處理就可以進(jìn)行操作（封裝、數(shù)據(jù)抽象）。
2 . 根據(jù)不同的數(shù)據(jù)類型自動選擇適當(dāng)?shù)姆椒ǎǘ鄳B(tài)性）。
為什么“面向?qū)ο蟆保?/b>
最早的時候是面向過程。想象一下一堆C語言or匯編堆砌在一起的函數(shù)互相調(diào)（shang）用(hai)的場景————什么？你說你沒學(xué)過C語言？那么你就想象一下一個復(fù)雜的SQL語句吧，有點(diǎn)像。
評論中有人提到了C語言并非完全不支持面向?qū)ο?，Struct就是一個不錯的選擇。的確，但是C語言對面向?qū)ο蟮闹С植⒉皇悄敲吹暮?。在絕大多數(shù)語言中都為Class（C++同時支持Struct和Class），但也有小部分語言沿用了這個經(jīng)典的名字——比如Go語言。在這里特別說明是為了防止誤導(dǎo)新手

把大象裝進(jìn)冰箱需要幾步？
我們以“把大象裝進(jìn)冰箱需要幾步”這個經(jīng)典的腦經(jīng)急轉(zhuǎn)彎來舉個例子吧：
面向過程
打開冰箱，裝入大象，關(guān)上冰箱。這三步就是面向過程的思考方式，這種思想強(qiáng)調(diào)的是過程，也可以叫做動作。
open(icebox);
putIn(icebox,elephant);
close(icebox);
面向?qū)ο?/b>
冰箱打開，冰箱存儲，冰箱關(guān)閉。這就是面向?qū)ο蟮乃伎挤绞剑@種方式強(qiáng)調(diào)是對象，也可以說是實(shí)例。
//我們有一個冰箱
Icebox iceBox = new iceBox();
//可不能忘記大象,就叫它jake吧
Elephant jake = new Elephant();
icebox.open();
icebox.save(jake);
icebox.close();
什么是面向?qū)ο螅?/b>
一種編程范式，相對于面向過程。為了方便在編程中更接近地去描述現(xiàn)實(shí)世界中的萬物（萬物皆對象），我們將對一個事物的描述稱之為類，而對象則是該事物的實(shí)例。
而面向?qū)ο蟮木幊谭椒ǔＲ姷挠腥N：

類模板方法
委派面向原型
組合

類模板
在類中，我們把事物的屬性轉(zhuǎn)變?yōu)榫幊讨械淖兞?，把事物的行為轉(zhuǎn)變?yōu)榉椒ā?/p>
Class Elephant{
  public String name;
  public int age;
  public double weight;
  //更多的屬性......

  //在這里的方法為了方便演示都是void
  public void eat(Food food){
    //吃東西
  }
  //更多的行為.......
}
對象
//我們再次召喚了jake
Elephant jake = new Elephant();
//他隨便吃了點(diǎn)什么
jake.eat(new Something);

面向?qū)ο笏峁┑奶匦?/b>
繼承
可以使子類復(fù)用父類公開的變量、方法
//幾百年后，jake和它的子孫們進(jìn)化成了更強(qiáng)的大象
//它們被稱為：飛象
Class FlyElephant extends Elephant{
  public void fly(){
    //i belive i can fly~~
  }
}

//其中有一頭飛象叫jason
FlyElephant jason = new FlyElephant();
//不要問大象為什么能飛！
jason.fly();
//而且還可以像其他大象一樣正常的吃東西
jason.eat(new Something);
如果把類當(dāng)作模塊，繼承就是利用模塊的方法。繼承的思想好像有其現(xiàn)實(shí)的知識基礎(chǔ)，但是把它看做純粹的模塊利用方法則更恰當(dāng)。
因為繼承只不過是抽象的功能利用方法，所以不必把對繼承的理解束縛在“繼承是對現(xiàn)實(shí)事物的分類的反映”。實(shí)際上這樣的想法反而妨礙了我們對繼承的理解。
封裝
屏蔽一系列的細(xì)節(jié)。使外部調(diào)用時只要知道這個方法的存在
jason在eat的時候它或許先會分泌一點(diǎn)激素有助于它進(jìn)食，然而我們在調(diào)用的時候并不知道發(fā)生了什么。
多態(tài)
父類的方法繼承的到子類以后可以有不同的實(shí)現(xiàn)方式
jason在eat的時候它或許先會分泌一點(diǎn)激素有助于它進(jìn)食，而jack在eat的時候或許會先刷個牙齒。
原型編程
以類為中心的傳統(tǒng)面向?qū)ο缶幊?，是以類為基礎(chǔ)生成新對象。類和對象的關(guān)系可以類比成鑄模和鑄件的關(guān)系。
而原型模式的面向?qū)ο缶幊陶Z言沒有類這樣一個概念。
以JavaScript為例。需要生成新的對象時，只要給對象追加屬性。設(shè)置函數(shù)對象作為屬性的話，就成為方法。當(dāng)訪問對象中不存在的屬性時，JavaScript 會去搜索該對象 prototype 屬性所指向的對象。
JavaScript 利用這個功能，使用“委派”而非“繼承”來實(shí)現(xiàn)面向?qū)ο缶幊獭?/p>
// 生成Doge。...（1）
function Doge(){
  this.sit = function () {return "I"m the king of the world"}
}
// 從Doge 生成對象dog...（2）
var doge = new Doge()
// doge 是狗，所以能 sit...（3）
alert(doge.sit())
// 生成新型myDoge...（4）
function MyDoge () {}
// 指定委派原型
MyDoge.prototype = new Dog()
// 從MyDoge 生成新對象myDoge...（5）
var myDoge = new MyDoge()
document.write(myDoge.sit()) 

函數(shù)其實(shí)做到了對象構(gòu)造器的作用

從原型生成對象：

生成對象；
將委派原型的內(nèi)部屬性（__proto__）設(shè)置為 Dog.prototype；
調(diào)用函數(shù) Dog，參數(shù)即為傳遞給 new 時的參數(shù)；
返回新生成的對象。


調(diào)用方法
定義原型函數(shù)，是空的
類似與第2步，生成新對象

和之前的Java通過類模板來實(shí)現(xiàn)面向?qū)ο蟮木幊谭绞较啾龋蛯ο笙到y(tǒng)支持一個更為直接的對象創(chuàng)建方法。例如，在 JavaScript 中，一個對象是一個簡單的屬性列表。每個對象包含另一個父類或原型 的一個特別引用，對象從父類或原型中繼承行為。
傳統(tǒng)對象系統(tǒng)和原型對象系統(tǒng)有本質(zhì)的區(qū)別。傳統(tǒng)對象被抽象地定義為概念組的一部分，從對象的其他類或組中繼承一些特性。相反，原型對象被具體地定義為特定對象，從其他特定對象中繼承行為。
因此，基于類的面向?qū)ο笳Z言具有雙重特性，至少需要 2 個基礎(chǔ)結(jié)構(gòu)：類和對象。由于這種雙重性，隨著基于類的軟件的發(fā)展，復(fù)雜的類層次結(jié)構(gòu)繼承也將逐漸開發(fā)出來。通常無法預(yù)測出未來類需要使用的方法，因此，類層次結(jié)構(gòu)需要不斷重構(gòu)，讓更改變得更輕松。
基于原型的語言會減少上述雙重性需求，促進(jìn)對象的直接創(chuàng)建和操作。如果沒有通過類來束縛對象，則會創(chuàng)建更為松散的類系統(tǒng)，這有助于維護(hù)模塊性并減少重構(gòu)需求。
然而話雖這么講，一大串原型鏈還是會讓人頭痛不已的，特別還是在動態(tài)語言中。
組合
繼承(inheritance)是實(shí)現(xiàn)代碼重用的有力手段，但它并非永遠(yuǎn)是完成這項任務(wù)的最佳工作。使用不當(dāng)會導(dǎo)致軟件變得很脆弱。在包的內(nèi)部使用繼承是非常安全的，在那里，子類和超類的實(shí)現(xiàn)都處于同一個程序員的控制下。對于專門為了繼承而設(shè)計的并且具有很好的文檔說明的類來說，使用繼承也是非常安全的。然而，對于普通的具體類進(jìn)行跨超包邊界的繼承則是非常危險的。本條目并不適用于接口繼承(一個類實(shí)現(xiàn)一個接口，或者一個接口擴(kuò)展另一個接口)。
方法調(diào)用不同的是，繼承打破了封裝性。子類信賴于其超類中特定功能的實(shí)現(xiàn)細(xì)節(jié)。超類的實(shí)現(xiàn)有可能會隨著發(fā)行版本的不同而有變化，子類有可能會被破壞。
在Java中，我們總是推薦使用interface而不是abstract class，這樣可以使代碼更加的靈活。在Java8后interface也是得到了增強(qiáng)——可以提供默認(rèn)的方法實(shí)現(xiàn)。
另外，Go語言也是將組合發(fā)揮到極致的語言。
面向?qū)ο蟮暮锰?/b>

接近人的思維，符合人類對現(xiàn)實(shí)世界的認(rèn)知；

封裝特性可以使開發(fā)者不必在意內(nèi)部的具體實(shí)現(xiàn)，更方便互相協(xié)作；

繼承特性可以減少代碼冗余，實(shí)現(xiàn)代碼復(fù)用；

多態(tài)特性令子類相比父類有不同的行為，這是非常接近現(xiàn)實(shí)的；

什么是面向?qū)ο?/b>
一種相對于面向過程的編程范式。
Java程序員應(yīng)了解的10個面向?qū)ο笤O(shè)計原則-原文

面向?qū)ο笤O(shè)計原則是 OOPS（Object-Oriented Programming System，面向?qū)ο蟮某绦蛟O(shè)計系統(tǒng)）編程的核心，但大多數(shù) Java 程序員追逐像 Singleton、Decorator、Observer 這樣的設(shè)計模式，而不重視面向?qū)ο蟮姆治龊驮O(shè)計。甚至還有經(jīng)驗豐富的 Java 程序員沒有聽說過 OOPS 和 SOLID設(shè)計原則，他們根本不知道設(shè)計原則的好處，也不知道如何依照這些原則來進(jìn)行編程。
眾所周知，Java 編程最基本的原則就是要追求高內(nèi)聚和低耦合的解決方案和代碼模塊設(shè)計。查看 Apache 和 Sun 的開放源代碼能幫助你發(fā)現(xiàn)其他 Java 設(shè)計原則在這些代碼中的實(shí)際運(yùn)用。Java Development Kit 則遵循以下模式：BorderFactory 類中的工廠模式、Runtime 類中的單件模式。你可以通過 Joshua Bloch 的《Effective Java》一書來了解更多信息。我個人偏向的另一種面向?qū)ο蟮脑O(shè)計模式是 Kathy Sierra 的 《Head First設(shè)計模式》 以及 《Head First Object Oriented Analysis and Design》。
雖然實(shí)際案例是學(xué)習(xí)設(shè)計原則或模式的最佳途徑，但通過本文的介紹，沒有接觸過這些原則或還在學(xué)習(xí)階段的 Java 程序員也能夠了解這 10 個面向?qū)ο蟮脑O(shè)計原則。其實(shí)每條原則都需要大量的篇幅才能講清楚，但我會盡力做到言簡意賅。
原則1：DRY（Don’t repeat yourself）
即不要寫重復(fù)的代碼，而是用“abstraction”類來抽象公有的東西。如果你需要多次用到一個硬編碼值，那么可以設(shè)為公共常量；如果你要 在兩個以上的地方使用一個代碼塊，那么可以將它設(shè)為一個獨(dú)立的方法。SOLID 設(shè)計原則的優(yōu)點(diǎn)是易于維護(hù)，但要注意，不要濫用，duplicate 不是針對代碼，而是針對功能。這意味著，即使用公共代碼來驗證 OrderID 和 SSN，二者也不會是相同的。使用公共代碼來實(shí)現(xiàn)兩個不同的功能，其實(shí)就是近似地把這兩個功能永遠(yuǎn)捆綁到了一起，如果 OrderID 改變了其格式，SSN 驗證代碼也會中斷。因此要慎用這種組合，不要隨意捆綁類似但不相關(guān)的功能。
原則2：封裝變化
在軟件領(lǐng)域中唯一不變的就是“Change”，因此封裝你認(rèn)為或猜測未來將發(fā)生變化的代碼。OOPS 設(shè)計模式的優(yōu)點(diǎn)在于易于測試和維護(hù)封轉(zhuǎn)的代碼。如果你使用 Java 編碼，可以默認(rèn)私有化變量和方法，并逐步增加訪問權(quán)限，比如從 private 到 protected 和 not public。有幾種 Java 設(shè)計模式也使用封裝，比如 Factory 設(shè)計模式是封裝“對象創(chuàng)建”，其靈活性使得之后引進(jìn)新代碼不會對現(xiàn)有的代碼造成影響。
原則3：開閉原則
即對擴(kuò)展開放，對修改關(guān)閉。這是另一種非常棒的設(shè)計原則，可以防止其他人更改已經(jīng)測試好的代碼。理論上，可以在不修改原有的模塊的基礎(chǔ)上，擴(kuò)展功能。這也是開閉原則的宗旨。
原則4：單一職責(zé)原則
類被修改的幾率很大，因此應(yīng)該專注于單一的功能。如果你把多個功能放在同一個類中，功能之間就形成了關(guān)聯(lián)，改變其中一個功能，有可能中止另一個功能，這時就需要新一輪的測試來避免可能出現(xiàn)的問題。
原則5：依賴注入或倒置原則
這個設(shè)計原則的亮點(diǎn)在于任何被 DI 框架注入的類很容易用 mock 對象進(jìn)行測試和維護(hù)，因為對象創(chuàng)建代碼集中在框架中，客戶端代碼也不混亂。有很多方式可以實(shí)現(xiàn)依賴倒置，比如像 AspectJ 等的 AOP（Aspect Oriented programming）框架使用的字節(jié)碼技術(shù)，或 Spring 框架使用的代理等。
原則6：優(yōu)先利用組合而非繼承
如果可能的話，優(yōu)先利用組合而不是繼承。一些人可能會質(zhì)疑，但我發(fā)現(xiàn)，組合比繼承靈活得多。組合允許在運(yùn)行期間通過設(shè)置類的屬性來改變類的行為，也可以通過使用接口來組合一個類，它提供了更高的靈活性，并可以隨時實(shí)現(xiàn)?！禘ffective Java》也推薦此原則。
原則7：里氏代換原則（LSP）
根據(jù)該原則，子類必須能夠替換掉它們的基類，也就是說使用基類的方法或函數(shù)能夠順利地引用子類對象。LSP 原則與單一職責(zé)原則和接口分離原則密切相關(guān)，如果一個類比子類具備更多功能，很有可能某些功能會失效，這就違反了 LSP 原則。為了遵循該設(shè)計原則，派生類或子類必須增強(qiáng)功能。
原則8：接口分離原則
采用多個與特定客戶類有關(guān)的接口比采用一個通用的涵蓋多個業(yè)務(wù)方法的接口要好。設(shè)計接口很棘手，因為一旦釋放接口，你就無法在不中斷執(zhí)行的情況 下改變它。在 Java 中，該原則的另一個優(yōu)勢在于，在任何類使用接口之前，接口不利于實(shí)現(xiàn)所有的方法，所以單一的功能意味著更少的實(shí)現(xiàn)方法。
原則9：針對接口編程，而不是針對實(shí)現(xiàn)編程
該原則可以使代碼更加靈活，以便可以在任何接口實(shí)現(xiàn)中使用。因此，在 Java 中最好使用變量接口類型、方法返回類型、方法參數(shù)類型等?！禘ffective Java》 和《Head First Design Pattern》書中也有提到。
原則 10：委托原則
該原則最典型的例子是 Java 中的 equals () 和 hashCode () 方法。為了平等地比較兩個對象，我們用類本身而不是客戶端類來做比較。這個設(shè)計原則的好處是沒有重復(fù)的代碼，而且很容易對其進(jìn)行修改。
總之，希望這些面向?qū)ο蟮脑O(shè)計原則能幫助你寫出更靈活更好的代碼。理論是第一步，更重要的是需要開發(fā)者在實(shí)踐中去運(yùn)用和體會。
擴(kuò)展閱讀

學(xué)習(xí)面向?qū)ο蟮牧詈鼪_ 
原型繼承-廖雪峰的官方網(wǎng)站
JavaScript--面向?qū)ο笈c原型(15)