前言
因為這些筆記是很久以前自己做的記錄，主要是給自己看的，所以內容很簡單，也相信有一定程式設計經驗的人，看到這些說明也了解是什麼意思，可以做為一個簡單的回憶。
同時，因為當初在理解設計模式時碰到了很大的困難，所以我在底下也給一些如何理解設計模式的建議。
六大設計原則
每個類應該只具備單一功能。
任何父類出現的地方，應該都可以用子類取代。
要依賴於抽象，不要依賴於具體實現。
不應該強迫程式依賴他們不需使用的方法。
一個對象應當對其他對象盡可能的少了解。
類的改動是通過增加代碼進行的，而不是改動現有的代碼。
如何理解設計模式？
菜鳥的做法
今天假設你在一家公司工作，和A公司的簽約，A公司的DB採用orcale，於是你開發了一套專用的資料庫連線程式，那程式碼大概會長這樣：
OrcaleConn conn = new OrcaleConn();
結果後來A公司改需求，說orcale太貴了，我們希望改用mysql，這時你發覺慘了，上面所有用OracleConn連線的程式都要改，根本改不完。
老鳥的做法
而一個有經驗的設計師會怎麼做呢？他會設計一個界面IDBConn，然後讓OrcaleConn繼承IDBConn，如下：
IDBConn conn = DBConnFactory.getConn("conn");
其中DBConnFactory，他會去讀取設定檔，而設定檔的內容設定就是去鏈接Orcaleconn：
conn=OrcaleConn
當我們需要改成用mysql連線的時候，只需要再設計一個MysqlConn繼承IDBConn,然後更改設定檔：
conn=MysqlConn
我們發覺一切就大工告成了，原本的程式碼一行都沒改，就改了一個設定檔，有沒有很輕鬆！
給新鮮人的建議：
因此，也不要把設計模式當成什麼了不起的東西，看不懂也別氣餒，畢竟學生做專題，跟實際生產環境是有很大差別的，不容易發生程式改一半，客戶要換資料庫或等等其他需要改需求的問題。
所以也建議沒有實務經驗的學生，如果在閱讀設計模式的過程中，實在覺得設計模式太難理解，可以先緩緩，累計一點工作經驗，回來看就輕鬆了。
因為很多文章是過往自己搜集的資料、圖片，如有侵權疑慮請告知，將立即下架刪除。
