前言

相信做過編程開發的都應該聽說過設計模式，設計模式是歷史上的編程大牛經過不斷的探索，總結出來的一整套經驗的總和。他們總結出來這23種設計模式，告訴我們編程按照這些編程的設計模式可以讓我們代碼的可重用性，可讀寫行，可靠性，易理解等各方面達到一種最優的效果。所以每個做技術開發的人都應該理解這些設計模式，這是成為技術大拿的基礎，要不然真的只能算是碼農了，各種優秀的開源框架也都大量地應用了這些設計模式，所以這也是我們閱讀開源框架源碼的基礎。如何你夠牛的話，你也可以根據自己的經驗來總結出一套設計模式。到時可能就是23+種設計模式了。在總結編程設計模式的時候，大牛們又是根據六大原則來總結的。以下用最短的文字總結介紹著六大基本原則。其實六大基本原則和設計模式并不是很復雜的東西，網上有些洋洋灑灑長篇大論，其實我感覺是把簡單的問題復雜化。

設計模式六大原則(1)：單一職責原則

很好理解，字面上的意思就是同一個類只做一件事，不要把一個類的多種功能揉在一起，比如說筷子類用來夾東西，勺子類用來舀東西，你不能創建一個類既然當筷子又能當勺子。從這個編程原則來說是不合理的。

單一指責原則也是OOP(面向對象)編程的具體體現。很多時候在面向對象編程的時不知不覺中運用了這種原則。但是有時候我們很難進行指責劃分。有時候我們會不斷思考這個功能應該是放在這個類還是那個類猶豫不決。所以運用單一職責原則職責劃分是重點。

設計模式六大原則(2)：里氏替換原則

官方的定義是如果對每一個類型為S的對象o1， 都有類型為T的對象o2， 使得以T定義的所有程序P在所有的對象o1都代換成o2時， 程序P的行為沒有發生變化， 那么類型S是類型T的子類型。

其實里氏替換原則簡單來說就是定義了一個接口，接口規范了很多方法子類必須實現。使用的用接口引用。然后當你換一個實現子類的。你的程序不需要修改。

這樣做的好處有

● 代碼共享， 減少創建類的工作量， 每個子類都擁有父類的方法和屬性；

● 提高代碼的重用性；

● 子類可以形似父類， 但又異于父類， “龍生龍， 鳳生鳳， 老鼠生來會打洞”是說子擁有

父的“種”， “世界上沒有兩片完全相同的葉子”是指明子與父的不同；

● 提高代碼的可擴展性， 實現父類的方法就可以“為所欲為”了， 君不見很多開源框架的

擴展接口都是通過繼承父類來完成的；

● 提高產品或項目的開放性。

設計模式六大原則(3)：依賴倒置原則

官方的定義

● 高層模塊不應該依賴低層模塊， 兩者都應該依賴其抽象；

● 抽象不應該依賴細節；

● 細節應該依賴抽象。

上面的是不是很難理解，那換種說法

● 模塊間的依賴通過抽象發生， 實現類之間不發生直接的依賴關系， 其依賴關系是通過

接口或抽象類產生的；

● 接口或抽象類不依賴于實現類；

● 實現類依賴接口或抽象類。

這一原則就是典型的OOD(面向接口編程的具體實現)

依賴倒置原則有三種的具體實現方式

public interface Food { }

Food 的實現由Rice，Meat。

①構造函數傳遞依賴

public class Eat implements IEat { private Food food; public Eat(Food food){ this.food = food; } @Override public void eating() { food.food(); }}

②setting方法傳遞依賴

public class Eat implements IEat { private Food food; public void setFood(Food food){ this.food = food; } @Override public void eating() { food.food(); }}

③接口方法傳遞依賴

public class Eat implements IEat { @Override public void eating(Food food) { food.food(); }}

設計模式六大原則(4)：接口隔離原則

官方的定義：

①客戶端不應該依賴它不需要的接口。

②類間的依賴關系應該建立在最小的接口上。

怎么理解呢，我們定義一個接口方法盡可能少，粒度盡可能小，它不依賴其他接口獨立完成一個功能或一件事情。接口之間的個功能不應該相互依賴。接口的設計要求本來也是高內聚低耦合。當客戶端功能粒度大時，我們可能引用多個接口完成。

隔離原則在實際過程存在問題是，有些時候我們很難把握一個度，為什么，你的接口粒度越小，拆分的越多，整個項目的可讀性，可維護就越差，所以這得根據我們平時的積累的經驗和實際情況出發來運用這一原則。

設計模式六大原則(5)：迪米特法則

通俗的講一個對象實體應當盡可能少地與其他對象發生相互作用。

一個類應該對自己需要耦合或者調用的類知道最少， 類的內部如何實現與調用者或者依賴關系越密切，耦合度越大，當一個類發生變化時，對另一個類的影響也越大。

①在類的劃分上，應當盡量創建松耦合的類。類之間的耦合度約低，就越有利于服用。一個處于松耦合中的類一旦被修改，則不會對關聯的類造成太大的波及。

②在類的機構設計上， 每一個類都應當盡量降低其成員變量和成員函數的訪問權限。

③在對其他類的引用上， 一個類對其他對象的引用應當降到最低。

設計模式六大原則(6)：開閉原則

一個軟件實體應該通過擴展來實現變化， 而不是通過修改已有的代碼來實現變化。類、模塊、函數等應該是可以拓展的，但是不可修改。

那什么又是軟件實體呢？ 軟件實體包括以下幾個部分：

● 項目或軟件產品中按照一定的邏輯規則劃分的模塊。

● 抽象和類。

● 方法。

參考書籍：設計模式之禪

總結

以上是生活随笔為你收集整理的js倒计时代码最简单的_代码设计开发-6大基本原则解读(最简单扼要的理解)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。