面向對象設計原則是OOPS編程的核心，學習面向對象編程像“抽象”、“封裝”、“多態”、“繼承”等基礎知識是重要的，但同時為了創建簡潔、模塊化的設計，了解這些設計原則也同等重要。
(設計原則)底線是永遠追求高內聚、低耦合的編碼或設計。Apache和Sun的開源代碼是學習和OOPS設計原則的良好範例。它們向我們展示了，設計原則在編程中是如何使用的。JDK使用了壹些設計原則：BorderFactory類中的工廠模式、Runtime類中的單例模式、.io類中的裝飾器模式。順便說壹句，如果您真的對編碼原則感興趣，請閱讀JoshuaBloch的Effective，他編寫過API。我個人最喜歡的關於面向對象設計模式的是KathySierra的HeadFirstDesignPattern(深入淺出設計模式)，以及其它的關於深入淺出面向對象分析和設計。這些書對編寫更好的代碼有很大幫助，充分利用各種面向對象和SOLID的設計模式。
雖然學習設計模式(原則)最好的方法是現實中的例子和理解違反設計原則帶來的不便，本文的宗旨是向那些沒有接觸過或正處於學習階段的程序員介紹面向對象設計原則。
DRY_Don’trepeatyourself
我們第壹個面向對象設計原則是：DRY，從名稱可以看出DRY(don’trepeatyourself)意思是不寫重復代碼，而是抽象成可復用的代碼塊。如果您有兩處以上相同的代碼塊，請考慮把它們抽象成壹個單獨的方法；或者您多次使用了硬編碼的值，請把它們設置成公***常量。這種面向對象設計原則的優點是易於維護。重要的是不要濫用此原則，重復不是針對代碼而是針對功能來說。它的意思是，如果您使用通用代碼來驗證OrderID和SSN，這並不意味著它們是相同的或者他們今後將保持不變。通過把通用代碼用於實現兩種不同的功能，或者您把這兩種不同的功能密切地聯系在壹起；當您的OrderID格式改變時，您的SSN驗證代碼將會中斷。所以要當心這種耦合，而且不要把彼此之間沒有任何關系卻類似的代碼組合在壹起。
封裝經常修改的代碼
EncapsulateWhatChanges
在軟件領域永遠不變的是“變化”，所以把您認為或懷疑將來要被修改的代碼封裝起來。這種面向對象設計模式的優點是：易於測試和維護恰當封裝的代碼。如果您在用編程，那麽請遵守以下原則：變量和方法的訪問權限默認設置為私有，並且逐步放開它們的訪問權限，例如從“private”到“protected”、“notpublic”。中的壹些設計模式使用了封裝，工廠設計模式就是壹個例子，它封裝了創建對象的代碼而且提供了以下靈活性：後續生成新對象不影響現有的代碼。
打開/關閉設計原則
OpenClosedDesignPrinciple
類、方法/函數應當是對擴展(新功能)開放，對修改閉合。這是另外壹個優雅的SOLID設計原則，以防止有人修改通過測試的代碼。理想情況下假如您添加了新功能，那麽您的代碼要經過測試，這就是打開/關閉設計原則的目標。順便說壹句，SOLID中的字母“O”指的是打開/關閉設計原則。
單壹職責原則
SingleResponsibilityPrinciple(SRP)
單壹職責原則是另外壹個SOLID設計原則，SOLID中的字母“S”指的就是它。按照SRP，壹個類修改的原因應當有且只有壹個，或者壹個類應當總是實現單壹功能。如果您在中的壹個類實現了多個功能，那麽這些功能之間便產生了耦合關系；如果您修改其中的壹個功能，您有可能就打破了這種耦合關系，那麽就要進行另壹輪測試以避免產生新的問題。
依賴註入/反轉原則
DependencyInjectionorInversionprinciple
不要問框架的依賴註入功能將會給妳帶來什麽益處，依賴註入功能在spring框架裏已經很好的得到了實現，這壹設計原則的優雅之處在於：DI框架註入的任何壹個類都易於用模擬對象進行測試，並且更易於維護，因為創建對象的代碼在框架裏是集中的而且和客戶端代碼是隔離的。有多種方法可以實現依賴註入，例如使用字節碼工具，其中壹些AOP(面向切面編程)框架如切入點表達式或者spring裏使用的代理。想對這種SOLID設計原則了解更多，請看IOC和DI設計模式中的例子。SOLID中的字母“D”指的就是這種設計原則。
優先使用組合而非繼承
ForCompositionoverInheritance
如果可以的話，要優先使用組合而非繼承。妳們中的壹些人可能為此爭論，但我發現組合比繼承更有靈活性。組合允許在運行時通過設置屬性修改壹個類的行為，通過使用多態即以接口的形式實現類之間的組合關系，並且為修改組合關系提供了靈活性。甚至Effective也建議優先使用組合而非繼承。
裏氏替換原則
LiskovSubstitutionPrincipleLSP
根據裏氏替換原則，父類出現的地方可以用子類來替換，例如父類的方法或函數被子類對象替換應該沒有任何問題。LSP和單壹職責原則、接口隔離原則密切相關。如果壹個父類的功能比其子類還要多，那麽它可能不支持這壹功能，而且也違反了LSP設計原則。為了遵循LSPSOLID設計原則，派生類或子類(相對父類比較)必須增強功能，而非減少。SOLID中的字母“L”指的就是LSP設計原則。
接口隔離原則
接口隔離原則指，如果不需要壹個接口的功能，那麽就不要實現此接口。這大多在以下情況發生：壹個接口包含多種功能，而實現類只需要其中壹種功能。接口設計是壹種棘手的工作，因為壹旦發布了接口，您就不能修改它否則會影響實現該接口的類。在中這種設計原則的另壹個好處是：接口有壹個特點，任何類使用它之前都要實現該接口所有的方法，所以使用功能單壹的接口意味著實現更少的方法。
編程以接口(而非實現對象)為中心
編程總是以接口(而非實現對象)為中心，這會使代碼的結構靈活，而且任何壹個新的接口實現對象都能兼容現有代碼結構。所以在中，變量、方法返回值、方法參數的數據類型請使用接口。這是許多程序員的建議，Effective以及headfirstdesignpattern等書也這樣建議。
代理原則
不要期望壹個類完成所有的功能，電腦培訓認為可以適當地把壹些功能交給代理類實現。代理原則的典範是：中的equals()和hashCode()方法。為了比較兩個對象的內容是否相同，我們讓用於比較的類本身完成對比工作而非它們的調用方。這種設計原則的好處是：沒有重復編碼而且很容易修改類的行為。