在20世紀(jì)90年代，面向?qū)ο蟮木幊趟枷胍呀?jīng)逐步代替了面向過程編程思想。特別在當(dāng)前的大型企業(yè)應(yīng)用項(xiàng)目中，使用面向?qū)ο蟮某绦蛟O(shè)計(jì)思想進(jìn)行軟件設(shè)計(jì)，可以構(gòu)造出較穩(wěn)定、易擴(kuò)展、易維護(hù)的軟件。

面向?qū)ο蟮某绦蛟O(shè)計(jì)思想發(fā)展到今天，已經(jīng)有20多年的歷史了。然而在一些使用面向?qū)ο蠹夹g(shù)（如JAVA）編寫的軟件程序中，仍然可以看到很大篇幅的過程式代碼，這使得軟件在穩(wěn)定性、可讀性上都大打折扣。要想解決這一問題，需要掌握面向?qū)ο蟮脑瓌t以及實(shí)現(xiàn)面向?qū)ο蟮姆椒ā?br /> 程序員朋友都聽說過，面向?qū)ο笥幸韵聨状蠡驹瓌t：

開閉原則

對(duì)擴(kuò)展開放，對(duì)修改關(guān)閉。通俗點(diǎn)說，一個(gè)軟件或一個(gè)模塊，在需要增加新的功能時(shí)，如果通過增加新的代碼或修改現(xiàn)有代碼的外圍代碼（非核心代碼）即可實(shí)現(xiàn)，那么我們可以說，這個(gè)軟件或模塊滿足了開閉原則。

依賴倒轉(zhuǎn)原則

依賴抽象而不是依賴具體。通俗點(diǎn)說，程序只依賴抽象類或接口，不依賴具體類。具體類的修改（改名稱、改方法實(shí)現(xiàn)）不會(huì)影響其它類的代碼。

里氏代換原則

父類可以出現(xiàn)的地方，子類就一定可以出現(xiàn)。因此子類在覆蓋父類方法時(shí)，方法的實(shí)現(xiàn)與父類相比在“量”上可以不同，在“方向”上要一致。舉個(gè)簡(jiǎn)單例子：父類有一個(gè)邏輯驗(yàn)證方法，當(dāng)驗(yàn)證通過時(shí)返回true，未通過時(shí)返回false。現(xiàn)在子類將該方法覆蓋為通過時(shí)返回false，未通過時(shí)返回true，這顯然會(huì)造成軟件邏輯上的錯(cuò)誤。

接口隔離原則

使用多個(gè)專門的接口比使用單一的總接口要好。廢話，一個(gè)類做完全部事情，你受得了？

?迪米特法則

一個(gè)類與另一個(gè)類（或一個(gè)模塊與另一個(gè)模塊、一個(gè)軟件系統(tǒng)與另一個(gè)軟件系統(tǒng)）之間的通信要盡可能少，換句話說彼此了解得越少越安全（你知道得太多了J）

上述幾個(gè)原則即是面向?qū)ο箝_發(fā)時(shí)要注意的幾個(gè)基本原則，還有一些其它原則，本文不一一列舉。

有了這幾個(gè)原則作為面向?qū)ο箝_發(fā)軟件的衡量標(biāo)準(zhǔn)，可以多多測(cè)量自己所編寫代碼的水平。每當(dāng)寫完一個(gè)方法、一個(gè)類、一個(gè)模塊時(shí)，不妨用上述幾個(gè)原則來考量一下。腦海中時(shí)常多問自己1個(gè)問題：當(dāng)今后增加XX功能時(shí)，我現(xiàn)有的代碼要如何修改？如果你自己的答案是勿須修改現(xiàn)有的核心代碼（這些代碼可能是你冥思苦想、絞盡腦汁的心血），只須增加代碼，加點(diǎn)配置文件什么的，那恭喜你，你的程序具有很強(qiáng)的可擴(kuò)展性。

如果你的答案是可能要改自己的核心代碼，那估計(jì)到時(shí)候就悲劇了，傳說中的牽一發(fā)而動(dòng)全身就是說的你這種軟件。新功能一增加，bug到處亂竄，為了解決這一問題，你可能采取另一個(gè)辦法，就是不修改現(xiàn)有核心代碼，將這份代碼復(fù)制一份到另外一個(gè)地方，然后去修改復(fù)制出來的代碼，這樣一來，你就會(huì)陷入一個(gè)代碼泥潭，越陷越深最終不能自拔。

為了使自己編寫的軟件滿足面向?qū)ο蟮倪@些原則，我們?cè)诔绦蜷_發(fā)時(shí)，不妨使用管理的思維來編寫程序。

當(dāng)你收到某一個(gè)功能需求時(shí)，在以前也許會(huì)直接聯(lián)想到該用哪些API來實(shí)現(xiàn)，該用幾個(gè)循環(huán)，什么條件下使用什么樣的if判斷等。如果你真是這樣想的，那么即使你是使用的java之類的面向?qū)ο笳Z言，你編寫出的代碼仍然是面向過程的。也許你不自覺的就在一個(gè)方法中，用幾百行代碼實(shí)現(xiàn)了這個(gè)功能需求。其中，循環(huán)套循環(huán)、if嵌if，這樣的代碼也許你自己隔個(gè)三兩天來看，都不容易看懂，如果換一個(gè)人來維護(hù)這樣的代碼，估計(jì)要吐血。在這樣的代碼海洋中，如果在不起眼的角落里，有一個(gè)字符輸入錯(cuò)誤，估計(jì)你會(huì)花很大的力氣才檢查得出來。

如果你用管理的思維來編寫程序，那就不一樣了。則在編寫代碼前，你會(huì)想象，實(shí)現(xiàn)這個(gè)功能需求，需要一系列的類，就好象要做一件事情，不是一個(gè)人去完成它，而是一個(gè)團(tuán)隊(duì)去完成。這個(gè)團(tuán)隊(duì)有自己的部門組織機(jī)構(gòu)（package包），每個(gè)部門下面都有多個(gè)員工（class類）。各個(gè)部門有自己的職責(zé)（包的分類），各個(gè)員工也有自己的職責(zé)（抽象類或接口）。員工與員工之間如何溝通，部門與部門之間如何通信，這些都可以參考現(xiàn)實(shí)中大型企業(yè)的管理來實(shí)現(xiàn)。當(dāng)你將這些部門和員工的職責(zé)設(shè)計(jì)好，相當(dāng)于程序中的包和類以及類中的方法就設(shè)計(jì)好了，最后來實(shí)現(xiàn)這些方法，相信是游刃有余的了。在這種系統(tǒng)中，每個(gè)類的職責(zé)都很清晰，每個(gè)方法的代碼都不多，如果有某個(gè)字符輸入錯(cuò)誤，會(huì)很容易的發(fā)現(xiàn)它。這也正是很多人推崇的一個(gè)方法只做一件事情的原因。

在使用管理的思維來編寫程序時(shí)，因?yàn)槌绦蛑械念惖姆椒ê灻麜?huì)對(duì)應(yīng)到管理體系中的員工職責(zé)，因此，要善于區(qū)分這些職責(zé)的重要性，將核心職責(zé)放在核心類中實(shí)現(xiàn)，業(yè)務(wù)職責(zé)放在業(yè)務(wù)類中實(shí)現(xiàn)。核心職責(zé)是系統(tǒng)中長(zhǎng)期不變的（相對(duì)的長(zhǎng)期），要放在抽象類中，業(yè)務(wù)職責(zé)根據(jù)業(yè)務(wù)的變化會(huì)相應(yīng)的變化，因此要放在具體實(shí)現(xiàn)類中。區(qū)分核心和業(yè)務(wù)的目的是為了提高系統(tǒng)的穩(wěn)定性，正是所謂的要善于區(qū)分變和不變的部分。

現(xiàn)在我們用管理的思維再來驗(yàn)證一下面向?qū)ο蟮膸状笤瓌t！

開閉原則

當(dāng)新功能需要增加時(shí)，相當(dāng)于一個(gè)團(tuán)隊(duì)有新的業(yè)務(wù)需要開展（這個(gè)新業(yè)務(wù)與老業(yè)務(wù)在性質(zhì)上是一樣的，不會(huì)是完全不同的領(lǐng)域），現(xiàn)實(shí)中當(dāng)然是新增一兩個(gè)業(yè)務(wù)員，或者新增一個(gè)業(yè)務(wù)部門即可，對(duì)團(tuán)隊(duì)的核心組織架構(gòu)當(dāng)然不會(huì)有影響。

依賴倒轉(zhuǎn)原則

員工是具體類，員工的崗位職責(zé)是抽象類。一個(gè)員工需要與另外一個(gè)員工進(jìn)行協(xié)作時(shí)，認(rèn)定的當(dāng)然是這個(gè)崗位，而不是具體某個(gè)人。比如：運(yùn)營中心的銷售員需要向研發(fā)中心的程序員反饋客戶的需求，他只要找到研發(fā)中心任何一個(gè)具有程序員崗位職責(zé)的人都可以，而不是非要找到研發(fā)中心的張三，這就是依賴抽象（崗位職責(zé)），不依賴具體（張三）。

里氏代換原則

實(shí)施部在客戶倉庫實(shí)施項(xiàng)目，實(shí)施員甲生病了，要請(qǐng)假回家休息，這時(shí)，公司的實(shí)施員乙馬上奔赴現(xiàn)場(chǎng)，接替實(shí)施員甲的工作，保證項(xiàng)目按計(jì)劃進(jìn)度完成，項(xiàng)目質(zhì)量未受到任何影響。
以上場(chǎng)景可以看出，實(shí)施員甲和乙兩人都具有相同的崗位職責(zé)，因此，凡是實(shí)施員（基類）可以出現(xiàn)的地方，任何具體的實(shí)施員（具體類或者叫子類）都可以出現(xiàn)。

接口隔離原則

為什么一個(gè)管理良好的公司要分銷售部、研發(fā)部、財(cái)務(wù)部？這就是接口隔離原則，分工合作，正所謂因?yàn)閷Ｗ?，所以專業(yè)。當(dāng)一個(gè)類什么事情都要負(fù)責(zé)，那這個(gè)類會(huì)很健壯嗎？

迪米特法則

銷售部問研發(fā)部，XX軟件在XX日期能否研發(fā)完？研發(fā)部說，我要先花XX天做什么什么工作，再花XX天做什么什么工作……銷售部煩了，我沒問你那么多，你只管說能還是不能就行了。
可以看出，上述對(duì)話中，研發(fā)部過多的暴露了內(nèi)部的細(xì)節(jié)，不滿足迪米特法則。因此，系統(tǒng)與系統(tǒng)通信、模塊與模塊通信、類與類通信之間的接口數(shù)量以及暴露的信息，在滿足功能需要的前提下，越少越好。

說了這么多廢話，相信大家都有自己的認(rèn)識(shí)。其實(shí)完全可以將生活中的各種經(jīng)驗(yàn)用在軟件開發(fā)中，軟件的靈感來自于生活，因?yàn)檐浖哪康氖菫榱松罡篮茫?/p>