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

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

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

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

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

  //在這里的方法為了方便演示都是void
  public void eat(Food food){
    //吃東西
  }
  //更多的行為.......
}
對(duì)象
//我們?cè)俅握賳玖薺ake
Elephant jake = new Elephant();
//他隨便吃了點(diǎn)什么
jake.eat(new Something);

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

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

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

從原型生成對(duì)象：

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


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

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

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

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

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

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

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

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

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