原文地址：http://www.android-doc.com/androiddocs/2017/0911/3389.html
1，面向?qū)ο笕筇匦裕?br> 封裝：封裝是把過(guò)程和數(shù)據(jù)包圍起來(lái)，對(duì)數(shù)據(jù)的訪問(wèn)只能通過(guò)已定義的接口。
繼承：
多態(tài)：多態(tài)就是指程序中定義的引用變量所指向的具體類型和通過(guò)該引用變量發(fā)出的方法調(diào)用在編程時(shí)并不確定，而是在程序運(yùn)行期間才確定，即一個(gè)引用變量倒底會(huì)指向哪個(gè)類的實(shí)例對(duì)象，該引用變量發(fā)出的方法調(diào)用到底是哪個(gè)類中實(shí)現(xiàn)的方法，必須在由程序運(yùn)行期間才能決定。因?yàn)樵诔绦蜻\(yùn)行時(shí)才確定具體的類，這樣，不用修改源程序代碼，就可以讓引用變量綁定到各種不同的類實(shí)現(xiàn)上，從而導(dǎo)致該引用調(diào)用的具體方法隨之改變，即不修改程序代碼就可以改變程序運(yùn)行時(shí)所綁定的具體代碼，讓程序可以選擇多個(gè)運(yùn)行狀態(tài)，這就是多態(tài)性。
2，程序設(shè)計(jì)的6大原則
（一）單一職責(zé)原則（地址：https://baike.baidu.com/item/%E5%8D%95%E4%B8%80%E8%81%8C%E8%B4%A3%E5%8E%9F%E5%88%99/9456515?fr=aladdin）:
我把關(guān)鍵內(nèi)容整理一下
(1)原理：如果一個(gè)類承擔(dān)的職責(zé)過(guò)多，就等于把這些職責(zé)耦合在一起了。一個(gè)職責(zé)的變化可能會(huì)削弱或者抑制這個(gè)類完成其他職責(zé)的能力。這種耦合會(huì)導(dǎo)致脆弱的設(shè)計(jì)，當(dāng)發(fā)生變化時(shí)，設(shè)計(jì)會(huì)遭受到意想不到的破壞。而如果想要避免這種現(xiàn)象的發(fā)生，就要盡可能的遵守單一職責(zé)原則。此原則的核心就是解耦和增強(qiáng)內(nèi)聚性。
（2）問(wèn)題由來(lái)：之所以會(huì)出現(xiàn)單一職責(zé)原則就是因?yàn)樵谲浖O(shè)計(jì)時(shí)會(huì)出現(xiàn)以下類似場(chǎng)景：
T負(fù)責(zé)兩個(gè)不同的職責(zé)：職責(zé)P1，職責(zé)P2。當(dāng)由于職責(zé)P1需求發(fā)生改變而需要修改類T時(shí)，有可能會(huì)導(dǎo)致原本運(yùn)行正常的職責(zé)P2功能發(fā)生故障。也就是說(shuō)職責(zé)P1和P2被耦合在了一起。
（3）產(chǎn)生原因：沒(méi)有任何的程序設(shè)計(jì)人員不清楚應(yīng)該寫(xiě)出高內(nèi)聚低耦合的程序，但是很多耦合常常發(fā)生在不經(jīng)意之間，其原因就是：
職責(zé)擴(kuò)散：因?yàn)槟撤N原因，某一職責(zé)被分化為顆粒度更細(xì)的多個(gè)職責(zé)了
（4）解決辦法：遵守單一職責(zé)原則，將不同的職責(zé)封裝到不同的類或模塊中。
（二）里氏替換原則：（參考地址：http://blog.csdn.net/zhengzhb/article/details/7281833）
文章中有一句總結(jié)寫(xiě)的很好：子類可以擴(kuò)展父類的功能，但不能改變父類原有的功能。
具體包含了以下4點(diǎn)：
（1）子類可以實(shí)現(xiàn)父類的抽象方法，但不能覆蓋父類的非抽象方法。
（2）子類可以實(shí)現(xiàn)自己特有的方法
（3）當(dāng)子類的方法重載父類的方法時(shí)，方法的前置條件（即方法的形參）要比父類方法的輸入?yún)?shù)更寬松。
（4）當(dāng)子類的方法實(shí)現(xiàn)父類的抽象方法時(shí)，方法的后置條件（即方法的返回值）要比父類更嚴(yán)格。
（三）依賴倒置原則（參考地址：http://blog.csdn.net/zhengzhb/article/details/7289269）：
我覺(jué)得自己理解的還不夠好，下次再閱讀是加入理解。
（四）接口隔離原則（參考地址http://blog.csdn.net/zhengzhb/article/details/7296921）：這個(gè)原則主要是說(shuō)將接口模塊化，不要讓接口過(guò)于龐大，使得在其他類實(shí)現(xiàn)該接口時(shí)實(shí)現(xiàn)了很多自己用不到的方法。
（五）迪米特法則（參考地址：http://www.itdecent.cn/p/14589fb6978e）： 簡(jiǎn)單來(lái)說(shuō)就是一個(gè)類A在決定要讓其他類B調(diào)用時(shí)，要保證只給B需要的方法，將其他方法設(shè)置為protected，這樣類B也就知道這些展示給我的才是我需要用的到的，其他的是自己所不需要展示的。
（六）開(kāi)閉原則（參考地址：http://blog.csdn.net/zhengzhb/article/details/7296944）：
總結(jié)：其實(shí)在最初接觸java時(shí)，我很質(zhì)疑反射的存在。我一度認(rèn)為這是脫了褲子放屁的行為。但是，再后來(lái)我用反射實(shí)現(xiàn)了需求時(shí)。我才知道，這是個(gè)很強(qiáng)大的功能。其實(shí)，我想說(shuō)的是所謂的原則就像是義務(wù)一樣。我們可以按照原則來(lái)，也可以不按照。我們?cè)谧铋_(kāi)始使用這些原則時(shí)是痛苦的，因?yàn)樗拗屏宋覀兊暮芏喾绞?。因此，?xiě)代碼的速度會(huì)下降。但是，正是因?yàn)橛羞@些規(guī)則，在我們項(xiàng)目需要該需求的時(shí)候才會(huì)方便很多。因?yàn)榇a之間的聯(lián)系（耦合）確實(shí)很少。我們之前可能要一個(gè)一個(gè)找的內(nèi)容，現(xiàn)在只需要修改一塊的代碼就可以了。