前言:html
我學習設計模式主要根據http://blog.csdn.net/lovelion/article/details/17517213 來學習的 太牛了 。夠我玩好幾年吧 哈哈哈哈哈!!!設計模式解決的問題是:設計模式用於在特定的條件下爲一些重複出現的軟件設計問題提供合理的、有效的解決方案。數據庫
結合來看吧,從招式與內功談起——設計模式概述(一) :模式:是在特定環境下人們解決某類重複出現問題的一套成功或有效的解決方案。【A pattern is a successful or efficient solution to a recurring problem within a context】。由"四人組"簡稱GOF 將模式引入軟件工程方面。標誌着軟件模式的誕生--軟件模式並不是僅限於設計模式,還包括架構模式、分析模式和過程模式等,實際上,在軟件開發生命週期的每個階段都存在着一些被認同的模式。編程
軟件模式的基礎結構主要由四部分構成,包括問題描述【待解決的問題是什麼】、前提條件【在何種環境或約束條件下使用】、解法【如何解決】和效果【有哪些優缺點】 設計模式
從招式與內功談起——設計模式概述(二):設計模式可分爲建立型(Creational),結構型(Structural)和行爲型(Behavioral)三種,其中創建型模式主要用於描述如何建立對象,結構型模式主要用於描述如何實現類或對象的組合,行爲型模式主要用於描述類或對象怎樣交互以及怎樣分配職責 。架構
23種設計模式中包含5種建立型設計模式、7種結構型設計模式和11種行爲型設計模式。設計模式還能夠分爲類模式和對象模式。學習
此外,還有個簡單工廠模式 沒有列入23種設計模式裏,但它屬於設計模式。spa
表1 經常使用設計模式一覽表(我要改了哈哈先學幾個慢慢來).net
類型設計 |
模式名稱代理 |
學習難度 |
使用頻率 |
建立型模式 Creational Pattern |
單例模式 Singleton Pattern |
★☆☆☆☆ |
★★★★☆ |
簡單工廠模式 Simple Factory Pattern |
★★☆☆☆ |
★★★☆☆ |
|
工廠方法模式 Factory Method Pattern |
★★☆☆☆ |
★★★★★ |
|
抽象工廠模式 Abstract Factory Pattern |
★★★★☆ |
★★★★★ |
|
原型模式 Prototype Pattern |
★★★☆☆ |
★★★☆☆ |
|
|
|||
結構型模式(都不知道) Structural Pattern |
適配器模式 Adapter Pattern |
★★☆☆☆ |
★★★★☆ |
橋接模式 Bridge Pattern |
★★★☆☆ |
★★★☆☆ |
|
組合模式 Composite Pattern |
★★★☆☆ |
★★★★☆ |
|
裝飾模式 Decorator Pattern |
★★★☆☆ |
★★★☆☆ |
|
外觀模式 Façade Pattern |
★☆☆☆☆ |
★★★★★ |
|
享元模式 Flyweight Pattern |
★★★★☆ |
★☆☆☆☆ |
|
代理模式 Proxy Pattern |
★★★☆☆ |
★★★★☆ |
|
行爲型模式 Behavioral Pattern |
職責鏈模式 Chain of Responsibility Pattern |
★★★☆☆ |
★★☆☆☆ |
命令模式 Command Pattern |
★★★☆☆ |
★★★★☆ |
|
解釋器模式 Interpreter Pattern |
★★★★★ |
★☆☆☆☆ |
|
迭代器模式 Iterator Pattern |
★★★☆☆ |
★★★★★ |
|
中介者模式 Mediator Pattern |
★★★☆☆ |
★★☆☆☆ |
|
備忘錄模式 Memento Pattern |
★★☆☆☆ |
★★☆☆☆ |
|
觀察者模式 Observer Pattern |
★★★☆☆ |
★★★★★ |
|
狀態模式 State Pattern |
★★★☆☆ |
★★★☆☆ |
|
策略模式 Strategy Pattern |
★☆☆☆☆ |
★★★★☆ |
|
模板方法模式 Template Method Pattern |
★★☆☆☆ |
★★★☆☆ |
|
訪問者模式 Visitor Pattern |
★★★★☆ |
★☆☆☆☆ |
從招式與內功談起——設計模式概述(三):做者的學習心得吧,學習設計模式應該理解,這個設計模式的意圖,解決什麼問題,何時用;它是如何解決的,掌握它的結構圖,記住它的關鍵代碼;可以想到至少兩個它的應用實例,一個生活中的,一個軟件中的;這個模式的優缺點是什麼,在使用時要注意什麼。當你可以回答上述全部問題時,恭喜你,你瞭解一個設計模式了,至於掌握它,那就在開發中去使用吧,用多了你天然就掌握了。對模式的學習不要急於求成!!!!!開閉原則是目標,里氏代換原則是基礎,依賴倒轉原則是手段
面向對象設計原則概述:原則:如何同時提升一個軟件系統的可維護性和可複用性是面向對象設計須要解決的核心問題之一。
最多見的7種面向對象設計原則(我還不太理解哈哈先了解下 我有添加連接之後看)
面向對象設計原則之單一職責原則:定義:一個類只實現一個功能領域的相關職責,拿做者的例子來說,本來一個類要實現 數據庫連接、數據則刪改查、和圖表生成等。如今分爲三個類實現。單獨實現這些功能,以達到高內聚,低耦合的目的。
面向對象設計原則之開閉原則:定義:一個軟件實體應當對擴展開放,對修改關閉。即軟件實體應儘可能在不修改原有代碼的狀況下進行擴展。抽象化是實現開閉原則的重因素。看這個須要理解抽象類和接口的區別(抽象方法是必須實現的方法,在實際應用中他們仍是有必定的差異,
抽象類一般做爲公共的父類爲子類的的擴展作基礎。這裏擴展包括屬性上或行爲上)
接口是通常不考慮屬性,只考慮方法子類能夠自由的填補或擴展接口的方法。偏重於行爲。許多狀況下接口是能夠代替抽象類的 (若是你不須要刻意表達屬性上的繼承的話)
接口是公開的裏面不能有私有的方法或變量,是用於讓別人使用的,而抽象類是能夠有私有方法或私有變量的
接口能夠實現多重繼承,而一個類只能繼承一個父類。。。。。。就說到這吧,要跑題了。。。。具體詳解
面向對象設計原則之里氏代換原則:定義:全部引用基類(父類)的地方必須能透明地使用其子類的對象。我看例子明白 感受和開閉原則很類似,在程序中儘可能使用基類類型來對對象進行定義,而在運行時再肯定其子類類型,用子類對象來替換父類對象(不太明白)。
面向對象設計原則之依賴倒轉原則: 定義:抽象不該該依賴於細節,細節應當依賴於抽象。換言之,要針對接口編程,而不是針對實現編程。就是變量、參數、方法返回、數據類型轉換等都要用抽象定義聲明,再經過依賴注入(構造注入、設值注入和接口注入)的方式將具體對象注入到有依賴關係的對象中。我其實不太明白 。。。但有了基本瞭解。就是不具體定義 聲明 等、抽象化實現。下篇見。