1.設計模式之初體驗—精讀《JavaScript 設計模式》Addy Osmani著
同系列友情連接:
原始模式(proto-pattern):一種還沒有經過「模式」測試的設計模式;
優秀的模式:若是模式能夠執行如下操做,就被認爲是優秀的模式:
- 解決特殊問題。模式不該該只是獲取原則或策略,它們須要獲取解決方案。這隻做爲一種優秀模式不可或缺的要素。
- 沒有顯而易見的解決方案。咱們會發現,解決問題的技術基原本自衆所周知的基本原則。最好的設計模式一般會間接提供解決問題的方案——這被認爲是解決與設計相關的最具挑戰性問題的必要方法。
- 描述業經驗證的概念。設計模式須要證實它們的做用與描述相一致,而且若是沒有證實這一點,就不能認真考慮該設計。若是一種模式其實是推測出來的,那麼只有那些勇敢的人才可能嘗試它。
- 描述一種關係。在某些狀況下,看起來多是一種模式描述了一種類型的模塊。儘管一種實現看起來也是這樣,但對模式的正式描述必須可以更深刻的理解它與代碼關係的系統結構和機制。
反模式:描述一種針對於某種特定問題的不良解決方案,該方案會致使糟糕的狀況發生;描述如何擺脫前述的糟糕狀況以及如何創造好的解決方案。
JavaScript 中的反模式:
- 在全局上下文中定義大量的變量污染全局命名空間;
- 向 setTimeout 或 setInterval 傳遞字符串,而不是函數,這會觸發 eval ( ) 的內部使用;
- 修改 Object類的原型(這是一個特別不良的反模式);
- 之內斂的形式使用 JavaScript,它是不可改變的;
- 在使用document.createElement 等原生DOM 方法更適合的狀況下使用 document.write。多年以來document.write一直都是在被嚴重濫用,並有至關多的缺點,包括:若是在頁面加載完成後執行document.write,它實際上會重寫咱們所在的頁面,而document.createElement則不會。訪問此網站能夠看到它運行的實例。document.write也沒法與XHTML相適,這是選擇像document.createElement這樣更爲DOM友好的方法比較有利的另外一個緣由。
設計模式的類別:
建立型設計模式:專一於處理對象建立機制,以適合給定狀況的方式來建立對象。建立對象的基本方法可能致使項目複雜性增長,而這些模式旨在經過控制建立過程來解決這種問題。
- Constructor(構造器)
- Factory(工廠)
- Abstract(抽象)
- Prototype(原型)
- Singleton(單例)
- Builder(生成)
結構型設計模式:結構型模式與對象組合有關,一般能夠用於在不一樣對象之間創建關係的簡單方法。這種模式有助於確保在系統某一部分發生變化時,系統的整個結構不須要同時改變。同時對於不適用因某一特定目的而改變的系統部分,這種模式也可以幫助它們完成重組。
- Decorator(裝飾者)
- Facade(外觀)
- Flyweight(享元)
- Adapter(適配器)
- Proxy(代理)
行爲設計模式:行爲模式專一於改善或簡化系統中不一樣對象之間的通訊。
- Iterator(迭代器)
- Mediator(中介者)
- Observe(觀察者)
- Visitor(訪問者)
讀後感
- 以上內容直接摘抄於原書內容,若有筆誤,歡迎指點,定會及時更改;
- 針對於各大論壇中設計模式的技術分享有太多的技術等級有差別、分享內容片面不具體,技術帖渾水摸魚等問題,本書是一本具備極高專業度與承認度的書,是值得花時間去研究與學習的一本好書;
- 下次更新將着重對第九章:JavaScript 設計模式 逐次精讀並實操應用。
歡迎關注本站公眾號,獲取更多信息