在20世紀90年代，面向對象的編程思想已經逐步代替了面向過程編程思想。特別在當前的大型企業應用項目中，使用面向對象的程序設計思想進行軟件設計，可以構造出較穩定、易擴展、易維護的軟件。
面向對象的程序設計思想發展到今天，已經有20多年的歷史了。然而在一些使用面向對象技術（如JAVA）編寫的軟件程序中，仍然可以看到很大篇幅的過程式代碼，這使得軟件在穩定性、可讀性上都大打折扣。要想解決這一問題，需要掌握面向對象的原則以及實現面向對象的方法。
程序員朋友都聽說過，面向對象有以下幾大基本原則：
開閉原則
對擴展開放，對修改關閉。通俗點說，一個軟件或一個模塊，在需要增加新的功能時，如果通過增加新的代碼或修改現有代碼的外圍代碼（非核心代碼）即可實現，那么我們可以說，這個軟件或模塊滿足了開閉原則。
依賴倒轉原則
依賴抽象而不是依賴具體。通俗點說，程序只依賴抽象類或接口，不依賴具體類。具體類的修改（改名稱、改方法實現）不會影響其它類的代碼。
里氏代換原則
父類可以出現的地方，子類就一定可以出現。因此子類在覆蓋父類方法時，方法的實現與父類相比在“量”上可以不同，在“方向”上要一致。舉個簡單例子：父類有一個邏輯驗證方法，當驗證通過時返回true，未通過時返回false?，F在子類將該方法覆蓋為通過時返回false，未通過時返回true，這顯然會造成軟件邏輯上的錯誤。
接口隔離原則
使用多個專門的接口比使用單一的總接口要好。廢話，一個類做完全部事情，你受得了？
?迪米特法則
一個類與另一個類（或一個模塊與另一個模塊、一個軟件系統與另一個軟件系統）之間的通信要盡可能少，換句話說彼此了解得越少越安全（你知道得太多了J）
上述幾個原則即是面向對象開發時要注意的幾個基本原則，還有一些其它原則，本文不一一列舉。
有了這幾個原則作為面向對象開發軟件的衡量標準，可以多多測量自己所編寫代碼的水平。每當寫完一個方法、一個類、一個模塊時，不妨用上述幾個原則來考量一下。腦海中時常多問自己1個問題：當今后增加XX功能時，我現有的代碼要如何修改？如果你自己的答案是勿須修改現有的核心代碼（這些代碼可能是你冥思苦想、絞盡腦汁的心血），只須增加代碼，加點配置文件什么的，那恭喜你，你的程序具有很強的可擴展性。
如果你的答案是可能要改自己的核心代碼，那估計到時候就悲劇了，傳說中的牽一發而動全身就是說的你這種軟件。新功能一增加，bug到處亂竄，為了解決這一問題，你可能采取另一個辦法，就是不修改現有核心代碼，將這份代碼復制一份到另外一個地方，然后去修改復制出來的代碼，這樣一來，你就會陷入一個代碼泥潭，越陷越深最終不能自拔。
為了使自己編寫的軟件滿足面向對象的這些原則，我們在程序開發時，不妨使用管理的思維來編寫程序。
當你收到某一個功能需求時，在以前也許會直接聯想到該用哪些API來實現，該用幾個循環，什么條件下使用什么樣的if判斷等。如果你真是這樣想的，那么即使你是使用的java之類的面向對象語言，你編寫出的代碼仍然是面向過程的。也許你不自覺的就在一個方法中，用幾百行代碼實現了這個功能需求。其中，循環套循環、if嵌if，這樣的代碼也許你自己隔個三兩天來看，都不容易看懂，如果換一個人來維護這樣的代碼，估計要吐血。在這樣的代碼海洋中，如果在不起眼的角落里，有一個字符輸入錯誤，估計你會花很大的力氣才檢查得出來。
如果你用管理的思維來編寫程序，那就不一樣了。則在編寫代碼前，你會想象，實現這個功能需求，需要一系列的類，就好象要做一件事情，不是一個人去完成它，而是一個團隊去完成。這個團隊有自己的部門組織機構（package包），每個部門下面都有多個員工（class類）。各個部門有自己的職責（包的分類），各個員工也有自己的職責（抽象類或接口）。員工與員工之間如何溝通，部門與部門之間如何通信，這些都可以參考現實中大型企業的管理來實現。當你將這些部門和員工的職責設計好，相當于程序中的包和類以及類中的方法就設計好了，最后來實現這些方法，相信是游刃有余的了。在這種系統中，每個類的職責都很清晰，每個方法的代碼都不多，如果有某個字符輸入錯誤，會很容易的發現它。這也正是很多人推崇的一個方法只做一件事情的原因。
在使用管理的思維來編寫程序時，因為程序中的類的方法簽名會對應到管理體系中的員工職責，因此，要善于區分這些職責的重要性，將核心職責放在核心類中實現，業務職責放在業務類中實現。核心職責是系統中長期不變的（相對的長期），要放在抽象類中，業務職責根據業務的變化會相應的變化，因此要放在具體實現類中。區分核心和業務的目的是為了提高系統的穩定性，正是所謂的要善于區分變和不變的部分。
現在我們用管理的思維再來驗證一下面向對象的幾大原則！
開閉原則
當新功能需要增加時，相當于一個團隊有新的業務需要開展（這個新業務與老業務在性質上是一樣的，不會是完全不同的領域），現實中當然是新增一兩個業務員，或者新增一個業務部門即可，對團隊的核心組織架構當然不會有影響。
依賴倒轉原則
員工是具體類，員工的崗位職責是抽象類。一個員工需要與另外一個員工進行協作時，認定的當然是這個崗位，而不是具體某個人。比如：運營中心的銷售員需要向研發中心的程序員反饋客戶的需求，他只要找到研發中心任何一個具有程序員崗位職責的人都可以，而不是非要找到研發中心的張三，這就是依賴抽象（崗位職責），不依賴具體（張三）。
里氏代換原則
實施部在客戶倉庫實施項目，實施員甲生病了，要請假回家休息，這時，公司的實施員乙馬上奔赴現場，接替實施員甲的工作，保證項目按計劃進度完成，項目質量未受到任何影響。
以上場景可以看出，實施員甲和乙兩人都具有相同的崗位職責，因此，凡是實施員（基類）可以出現的地方，任何具體的實施員（具體類或者叫子類）都可以出現。
接口隔離原則
為什么一個管理良好的公司要分銷售部、研發部、財務部？這就是接口隔離原則，分工合作，正所謂因為專注，所以專業。當一個類什么事情都要負責，那這個類會很健壯嗎？
迪米特法則
銷售部問研發部，XX軟件在XX日期能否研發完？研發部說，我要先花XX天做什么什么工作，再花XX天做什么什么工作……銷售部煩了，我沒問你那么多，你只管說能還是不能就行了。
可以看出，上述對話中，研發部過多的暴露了內部的細節，不滿足迪米特法則。因此，系統與系統通信、模塊與模塊通信、類與類通信之間的接口數量以及暴露的信息，在滿足功能需要的前提下，越少越好。
說了這么多廢話，相信大家都有自己的認識。其實完全可以將生活中的各種經驗用在軟件開發中，軟件的靈感來自于生活，因為軟件的目的是為了生活更美好！