設計模式前傳---UML圖和六大設計原則

    聲明：文章內容根據大牛博客的內容，自己理解後，給自己做的學習筆記，文末會附上大牛博客地址鏈接。有需要溝通交流的可加我QQ羣：425120333
    正所謂，磨刀不誤砍柴工。只有準備充分了，做事才能事半功倍。學習也是同樣的道理，我第一次學習設計模式的時候，純粹是看着視頻學着敲
看的時候，理解了一點點簡單的，但是總的都是過一遍，只是看的當時，懂了。對是看懂了，至於後面的掌握和會用，差了十萬八千行代碼。
    在這裏提個建議，如果要學習新的知識（僅針對Java編程方面），動手是相當關鍵的，只有理解了並且能自己能動手寫下來，你才能算是看懂了。
雖然當時學習設計模式時我也這樣做了，我看懂了，可是過了幾天，我就忘了差不多了，除了其中有幾個特別簡單的還有點印象。時隔大半年，我再次來學習設計模式，
我發現了兩點：一、當時學習時連一些基本概念都沒搞清楚，就像不會加減，就直接去學乘除了。二、當時的自己代碼量還太少，寫代碼沒什麼感覺。
這兩點都很重要，就設計模式來說，連六大設計原則和UML圖都不知道是什麼，去看設計模式，真的算是沒學會走，就先學着飛了。還有代碼量，雖然代碼量不能作爲
衡量一個人水平的標準，不過在水平低時，還是很看重代碼量的（要養成好習慣，不要複製黏貼，每一行，每個單詞都是用鍵盤敲出來），只有保證了代碼量，才能談代碼質量。
    這兩點中，代碼量純靠積累，別人誰都幫不了。這裏談談UML圖，關於這圖你參考下這個鏈接http://blog.csdn.net/suxinpingtao51/article/details/8011335 
看完這個你對UML圖中每條線什麼意思應該都明白了，這也就差不多了（當然也可以繼續深入）。
    接下來理一理六大設計原則，首先是單一職責原則，這個好理解，就是保證每個類都只幹一件事。通俗的將你不要將多個功能混合在一起，
比如中國的筷子，就包含了多個功能。而外國就分爲了刀和叉，兩個工具分工明確。（這裏不是吐槽筷子不好，只是就單一職責原則而言，違反了）不過
單一職責難做的點是職責不好劃分，每個人心中對職責的定義也不一樣，所以這個原則也不是絕對的。
    接着是里氏替換原則，這個原則是對繼承來說的，就是用父類的地方同樣能用子類代替，說的直白點就是子類繼承父類時不要重寫父類中已有的方法。
這樣就能保證不違反里氏替換原則了，否則在某一模塊用了父類的方法，現在改爲用子類中的同樣的方法替換時，因爲子類重寫了，使得整體邏輯變了。
    第三個要講的是接口隔離原則（最小接口原則），這個和單一職責有些類似，就是在定義接口時，接口中的方法要儘量少，要擴展時通過接口間的繼承
來實現。最好的辦法就是每個接口都只有一個方法（理想情況），這樣新的接口要什麼功能就去繼承相應的接口就行。
    第四個是依賴倒置原則，用定義去理解有點難懂（定義可以百度），我的理解就是面向抽象（接口、抽象類）編程，對象聲明的時候聲明爲父類類型，
後面要變動，也只需要變動相應的子類即可，其他都可以不用變。
    第五個是迪米特原則（最小知道原則），指的是一個類暴露給其他類的信息不要太多（要求封裝，使用private關鍵字），同時這個類也儘量不要使用
其他類中的信息（方法、屬性等）。這樣一來，每個類自身的變動，對其他類的影響就大大的降低了。
    最後一個要將的開閉原則，對擴展開發，對修改封閉。就按字面來了解即可。如果能儘量滿足前面五條原則，開閉原則基本也會滿足。
    六大設計原則是我們開發代碼中應該儘量遵守的原則，當然存在很多情況我們不得不違反一些原則，這時需要考慮違反帶來的效益，權衡利弊。
最終決定方案，畢竟設計的再好也要貼合實際，滿足需求是前提原則。最後貼一句很有意義的話：用抽象搭建框架，用細節實現擴展。（來自大話設計模式）
    上述都是自己對自己的歸納總結，估計也就自己能看明白，附大牛對六大設計模式講解鏈接：http://www.cnblogs.com/zuoxiaolong/p/pattern1.html