JavaScript設計模式之設計原則

何爲設計

即按照哪種思路或者標準來實現功能，功能相同，能夠有不一樣的設計方案來實現

伴隨着需求的增長，設計的做用就會體現出來，通常的APP天天都在變化，更新很快，需求不斷在增長，若是設計的很差，後面很難維護

結合《UNIX/LINUX設計哲學》10大設計準責

小便是美

相對於同類龐然大物，小巧的事物有着其無可比擬的巨大優點。其中一點就是它們可以以獨特有效的方式結合其餘小事務，並且這種方式每每是最初的設計者沒能預見的。

讓每個程序只作好一件事情

經過集中精力應對單一任務，程序能夠減小冗餘代碼，從而避免太高的開銷、沒必要要的複雜性和缺少靈活性。

儘快創建原型

大多數人認同「創建原型是任何項目的一個重要組成部分。在其餘方法論中，創建原型只是設計中一個不過重要的組成部分，然而，在Unix環境下它倒是達成完美設計的主要工具。

舍高效率而取可移植性

當Unix做爲第一個可移植系統而開創先河時，它曾經掀起過軒然大波。今天，可移植性早被視做現代軟件設計中一個理所固然的特性，這更加充分說明這條Unix準則早就在Unix以外的系統中得到了普遍承認

使用純文本文件來存儲數據

舍高效率而取可移植性強調了可移植代碼的重要性。其實可移植性數據的重要性毫不亞於可移植代碼。在關於可移植性的準則中，人們每每容易忽視可移植性數據。 

充分利用軟件的槓桿效應

不少程序員對可重用代碼模塊的重要性只有一些膚淺認識。代碼重用能幫助人們充分利用軟件的槓桿效應。一些Unix的開發人員正是遵循這個強大的理念，在相對較短的時間內編寫出了大量應用程序。

使用shell腳原本提升槓桿效應和可移植性

shell腳本在軟件設計中可謂是一把雙刃劍，它能夠增強軟件的可重用性和可移植性。不管何時，只要有可能，編寫shell腳原本替代C語言程序都不失爲一個良好的選擇。

避免強制性的用戶界面

Unix開發人員很是瞭解，有一些命令用戶界面爲何會被稱爲是「強制性的"用戶界面。這些命令在運行的時候會阻止用戶去運行其餘命令，這樣用戶就會成爲這些系統的囚徒。在圖形用戶界面中，這樣的界面被稱爲」模態「。

讓每個程序都成爲過濾器

全部軟件程序共有的最基本特性就是，它們只是修改而從不創造數據。所以，基於軟件的過濾器本質，人們就應該把它們編寫成執行過濾器任務的程序。

 

下面還列出了10條次要準則，這些準則正在漸漸發展成Unix世界信奉體系的一個組成部分。並不是每一個與Unix打交道的人都會將它們奉爲信條，並且在嚴格意義上其中一些不能算做是Unix的特性。不過，它們看起來依然是Unix文化（固然地也包括Linux文化）不可或缺的一部分。

容許用戶定製環境

Unix用戶喜歡掌控系統環境，而且是整個環境。不少Unix應用程序絕對不會一刀切地使用交互風格，而是將選擇的權利交給用戶。它的基本思想就是，程序應該只是提供解決問題的機制，而不是爲解決問題的方法限定標準。讓用戶探索屬於本身的通往計算機的家境之路吧。

儘可能使操做系統內核小而輕巧

儘管對新功能的追求永無止境，Unix開發人員仍是喜歡讓操做系統最核心部分保持最小的規模。固然，他們並不老是能作到這一點，但這是他們的目標。

使用小寫字母，並儘可能保持簡短

使用小寫字母是Unix環境中的傳統，儘管這麼作的理由已不復存在，但人們仍是保留了這個傳統。今天，許多Unix用戶之因此要使用小寫的命令和神祕的名字，再也不是由於有其限制條件，而是他們就喜歡這麼作。

保護樹木

Unix用戶廣泛不太同意使用紙質文檔。而是在線存儲全部文字檔案。此外，使用功能強大的在線工具來處理文件是很是環保的作法。

沉默是金

在須要提供出錯信息的時候，Unix命令是出了名的喜歡保持沉默。雖然不少經驗豐富的Unix用戶認爲這是可取得作法，可其餘操做系統的用戶卻並不贊同這種觀點。

並行思考

大多數任務都能分解成更小的子任務。這些子任務能夠並行運行，於是，在完成一項大任務的時間內，能夠完成更多子任務。今天已涌現出大量對稱處理（symmetric multiprocessing，SMP）設計，這說明計算機行業正朝着並行處理的方向發展。

各部分之和大於總體

小程序集合而成的大型應用程序比單個的大程序更靈活，也更爲實用，本條準則正式源於此想法。兩種解決方案可能具有一樣的功能，可集合小程序的作法更具備前瞻性。

尋找90%的解決方案

百分百的完成任何事情都是很困難的。完成90%的目標會更有效率，而且更節省成本。Unix開發人員老是在尋找可以知足目標用戶90%要求的解決方案，剩下的10%則任其自生自滅。

更壞就是更好

Unix愛好者認爲具備」最小公分母「的系統是最容易存活的系統。比起高品質而昂貴的系統，那些便宜但有效的系統更容易獲得普及。因而，PC兼容機的世界從Unix世界借鑑了此想法，並取得了巨大成功。這其中的關鍵字就是包容。若是某一事物的包容性強到足以涵蓋幾乎全部事物，那它就比那些」獨家」系統要好得多。

層次化思考

Unix用戶和開發人員都喜歡層次來組織事物。例如，Unix目錄結構是最先將樹結構應用於文件系統的架構之一。Unix的層次化思考已擴展到其餘領域，如網絡服務命名器、窗口管理、面向對象開發。

 

 

 

 

 

SOLID 五大設計原則

單一職責原則（The Single-Responsibility Principle (SRP)）

單一職責有2個含義，一個是避免相同的職責分散到不一樣的類中,另外一個是避免一個類承擔太多職責。減小類的耦合，提升類的複用性。

一個程序只作好一件事情，若是功能過於複雜就拆分開，每一個部分保持獨立

開放封閉原則（The Open/Closed Principle (OCP)）

對擴展開發，對修改封閉，就是說增長新的需求的時候，擴展新的代碼，而非修改已經有的代碼

里氏替換原則 The Liskov Substitution Principle (LSP)

子類型必須可以替換掉他們的父類型、並出如今父類可以出現的任何地方。主要針對繼承的設計原則

父類的方法都要在子類中實現或者重寫，而且派生類只實現其抽象類中生命的方法，而不該當給出多餘的,方法定義或實現。

在客戶端程序中只應該使用父類對象而不該當直接使用子類對象，這樣能夠實現運行期間綁定。

接口分離原則 The Interface Segregation Principle (ISP)

代表客戶端不該該被強迫實現一些他們不會使用的接口，應該把胖接口中額方法分組，而後用多個接口代替它，每一個接口服務於一個子模塊。簡單說，就是使用多個專門的接口比使用單個接口好不少。

依賴倒置原則 The Dependency-Inversion Principle (DIP)

上層模塊不該該依賴於下層模塊，他們共同依賴於一個抽象(父類不能依賴子類，他們都要依賴抽象類)。抽象不能依賴於具體，具體應該要依賴於抽象。

接下使用promise來演示一下單一職責原則和開放封閉原則（由於這兩種在開發種體現的比較多）

function loadImg(src) {
  let promise = new Promise(function (resolve, reject) {
    let img = document.createElement('img')
    img.onload = function () {
      resolve(img)
    }
    img.onerror = function () {
      reject('圖片加載失敗')
    }
    img.src = src
  })
  return promise
}

let src = 'https://pics6.baidu.com/feed/0b46f21fbe096b635d43b3e50b6b3b40eaf8ac8e.jpeg'
let result = loadImg(src)

result.then(function (img) {
  console.log('img.width', img.width)
  return img
}).then(function (img) {
  console.log('img.height', img.height)
}).catch(function (ex) {
  console.log(ex) // 統一捕獲異常
})

單一職責原則：每一個then種的邏輯只作一件事情

開放封閉原則：若是新增需求，擴展then（promise對象種能夠不斷添加then的回調函數）

 

 

 

從設計到模式

何爲設計模式，能夠拆分開兩個詞來理解，設計是一種思想，而模式是根據設計開發出來的模板

 

 

23種設計模式的介紹

23種設計模式種能夠分爲3類

建立型：工廠模式（工廠方法模式，抽象工廠模式，建造者模式），單例模式，原型模式

結構型：適配器模式，裝飾器模式，代理模式，外觀模式，橋接模式，組合模式，享元模式

行爲型：策略模式，模板方法模式，觀察者模式，迭代器模式，職責鏈模式，命令模式，備忘錄模式，狀態模式，訪問者模式，中介者模式，解釋器模式