a、物件導向的五大基本原則（object-oriented design）
1.單一職責原則（single responsibility principle）：每乙個類應該只專注於做一件事。
?乙個類應該僅有乙個引起它變化的原因(最簡單，最容易理解卻最不容易做到的乙個設計原則)
職員類例子：
比如在職員類裡，將工程師、銷售人員、銷售經理這些情況都放在職員類裡考慮，其結果將會非常混亂，在這個假設下，職員類裡的每個方法都要if else判斷是哪種情況，從類結構上來說將會十分臃腫，並且上述三種的職員型別，不論哪一種發生需求變化，都會改變職員類！這個是大家所不願意看到的！
2.開閉原則（open-closed principle）：software entities should be open for extension,but closed for modification
?既開放又封閉，對擴充套件是開放的，對更改是封閉的！即「在不被修改的前提下被擴充套件」。
?擴充套件即擴充套件現行的模組，當我們軟體的實際應用發生改變時，出現新的需求，就需要我們對模組進行擴充套件，使其能夠滿足新的需求！
更改封閉即是在我們對模組進行擴充套件時，勿需對源有程式**和dll進行修改或重新編譯檔案！
這個原則對我們在設計類的時候很有幫助，堅持這個原則就必須盡量考慮介面封裝，抽象機制和多型技術！
3.黎克特制替換原則（liskov substitution principle）：任何基類可以出現的地方，子類一定也可以出現。itool tool = new knife();
?子類可以替換父類並且出現在父類能夠出現的任何地方
?這個原則也是在貫徹gof倡導的面向介面程式設計！在這個原則中父類應盡可能使用介面或者抽象類來實現！
子類通過實現了父類介面，能夠替父類的使用地方！通過這個原則，我們客戶端在使用父類介面的時候，通過子類實現！意思就是說我們依賴父類介面，在客戶端宣告乙個父類介面，通過其子類來實現，這個時候就要求子類必須能夠替換父類所出現的任何地方，這樣做的好處就是，在根據新要求擴充套件父類介面的新子類的時候而不影響當前客戶端的使用！
4.依賴倒轉原則（dependency inversion principle）：要依賴於抽象，不要依賴於實現。knife knife = new knife();knife.slice(); ==> itool tool = new knife();tool.slice();
?傳統的結構化程式設計中，最上層的模組通常都要依賴下面的子模組來實現，也稱為高層依賴低層！
所以dip原則就是要逆轉這種依賴關係，讓高層模組不要依賴低層模組，所以稱之為依賴倒置原則！
5.介面隔離原則（inte***ce segregation principle）：
?這個原則的意思是：使用多個專門的介面比使用單個介面要好的多！
這個我有體會，在我實際程式設計中，為了減少介面的定義，將許多類似的方法都放在乙個介面中，最後發現，維護和實現介面的時候花了太多精力，而介面所定義的操作相當於對客戶端的一種承諾，這種承諾當然是越少越好，越精練越好，過多的承諾帶來的就是你的大量精力和時間去維護！
b、物件導向三大原則：
1．物件導向設計的第一原則：封裝變化點。隔離變化點的好處在於，將系統中經常變化的部分和穩定的部分隔離，有助於增加復用性，並降低系統耦合度。很多設計模式的意圖中都明顯地指出了其對問題的解決方案，學習設計模式的要點是發現其解決方案中封裝的變化點。
2．物件導向設計的第二原則：對介面進行程式設計。這裡「介面」的含義表示的程式語言中的inte***ce ,或者abstract class。對介面程式設計的乙個好處在於客戶端程式並不需要了解具體的實現，而只需要了解介面中宣告的方法。更大的好處在於能夠使用多型性執行動態性的行為。
program to an inte***ce,not an implementation
3．物件導向設計的第三原則：多使用組合，而不是繼承。has-a關係要比is-a關係更好：因為繼承是靜態行為，也就是編譯時行為，這種設計缺乏靈活度，並且具有比組合更高的耦合度；而組合是動態行為，即執行時行為。可以通過使用組合的方式在設計上獲得更高的靈活性。gof設計模式中將設計模式分為物件設計模式和類設計模式，其中物件設計模式居多，原因就在於物件設計模式多使用組合，通過此獲得更好的靈活性。
合成/聚合復用原則（composition/aggregation principle）：要盡量使用合成/聚合，而不是繼承關係達到復用的目的。
迪公尺特法則（law of demeter）：應當為客戶端提供盡可能小的單獨的介面，而不要提供大的總介面。
c、介面與類
抽象類是用來繼承的
具體類是用來實現的，不是用來繼承的
介面僅僅給出方法的特徵，而不給出方法的實現，介面比抽象類更加抽象化
因此，介面把方法的特徵和方法的實現分割開來：介面常常代表乙個角色（role），而實現這個介面的類便是扮演這個角色的演員。乙個角色可以由不同的演員來演，而不同的演員之間除了扮演乙個共同的角色之外，並不要求有任何其他的共同之處。
class:inte***ce 實現繼承(implenmentation inheritance)
class:class 擴充套件繼承(extends inheritance)
在乙個類等級結構中的任何一類都可以實現乙個介面，這個介面會影響到此類的所有子類，但是不會影響到此類的任何超類。此類將不得不實現這個介面所規定的方法，而其子類則可以從此類自動繼承到這些方法，當然也可以選擇置換掉所有的這些方法，或者其中的某一些方法。
e、gof設計模式
建立型¤1、系統架構技能之設計模式-單例模式
¤2、系統架構技能之設計模式-工廠模式
3、系統架構技能之設計模式-抽象工廠模式
4、系統架構技能之設計模式-建立者模式
5、系統架構技能之設計模式-原型模式
結構型1、系統架構技能之設計模式-組合模式
2、系統架構技能之設計模式-外觀模式
3、系統架構技能之設計模式-介面卡模式
¤4、系統架構技能之設計模式-橋模式
5、系統架構技能之設計模式-裝飾模式
¤6、系統架構技能之設計模式-享元模式
7、系統架構技能之設計模式-**模式
行為型1、系統架構技能之設計模式-命令模式
¤2、系統架構技能之設計模式-觀察者模式
¤3、系統架構技能之設計模式-策略模式
4、系統架構技能之設計模式-職責模式
5、系統架構技能之設計模式-模板模式
6、系統架構技能之設計模式-中介者模式
7、系統架構技能之設計模式-直譯器模式
--型¤迭代器模式
設計模式開篇
1 什麼是設計模式？設計模式是一套被反覆使用 多人知曉 分類編目 設計經驗的總結。使用設計模式是為了可重用 保證 的可靠性，使 編制真正的工程化，能夠適應需求的變化。實現 功能的復用 1 繼承機制 uml中體現為泛化 2 組合 聚合 也可以是導航 3 多型，父類型別可以執行任何子類物件 4 類是對物...
設計模式 開篇
什麼是設計模式？一說起設計模式，可能很多人都覺得很高大上的感覺，事實上，設計模式只是針對某一類問題的最佳解決方案而已，設計模式是由許多優秀的軟體系統中總結出來的可成功復用的設計方案。我們常說的23種設計模式來自 設計模式 一書，也就是我們常說的gof。模式分類 1.建立型模式 建立型模式涉及物件的例...
設計模式開篇
提到設計模式，我們會經常這樣聽說 我也看過很多的設計模式，但在實際的專案中從來沒有用過 這的確是我以及很多人遇到的情況，那些設計模式都能看懂，但就是在專案用不到，總感覺紙上談兵，落實不到我們具體的專案上。我的個人觀點 1 對設計模式的理解還不夠深入 首先我們要對設計模式所要解決的問題要理解透徹，即什...