底線(設計原則)是始終追求高內聚、低耦合的編碼或設計。
Apache和Sun的開源代碼是學習和OOPS設計原則的好例子。
它們向我們展示了設計原則是如何在編程中使用的。
JDK使用了壹些設計原則:BorderFactory類中的工廠模式，運行時類中的單例模式和。io級。
順便說壹下，如果妳真的對編碼原理感興趣，請閱讀JoshuaBloch的Effective，他寫了壹個API。
關於面向對象設計模式我個人最喜歡的是KathySierra的HeadFirstDesignPattern，其他關於面向對象的分析和設計。
這些書對於編寫更好的代碼，充分利用各種面向對象的、堅實的設計模式有很大的幫助。
雖然學習設計模式(原則)最好的方法是使用真實的例子，了解違反設計原則帶來的不便，但本文的目的是向沒有接觸過或處於學習階段的程序員介紹面向對象的設計原則。
DRY _不要鉆牛角尖我們的第壹個面向對象設計原則是:DRY。從名字就可以看出，dry的意思是不寫重復的代碼，而是抽象成可重用的代碼塊。
如果妳有兩個以上相同的代碼塊，請考慮把它們抽象成壹個方法；或者多次使用硬編碼值，請設置為public * * *常量。
這種面向對象設計原則的優點是易於維護。
重要的是不要濫用這壹原則。重復不是為了代碼，而是為了函數。
這意味著，如果您使用通用代碼來驗證OrderID和SSN，這並不意味著它們是相同的，或者它們在未來將保持不變。
通過使用共同的代碼來實現兩個不同的功能，或者妳將這兩個不同的功能緊密地聯系起來；當您的訂單編號格式改變時，您的SSN驗證碼將被中斷。
所以要小心這種耦合，不要把彼此無關的相似代碼組合在壹起。
封裝頻繁修改的代碼EncapsulateWhatChanges在軟件領域永遠是“變化”的，所以封裝妳認為或者懷疑將來會被修改的代碼。
這種面向對象的設計模式的優點是易於測試和維護正確打包的代碼。
如果是用編程，請遵循以下原則:變量和方法的訪問權限默認設置為private，逐步釋放其訪問權限，如從“private”到“protected”和“notpublic”。
中的壹些設計模式。工廠設計模式(Factory design pattern)就是壹個例子，它封裝了創建對象的代碼，並提供了以下靈活性:後續生成新對象不會影響現有代碼。
開放/封閉設計原則類、方法/函數應該對擴展(新函數)開放，對修改關閉。
這是另壹個優雅可靠的設計原則，可以防止有人修改已經通過測試的代碼。
理想情況下，如果妳添加了新的特性，妳的代碼應該被測試，這是開/關設計原則的目標。
順便說壹下，SOLID中的字母“O”指的是開/關設計原理。
單壹責任原則單壹責任原則(SRP)是另壹個立體設計原則，立體中的字母“S”指的就是它。
根據SRP，壹個類應該只因為壹個原因而被修改，或者壹個類應該總是實現單壹的功能。
如果在壹個類中實現多個函數，這些函數之間存在耦合關系；如果修改其中壹個函數，可能會打破這種耦合關系，所以需要再進行壹輪測試，避免出現新的問題。
依賴註入/反轉原理不要問框架的依賴註入功能會給妳帶來什麽好處。依賴註入功能在spring框架中得到了很好的實現。這種設計原則的精妙之處在於，DI框架註入的任何類都易於用模擬對象進行測試，也更易於維護，因為創建對象的代碼集中在框架中，並與客戶端代碼隔離。
實現依賴註入的方法有很多，比如使用字節碼工具，還有壹些AOP(面向方面編程)框架比如spring中使用的切入點表達式或者代理。
要了解更多關於這個堅實的設計原則，請參閱IOC和DI設計模式中的例子。
SOLID中的字母“d”指的就是這個設計原則。
優先考慮結合而不是繼承。如果可能，優先考慮組合而不是繼承。
妳們中的壹些人可能會爭論這壹點，但是我發現組合比繼承更靈活。
組合允許在運行時通過設置屬性來修改類的行為，並利用多態性以接口的形式實現類之間的組合關系，為修改組合關系提供了靈活性。
甚至有效建議優先考慮組合而不是繼承。
根據Richter替換原理，父類出現的地方可以用子類替換，比如用子類替換父類的方法或函數應該沒有問題。
LSP與單壹責任原則和接口隔離密切相關。
如果壹個父類的功能比它的子類多，它可能不支持這個功能，這也違背了LSP設計原則。
為了遵循LSPSOLID設計原則，派生類或子類(與父類相比)必須增強它們的功能，而不是減少它們的功能。
實線中的字母“L”指的是LSP設計原理。
接口隔離原則接口隔離原則是指如果妳不需要壹個接口的功能，就不要實現它。
這種情況多發生在以下幾種情況:壹個接口包含多個函數，實現類只需要其中壹個。
接口設計是壹項棘手的工作，因為壹旦接口發布，妳就不能修改它，否則會影響實現它的類。
這種設計原則的另壹個好處是接口有壹個特點，任何壹個類在使用它之前都必須實現接口的所有方法，所以使用單壹功能的接口意味著實現更少的方法。
編程以接口為中心(而不是實現對象)。編程總是以接口(而不是實現對象)為中心，這將使代碼結構靈活，並且任何新的接口實現對象都與現有的代碼結構兼容。
因此，在中，請使用變量、方法返回值和方法參數的數據類型的接口。
這是很多程序員的建議，也是Effective、headfirstdesignpattern等書的建議。
代理的原理是不期望壹個類完成所有的功能，計算機訓練/思考壹些功能可以適當的交給代理類來實現。
代理原則的模型是。
為了比較兩個對象的內容是否相同，我們讓用於比較的類自己完成比較工作，而不是它們的調用方。
這種設計原則的優點是沒有重復編碼，並且很容易修改類的行為。