您的star是我不斷前行的動力
前言：物件導向設計的目標在於支援可維護性復用：
一方面需要實現設計方案和源**的復用，
另一方面要確保系統易於擴充套件和修改，具有良好的可維護性。
一：經常用到的設計原則
使用頻率
單一職責原則 ****
開閉原則 *****
黎克特制代換原則 *****
依賴倒轉原則 *****
介面隔離原則 **
合成復用原則 ***
一：單一職責原則(用於控制類的粒度大小)
定義:乙個物件應該只包含單一的職責，並且該職責被完整的封裝在乙個類中。
例如:圖表統計模組
customerdatachart類 (封裝了如下的行為)
getconnection():connection //用於連線資料庫
findcustomers():list //用於查詢所有的客戶資訊
createchart():void //用於建立圖表
displaychart():void //用於顯示圖表
以上的問題:
customerdatachart類承擔了太多的職責
1.既包含與資料庫相關的方法
2.又包含與圖表顯示相關的方法
解決問題:
將customerdatachart類拆分成三個類
1.dbutil:負責連線資料庫，包含資料庫連線方法,getconnetcion().
2.customerdao:負責運算元據庫中的customer表，包含對customer表的增刪改查，例如findcustomers().
3.customerdatachart:負責圖表的生成和顯示，包含方法createchart()和displaychart().
二:開閉原則(需要做到不修改原來**的基礎上擴充套件系統的功能)
定義：軟體實體對擴充套件開放，對修改關閉。
重點：1.為了滿足開閉原則，需要對系統進行抽象化的設計，抽象化是開閉原則的
關鍵。2.可以為系統定義乙個相對穩定的抽象層，而將不同的額實現行為移至具體 的實現層中完成。
3.可以通過介面、抽象類等機制來定義系統的抽象
4.如果想修改系統的行為，無須對系統的抽象層進行任何的修改,只需要增加
新的具體類來實現新的業務，實現再不修改已有的**的基礎上擴充套件系統的功能。
三:黎克特制代換原則(即執行時基類呼叫子類實現的方法)
定義:所有引用基類的地方必須能透明地使用其子類的物件
重點:1.應該將父類設計成抽象類或介面，讓子類繼承父類或實現父類介面，並實現父類中宣告的方法。執行時，子類例項替換父類例項，可以很方便的擴充套件系統的功能，無須修改原有子類的**，增加新的功能可以通過增加新的子類來實現。
四:依賴倒轉原則(要針對介面程式設計，不要針對實現程式設計)
定義:高層模組不應該依賴底層模組，他們都應該依賴抽象。抽象不應該依賴於細
節，細節應該依賴於抽象。
重點:1.使用介面和抽象類進行變數型別宣告，引數型別宣告，方法返回型別宣告 ，以及資料型別的轉換等，而不要用具體類來做這些事情。
2.在實現依賴倒轉原則時，需要針對抽象層進行程式設計，而將具體類的物件通 過依賴注入的方式注入到其他物件中。
3.依賴注入是指，乙個物件要與其他物件發生依賴時，通過方法引數來注入 所依賴的物件。常用的方法有三種(構造注入，設值注入和介面注入)。
4.這些方法在定義時使用的抽象型別，在執行時再傳入具體的物件，由子類
物件來覆蓋父類物件。
五:介面隔離原則
定義:客戶端不應該依賴那些它不需要的介面
重點:1.根據介面隔離原則，當乙個介面太大時，需要將它分割成一些更細小的接 口，使用該介面的客戶端需要知道與之相關的介面即可。
六:合成復用原則(要盡量使用組合/聚合關係，少用繼承)
定義:優先使用物件組合，而不是繼承來達到復用的目的。
重點:1.一些已有的物件，使之成為新物件的一部分，新物件通過委派呼叫已有物件的方法達到復用的目的。
例如:在設計資料庫連線操作的時候可以基於以下設計。
元件為customerdao、dbutil、oracledbutil、mysqldbutil
元件介紹:
1.customerdao:依賴dbutil類，用於資料庫的操作
2.dbutil:可以是抽象類，或介面，或具體類，用於獲取不同資料庫連線
3.oracledbutil：實現或繼承dbutil類，用於獲取oracle資料庫的連線。
4.mysqldbutil:實現或繼承dbutil類，用於獲取mysql資料庫的連線。
這樣，如果需要其他資料庫的連線操作，只需要繼承或實現dbutil類即可，達到了可擴充套件性。
總結:1.依賴注入可通過構造注入，設值注入和介面注入實現
2.設計模式無非是為了考慮設計的可擴充套件性和可維護性，
主要需要考慮到可變的部分,
例如在不需要修改原有**的情況下，通過繼承、實現等方式來增加新的功能，達到可擴充套件性，
例如通過元件(類或行為)的單一職責，達到元件的可維護性
例如通過合成復用原則，達到元件的復用，提高系統的靈活性
...設計模式的思想:
1.多用介面和抽象程式設計
2.單一職責
3.多用組合/聚合，少用繼承
4.功能拆分
架構篇 URI設計原則
author simon 優雅型 羅浮宮 達文西 蒙娜麗莎 中庸型 北京 新聞頻道 新聞id 謝特型 斜槓分隔符 必須用於顯示層次關係正例 反例 使用 提高uri的可讀性正例 禁止在url中使用 目的是提高可讀性，可能被文字檢視器中的下劃線特效遮蔽 反例 禁止使用大寫字母rfc 3986中規定uri...
設計模式 常用的設計原則
1 單一職責原則 就乙個類而言，應該僅有乙個引起它變化的原因。說明 單一職責是一種必需的思想，即職責相互分離。如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當發生變化時，設計會遭受到意想不到的破壞。軟體設計真...
精華篇 改變 明確時限
在完成工作的過程中，時間因素與質量因素同等重要。必須在規定的時間內完成規定的任務。即便沒有人對你完成工作的時間提出要求，那麼你也應當主動提出。無論是學校，還是人生，都不會給你這多出來的10分鐘。乙個精心制定 結構合理的完整計畫 詳細的列出所有任務 是節約時間的有力保證。應該用最合理的時間完成每一項工...