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

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

開閉原則

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

依賴倒轉(zhuǎn)原則

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

里氏代換原則

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

接口隔離原則

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

?迪米特法則

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

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

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

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

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

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

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

在使用管理的思維來編寫程序時，因為程序中的類的方法簽名會對應(yīng)到管理體系中的員工職責，因此，要善于區(qū)分這些職責的重要性，將核心職責放在核心類中實現(xiàn)，業(yè)務(wù)職責放在業(yè)務(wù)類中實現(xiàn)。核心職責是系統(tǒng)中長期不變的（相對的長期），要放在抽象類中，業(yè)務(wù)職責根據(jù)業(yè)務(wù)的變化會相應(yīng)的變化，因此要放在具體實現(xiàn)類中。區(qū)分核心和業(yè)務(wù)的目的是為了提高系統(tǒng)的穩(wěn)定性，正是所謂的要善于區(qū)分變和不變的部分。

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

開閉原則

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

依賴倒轉(zhuǎn)原則

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

里氏代換原則

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

接口隔離原則

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

迪米特法則

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

說了這么多廢話，相信大家都有自己的認識。其實完全可以將生活中的各種經(jīng)驗用在軟件開發(fā)中，軟件的靈感來自于生活，因為軟件的目的是為了生活更美好！