在20世(shi)紀90年代(dai)，面(mian)(mian)向對象的(de)編程(cheng)思(si)想已(yi)經逐步(bu)代(dai)替了面(mian)(mian)向過程(cheng)編程(cheng)思(si)想。特別在當前的(de)大型企(qi)業應(ying)用(yong)項目中，使用(yong)面(mian)(mian)向對象的(de)程(cheng)序設(she)計思(si)想進行軟件設(she)計，可以構(gou)造出較穩定、易擴展、易維護的(de)軟件。

面向對象的程序設計思想發展到今天，已經有20多年的歷史了。然而在一些使用面向對象技術（如JAVA）編寫的軟件程序中，仍然可以看到很大篇幅的過程式代碼，這使得軟件在穩定性、可讀性上都大打折扣。要想解決這一問題，需要掌握面向對象的原則以及實現面向對象的方法。
程序員朋友都聽(ting)說過，面向對象(xiang)有以下(xia)幾大基本原則：

開閉原則

對擴展(zhan)開放，對修(xiu)改關閉。通(tong)俗點(dian)說，一個軟件(jian)或一個模(mo)塊，在需要增加(jia)新(xin)的功(gong)能時，如(ru)果通(tong)過增加(jia)新(xin)的代(dai)(dai)碼或修(xiu)改現(xian)有代(dai)(dai)碼的外圍代(dai)(dai)碼（非核心代(dai)(dai)碼）即可(ke)實現(xian)，那么我們可(ke)以說，這個軟件(jian)或模(mo)塊滿(man)足了開閉原則。

依賴倒轉原則

依賴(lai)抽(chou)象而不(bu)是依賴(lai)具(ju)體(ti)(ti)。通俗(su)點說(shuo)，程序只依賴(lai)抽(chou)象類或接(jie)口，不(bu)依賴(lai)具(ju)體(ti)(ti)類。具(ju)體(ti)(ti)類的修改(gai)（改(gai)名稱、改(gai)方法實現）不(bu)會影(ying)響其它類的代碼。

里氏代換原則

父類(lei)(lei)可以(yi)出現(xian)(xian)的(de)地(di)方，子(zi)類(lei)(lei)就一定可以(yi)出現(xian)(xian)。因此子(zi)類(lei)(lei)在覆蓋父類(lei)(lei)方法(fa)(fa)(fa)時(shi)，方法(fa)(fa)(fa)的(de)實現(xian)(xian)與父類(lei)(lei)相比(bi)在“量”上(shang)可以(yi)不同，在“方向”上(shang)要一致。舉個(ge)簡單例子(zi)：父類(lei)(lei)有一個(ge)邏輯驗證(zheng)方法(fa)(fa)(fa)，當驗證(zheng)通(tong)過時(shi)返回true，未通(tong)過時(shi)返回false。現(xian)(xian)在子(zi)類(lei)(lei)將該方法(fa)(fa)(fa)覆蓋為通(tong)過時(shi)返回false，未通(tong)過時(shi)返回true，這顯(xian)然會造成軟件邏輯上(shang)的(de)錯誤(wu)。

接口隔離原則

使用(yong)多個專(zhuan)門的接(jie)口(kou)比使用(yong)單一(yi)的總接(jie)口(kou)要好。廢話，一(yi)個類做(zuo)完全(quan)部(bu)事情，你受得了？

?迪米特法則

一(yi)(yi)(yi)個(ge)(ge)類與另(ling)一(yi)(yi)(yi)個(ge)(ge)類（或一(yi)(yi)(yi)個(ge)(ge)模塊(kuai)與另(ling)一(yi)(yi)(yi)個(ge)(ge)模塊(kuai)、一(yi)(yi)(yi)個(ge)(ge)軟(ruan)件系統(tong)與另(ling)一(yi)(yi)(yi)個(ge)(ge)軟(ruan)件系統(tong)）之(zhi)間的(de)通(tong)信(xin)要盡(jin)可能少，換(huan)句話(hua)說彼此了(le)解得越(yue)少越(yue)安全（你知道得太多了(le)J）

上述幾個原則(ze)(ze)即是面向(xiang)對(dui)象開發時要注意的幾個基本(ben)原則(ze)(ze)，還(huan)有一些其它(ta)原則(ze)(ze)，本(ben)文不一一列舉。

有了這幾個(ge)(ge)(ge)(ge)原則作為(wei)面向(xiang)對象開發軟(ruan)件(jian)的(de)衡(heng)量(liang)標(biao)準，可以(yi)多多測量(liang)自己所編寫(xie)代碼的(de)水平。每當(dang)寫(xie)完一個(ge)(ge)(ge)(ge)方(fang)法、一個(ge)(ge)(ge)(ge)類(lei)、一個(ge)(ge)(ge)(ge)模塊(kuai)時(shi)，不妨用上(shang)述幾個(ge)(ge)(ge)(ge)原則來考量(liang)一下。腦(nao)海(hai)中時(shi)常(chang)多問自己1個(ge)(ge)(ge)(ge)問題：當(dang)今后增加(jia)XX功能時(shi)，我現有的(de)代碼要如何修改？如果(guo)你自己的(de)答案是勿須(xu)修改現有的(de)核(he)心代碼（這些代碼可能是你冥思苦想、絞盡腦(nao)汁(zhi)的(de)心血），只須(xu)增加(jia)代碼，加(jia)點配置(zhi)文件(jian)什么的(de)，那恭喜你，你的(de)程序具有很強(qiang)的(de)可擴(kuo)展性。

如果你(ni)的(de)(de)答案是可(ke)能要改自己的(de)(de)核(he)心(xin)代(dai)(dai)碼(ma)(ma)，那估(gu)計到(dao)時候就悲劇了，傳說中的(de)(de)牽一(yi)(yi)發而(er)動全身就是說的(de)(de)你(ni)這(zhe)(zhe)(zhe)(zhe)種軟件(jian)。新功(gong)能一(yi)(yi)增加，bug到(dao)處(chu)亂竄，為了解決這(zhe)(zhe)(zhe)(zhe)一(yi)(yi)問題(ti)，你(ni)可(ke)能采取另(ling)一(yi)(yi)個辦法，就是不(bu)修(xiu)(xiu)改現有核(he)心(xin)代(dai)(dai)碼(ma)(ma)，將這(zhe)(zhe)(zhe)(zhe)份代(dai)(dai)碼(ma)(ma)復制一(yi)(yi)份到(dao)另(ling)外一(yi)(yi)個地方，然后(hou)去(qu)修(xiu)(xiu)改復制出來的(de)(de)代(dai)(dai)碼(ma)(ma)，這(zhe)(zhe)(zhe)(zhe)樣(yang)一(yi)(yi)來，你(ni)就會陷(xian)入(ru)一(yi)(yi)個代(dai)(dai)碼(ma)(ma)泥(ni)潭，越(yue)陷(xian)越(yue)深最(zui)終不(bu)能自拔。

為了使自(zi)己編寫的(de)(de)軟件滿(man)足面向對(dui)象(xiang)的(de)(de)這些原則(ze)，我(wo)們(men)在程序(xu)開(kai)發時，不妨使用管理的(de)(de)思維(wei)來編寫程序(xu)。

當你(ni)(ni)(ni)收到某一(yi)(yi)個功能需求時(shi)，在以前也許會直(zhi)接聯想到該用哪些API來實現，該用幾(ji)個循環，什么條件下(xia)使(shi)用什么樣的(de)(de)(de)(de)if判斷(duan)等。如果你(ni)(ni)(ni)真是這(zhe)(zhe)樣想的(de)(de)(de)(de)，那么即使(shi)你(ni)(ni)(ni)是使(shi)用的(de)(de)(de)(de)java之類的(de)(de)(de)(de)面向對象語(yu)言，你(ni)(ni)(ni)編寫(xie)出(chu)的(de)(de)(de)(de)代(dai)(dai)碼(ma)仍然是面向過程的(de)(de)(de)(de)。也許你(ni)(ni)(ni)不自(zi)覺的(de)(de)(de)(de)就在一(yi)(yi)個方法中，用幾(ji)百行(xing)代(dai)(dai)碼(ma)實現了這(zhe)(zhe)個功能需求。其(qi)中，循環套循環、if嵌if，這(zhe)(zhe)樣的(de)(de)(de)(de)代(dai)(dai)碼(ma)也許你(ni)(ni)(ni)自(zi)己隔個三(san)兩天來看(kan)，都(dou)不容易看(kan)懂，如果換一(yi)(yi)個人來維護(hu)這(zhe)(zhe)樣的(de)(de)(de)(de)代(dai)(dai)碼(ma)，估計要(yao)吐血。在這(zhe)(zhe)樣的(de)(de)(de)(de)代(dai)(dai)碼(ma)海(hai)洋中，如果在不起眼的(de)(de)(de)(de)角(jiao)落里，有(you)一(yi)(yi)個字符輸(shu)入錯誤，估計你(ni)(ni)(ni)會花很大的(de)(de)(de)(de)力氣才(cai)檢查(cha)得(de)出(chu)來。

如果你用管(guan)理(li)的(de)(de)(de)(de)思維來(lai)編(bian)(bian)寫程序，那就(jiu)不一樣了(le)。則在編(bian)(bian)寫代(dai)碼(ma)前(qian)，你會(hui)想象(xiang)，實(shi)(shi)現(xian)這(zhe)個(ge)(ge)(ge)功能需求(qiu)，需要一系列的(de)(de)(de)(de)類(lei)，就(jiu)好象(xiang)要做一件事情，不是(shi)(shi)一個(ge)(ge)(ge)人去完(wan)成它，而是(shi)(shi)一個(ge)(ge)(ge)團隊(dui)去完(wan)成。這(zhe)個(ge)(ge)(ge)團隊(dui)有(you)自己(ji)的(de)(de)(de)(de)部(bu)(bu)(bu)門(men)(men)組(zu)織機構（package包(bao)(bao)），每個(ge)(ge)(ge)部(bu)(bu)(bu)門(men)(men)下(xia)面都(dou)(dou)有(you)多(duo)(duo)個(ge)(ge)(ge)員(yuan)(yuan)工（class類(lei)）。各個(ge)(ge)(ge)部(bu)(bu)(bu)門(men)(men)有(you)自己(ji)的(de)(de)(de)(de)職責(ze)（包(bao)(bao)的(de)(de)(de)(de)分類(lei)），各個(ge)(ge)(ge)員(yuan)(yuan)工也有(you)自己(ji)的(de)(de)(de)(de)職責(ze)（抽象(xiang)類(lei)或接口）。員(yuan)(yuan)工與員(yuan)(yuan)工之間如何(he)溝通(tong)，部(bu)(bu)(bu)門(men)(men)與部(bu)(bu)(bu)門(men)(men)之間如何(he)通(tong)信(xin)，這(zhe)些(xie)都(dou)(dou)可以參考現(xian)實(shi)(shi)中(zhong)大(da)型企業的(de)(de)(de)(de)管(guan)理(li)來(lai)實(shi)(shi)現(xian)。當你將(jiang)這(zhe)些(xie)部(bu)(bu)(bu)門(men)(men)和(he)員(yuan)(yuan)工的(de)(de)(de)(de)職責(ze)設計(ji)好，相當于程序中(zhong)的(de)(de)(de)(de)包(bao)(bao)和(he)類(lei)以及類(lei)中(zhong)的(de)(de)(de)(de)方(fang)法(fa)就(jiu)設計(ji)好了(le)，最后來(lai)實(shi)(shi)現(xian)這(zhe)些(xie)方(fang)法(fa)，相信(xin)是(shi)(shi)游刃有(you)余的(de)(de)(de)(de)了(le)。在這(zhe)種系統中(zhong)，每個(ge)(ge)(ge)類(lei)的(de)(de)(de)(de)職責(ze)都(dou)(dou)很清晰，每個(ge)(ge)(ge)方(fang)法(fa)的(de)(de)(de)(de)代(dai)碼(ma)都(dou)(dou)不多(duo)(duo)，如果有(you)某(mou)個(ge)(ge)(ge)字符(fu)輸(shu)入錯誤，會(hui)很容易的(de)(de)(de)(de)發現(xian)它。這(zhe)也正是(shi)(shi)很多(duo)(duo)人推崇(chong)的(de)(de)(de)(de)一個(ge)(ge)(ge)方(fang)法(fa)只做一件事情的(de)(de)(de)(de)原(yuan)因。

在使用管理(li)的(de)(de)思維(wei)來編寫程序(xu)時，因(yin)為程序(xu)中(zhong)(zhong)的(de)(de)類(lei)的(de)(de)方(fang)法(fa)簽名會對應到(dao)管理(li)體系(xi)中(zhong)(zhong)的(de)(de)員工職(zhi)責(ze)(ze)，因(yin)此(ci)，要(yao)善(shan)于(yu)區(qu)(qu)分這些職(zhi)責(ze)(ze)的(de)(de)重(zhong)要(yao)性，將核(he)心職(zhi)責(ze)(ze)放(fang)在核(he)心類(lei)中(zhong)(zhong)實(shi)(shi)現，業(ye)(ye)務(wu)(wu)職(zhi)責(ze)(ze)放(fang)在業(ye)(ye)務(wu)(wu)類(lei)中(zhong)(zhong)實(shi)(shi)現。核(he)心職(zhi)責(ze)(ze)是系(xi)統中(zhong)(zhong)長期(qi)不變(bian)的(de)(de)（相對的(de)(de)長期(qi)），要(yao)放(fang)在抽象類(lei)中(zhong)(zhong)，業(ye)(ye)務(wu)(wu)職(zhi)責(ze)(ze)根據業(ye)(ye)務(wu)(wu)的(de)(de)變(bian)化會相應的(de)(de)變(bian)化，因(yin)此(ci)要(yao)放(fang)在具體實(shi)(shi)現類(lei)中(zhong)(zhong)。區(qu)(qu)分核(he)心和業(ye)(ye)務(wu)(wu)的(de)(de)目(mu)的(de)(de)是為了提高系(xi)統的(de)(de)穩(wen)定性，正是所謂(wei)的(de)(de)要(yao)善(shan)于(yu)區(qu)(qu)分變(bian)和不變(bian)的(de)(de)部分。

現(xian)在我們用(yong)管理(li)的思(si)維再來驗證一下(xia)面(mian)向對象(xiang)的幾(ji)大(da)原則！

開閉原則

當(dang)(dang)(dang)新(xin)功能(neng)需要增(zeng)(zeng)加時，相當(dang)(dang)(dang)于一(yi)(yi)個團(tuan)隊(dui)有(you)新(xin)的業務(wu)(wu)需要開展（這個新(xin)業務(wu)(wu)與老(lao)業務(wu)(wu)在性質上(shang)是(shi)一(yi)(yi)樣的，不會(hui)(hui)是(shi)完全不同的領域），現實(shi)中當(dang)(dang)(dang)然(ran)是(shi)新(xin)增(zeng)(zeng)一(yi)(yi)兩個業務(wu)(wu)員，或者新(xin)增(zeng)(zeng)一(yi)(yi)個業務(wu)(wu)部門即可，對團(tuan)隊(dui)的核心(xin)組織架構(gou)當(dang)(dang)(dang)然(ran)不會(hui)(hui)有(you)影響(xiang)。

依賴倒轉原則

員(yuan)(yuan)工(gong)是(shi)(shi)具(ju)(ju)體(ti)類，員(yuan)(yuan)工(gong)的(de)崗位(wei)職責是(shi)(shi)抽(chou)(chou)象類。一個(ge)(ge)員(yuan)(yuan)工(gong)需要(yao)與(yu)另外(wai)一個(ge)(ge)員(yuan)(yuan)工(gong)進行協作時(shi)，認定的(de)當然是(shi)(shi)這個(ge)(ge)崗位(wei)，而(er)不是(shi)(shi)具(ju)(ju)體(ti)某(mou)個(ge)(ge)人。比如：運營中(zhong)心的(de)銷(xiao)售員(yuan)(yuan)需要(yao)向研發中(zhong)心的(de)程序員(yuan)(yuan)反(fan)饋(kui)客戶的(de)需求(qiu)，他只要(yao)找到(dao)研發中(zhong)心任何(he)一個(ge)(ge)具(ju)(ju)有(you)程序員(yuan)(yuan)崗位(wei)職責的(de)人都可以(yi)，而(er)不是(shi)(shi)非要(yao)找到(dao)研發中(zhong)心的(de)張三，這就(jiu)是(shi)(shi)依賴抽(chou)(chou)象（崗位(wei)職責），不依賴具(ju)(ju)體(ti)（張三）。

里氏代換原則

實施部在客戶倉庫實施項目，實施員甲生病了，要請假回家休息，這時，公司的實施員乙馬上奔赴現場，接替實施員甲的工作，保證項目按計劃進度完成，項目質量未受到任何影響。
以上場(chang)景(jing)可(ke)(ke)以看出，實施員(yuan)(yuan)甲(jia)和(he)乙兩人都(dou)具有相同的(de)崗位(wei)職(zhi)責，因此(ci)，凡是實施員(yuan)(yuan)（基類(lei)）可(ke)(ke)以出現的(de)地方，任何具體(ti)的(de)實施員(yuan)(yuan)（具體(ti)類(lei)或者(zhe)叫子類(lei)）都(dou)可(ke)(ke)以出現。

接口隔離原則

為什么一個管理良好(hao)的公司(si)要分銷(xiao)售(shou)部、研發部、財務部？這就是(shi)接口隔離(li)原則，分工合(he)作(zuo)，正所(suo)謂因為專注，所(suo)以專業(ye)。當一個類(lei)什么事(shi)情都要負責，那這個類(lei)會很健壯嗎？

迪米特法則

銷售部問研發部，XX軟件在XX日期能否研發完？研發部說，我要先花XX天做什么什么工作，再花XX天做什么什么工作……銷售部煩了，我沒問你那么多，你只管說能還是不能就行了。
可以(yi)看出(chu)，上述(shu)對話(hua)中，研發部(bu)過(guo)多的暴露(lu)了內(nei)部(bu)的細節，不滿(man)足迪(di)米特法則(ze)。因此，系統(tong)與(yu)系統(tong)通(tong)信、模塊與(yu)模塊通(tong)信、類(lei)與(yu)類(lei)通(tong)信之間(jian)的接(jie)口數(shu)量以(yi)及暴露(lu)的信息，在滿(man)足功能需(xu)要的前提下，越(yue)少越(yue)好(hao)。

說了這(zhe)么多廢(fei)話，相信大家都(dou)有自己的認識(shi)。其實完(wan)全可以(yi)將生(sheng)(sheng)活中的各種經驗(yan)用在(zai)軟件(jian)(jian)開發(fa)中，軟件(jian)(jian)的靈感來(lai)自于生(sheng)(sheng)活，因為軟件(jian)(jian)的目的是為了生(sheng)(sheng)活更(geng)美好！