S.O.L.I.D五大原則 雖然對我不陌生 但是他們的JS實現(xiàn)我沒怎么思考過，今天看湯姆大叔的博客，然后加以總結(jié)， 當(dāng)然不是說這五大原則就是真理 你需要根據(jù)你的項目的真實情況加以使用
- The Single Responsibility Principle（單一職責(zé)SRP）
- The Open/Closed Principle（開閉原則OCP）
- The Liskov Substitution Principle（里氏替換原則LSP）
- The Interface Segregation Principle（接口分離原則ISP）
- The Dependency Inversion Principle（依賴反轉(zhuǎn)原則DIP）
單一職責(zé)
這個怎么說呢，就是每個函數(shù)或者類擁有相對單一的職責(zé)，怎么做呢，這個沒有辦法一概而論，我個人理解就是第一步要邏輯上說的通，就是不能一聽就是錯的，比如食堂的大師傅在做飯的同時不能還要負責(zé)擦地一樣。
第二個要做的就是盡量把邏輯和數(shù)據(jù)拆開，這樣外面只需要修改數(shù)據(jù)而不需要觸碰到邏輯
第三個就是盡量吧相關(guān)邏輯封裝到一起，比如我們有個邏輯用到計算，那么我們可以把所有的計算邏輯抽離出來行成一個新的計算類
開閉原則
軟件實體（類，模塊，方法等等）應(yīng)當(dāng)對擴展開放，對修改關(guān)閉，即軟件實體應(yīng)當(dāng)在不修改的前提下擴展。
我自己粗淺的理解就是 不能因為添加了新的邏輯 就必須把以前 的代碼都要改一下， 比如 我的類增加了一種Type 我們?nèi)绻途托枰砑右粋€ else if 其實是不好的 因為這樣第一是把所有類型的邏輯都寫到了一起 其次是可能要修改多處
而我想到解決方式就是子類話 然后實現(xiàn)不同的接口 這樣的話 當(dāng)邏輯變化的時候 我們只需要新建一個類就好了
里氏替換原則
派生類型必須可以替換它的基類型。
這個我其實不是特別理解，那么我就先從繼承的角度來說一下，但是其實大神們告訴我們不要繼承 要使用組合， 這個之后再說
從繼承的角度講，我認為有兩點
- 子類必須能繼承父類的所有邏輯，如果只想繼承部分代碼，需要把父類再次抽象
- 即使是重寫了父類的方法，也不能使存在的邏輯發(fā)生變化，簡單來說，父類有開門 關(guān)門倆方法，但是子類重寫了開門，但是當(dāng)調(diào)用關(guān)門方法，門是不能被關(guān)上的 ，所以子類也許還需要重寫關(guān)門方法
大神告訴我們
盡量使用對象組合而不是類繼承
里氏替換原則（LSP）的本質(zhì)不是真的和繼承有關(guān)，而是行為兼容性。
當(dāng)然這又涉及了另一個原則 合成復(fù)用
而我的理解就是當(dāng)你需要基類的方法的時候 可以試著不去繼承 而是選擇擁有一個基類的對象作為屬性 然后讓他幫助你實現(xiàn)功能 當(dāng)然這些需要你視情況而定
接口分離原則
不應(yīng)該強迫客戶依賴于它們不用的方法。
不太理解 不過簡單來說就是一個類不能擁有他不需要的方法或者屬性
依賴倒置原則
高層模塊不應(yīng)該依賴于低層模塊，二者都應(yīng)該依賴于抽象
抽象不應(yīng)該依賴于細節(jié)，細節(jié)應(yīng)該依賴于抽象
我的簡單理解就是 不管高級模塊和低級模塊是怎么樣的 我們都必須設(shè)計一個他們倆交流的接口 這個接口是不能改變的 這的之后不管他們怎么修改邏輯 都不會想影響對方 這個就是按接口編程
