五大設計原則（SOLID）
一般情況下，我們為軟體構建中層架構的主要目標如下：
①使軟體可容忍被更改
②使軟體更容易被理解
③構建可在多個軟體系統中複用的元件
簡要介紹下SOLID原則：
一、 單一職責原則
該設計原則是基於康威定律的一個推論——一個軟體系統的最佳結構高度依賴於開發這個系統的組織的內部結構。這樣每個軟體模組有且只有一個需要被改變的理由。
二、 開閉原則
該設計原則是由Bertrand Meyer在20世紀80年代大力推廣的，其核心要素是：如果軟體系統想要更容易被改變，那麼其設計就必須允許新增程式碼來修改系統行為，而非只能靠修改原來的程式碼。
三、 里氏替換原則
該設計原則是Barbara Liskov在1988年提出的一個著名的子型別定義。簡單來說，這項原則的意思是如果想用可替換的元件來構建軟體系統，那麼這些元件就必須遵守同一個約定，以便讓這些元件可以相互替換。
四、 介面分離原則
該項設計原則主要告誡軟體設計師應該在設計中避免不必要的依賴。
五、 依賴反轉原則
該設計原則指出高層策略性的程式碼不應該依賴實現底層細節的程式碼，恰恰相反，那些實現底層細節的程式碼應該依賴高層策略性的程式碼。
相關推薦
五大設計原則（SOLID）
一般情況下，我們為軟體構建中層架構的主要目標如下： ①使軟體可容忍被更改 ②使軟體更容易被理解 ③構建可在多個軟體系統中複用的元件 簡要介紹下SOLID原則： 一、 單一職責原則 該設計原則是基於康威定律的一個推論——一個軟體系統的最佳結構
第2章 面向物件的設計原則（SOLID）：6_開閉原則
6. 開閉原則（Open Closed Principle，OCP） 6.1 定義 （1）一個類應該對擴充套件開放，對修改關閉。要求通過擴充套件來實現變化，而且是在不修改己有的程式碼情況下進行擴充套件，也不必改動己有的原始碼或二進位制程式碼。 （2）在軟體生命週期內，變化是一個既定的事實
第2章 面向物件的設計原則（SOLID）：5_迪米特法則
5. 迪米特法則（Law of Demeter，LoD） 5.1 定義 （1）應儘量減少其他物件之間的互動，物件只和自己的朋友交談，即對其他依賴的類越少越好（不要和太多的類發生關係）。 （2）儘量不要讓類和類之間建立直接的關係，這樣可減少類與類之間的依賴，降低類之間的耦合。 （3）一
第2章 面向物件的設計原則（SOLID）：4_介面隔離原則（ISP）
4. 介面隔離原則（Interface Segregation Principle，ISP） 4.1 定義 （1）使用多個專門的介面，而不使用單一的總介面，即客戶端不應該依賴那些它不需要的介面。類間的依賴關係應該建立在最小介面上 （2）介面儘量細化，同時介面中的方法儘量少。每個介面中只包
第2章 面向物件的設計原則（SOLID）：3_依賴倒置原則（DIP）
3. 依賴倒置原則（Dependence Inversion Principle，DIP） 3.1 定義 （1）要依賴抽象，不要依賴具體的實現類。簡單的說就是對抽象（或介面）進行程式設計，不要依賴實現進行程式設計，這樣就降低了客戶與實現模組間的耦合。包含3層含義： ①高層模組不應依賴
第2章 面向物件的設計原則（SOLID）：2_里氏替換原則（LSP）
2. 里氏替換原則（Liskov Substitution Principle，LSP） 2.1 定義 （1）所有使用基類的地方必須能透明地使用子類替換，而程式的行為沒有任何變化（不會產生執行結果錯誤或異常）。只有這樣，父類才能被真正複用，而且子類也能夠在父類的基礎上增加新的行為。也只有這樣
第2章 面向物件的設計原則（SOLID）：1_單一職責原則（SRP）
1. 單一職責原則（Single Responsibility Principle，SRP） 1.1 單一職責的定義 （1）定義：一個類應該僅有一個引起它變化的原因。這裡變化的原因就是所說的“職責”。 （2）如果一個類有多個引起它變化的原因，也就意味著這個類有多個職責。即把多個職責耦合在
設計模式之設計原則（一）
擴展 原因 依賴 設計原則 細節 面向接口 編程 面向 size 一： 單一職責原則：就一個類而言，應該只有一個引起它變化的原因。 二： 開閉原則：軟件實體對擴展開放，對修改關閉。 三： 裏式代換原則：子類型必須能夠替換掉它們的父類型。 四： 依賴倒轉原則：
設計模式之設計原則（二）
font 通過 size 模式 span 通信 轉發 設計模式 其他 五： 接口分離原則：不應該強迫程序依賴它們不需要使用的方法。即，一個接口不需要提供太多的行為，一個接口應該只提供一種對外的功能，不應該把所有的操作都封裝到一個接口中。 六： 迪米特原則：一個對象應
大話設計模式C++實現-第3.4.5-設計原則（1）
第三章-單一職責原則 （1）.就一個類而言，應該僅有一個引起它變化的原因。 （2）如果一個類承擔的職責過多，就等於把這些職責耦合在了一起，一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當發生變化時，設計會遭受到意想不到的破壞。 （3）軟體設計真正要做
23中設計模式概括及六種設計原則（一）
一、設計模式分類 總體來說模式依據目的可分為建立型模式（Creational）、結構型模式（Structural）、行為型模式（Behavioral）三種。 建立型模式：處理物件的建立。共5種：工廠方法模式（Factory Method）、抽象工廠模式（Abstract Factory）、建造者模式（Bu
(轉) 面向物件設計原則（二）：開放-封閉原則（OCP）
原文：https://blog.csdn.net/tjiyu/article/details/57079927 面向物件設計原則（二）：開放-封閉原則（OCP） 開放-封閉原則（Open-closed principle，OCP）也
以C/C++語法淺談六大設計原則（一）——依賴倒置原則（Dependence Inversion Principle）
一. 前言 眾所周知，在軟體開發過程中，我們的六大設計原則與二十三種設計模式可以說是我們開發的思想精髓。然而，網上或者書本大多數的資料都是以java、python等其他語言語法進行介紹與闡述，很少有以C/C++的語法進行深入介紹。鑑於此，本人以淺薄的見識對這些精妙的思想做以總結，方便
HBase RowKey設計原則（全面）
這段時間實在太忙了，工作和備考幾乎用盡了所有時間，以前的愛好都漸漸遠離了，現在也就更新部落格這個小喜好了，每天看到日益增長的訪問量還是挺開心的，能幫到別人也是一種快樂。這篇HBase的行健設計原則文
商城資料庫設計原則（二）-商品模型的設計
在電商系統中，商品模型至關重要，是整個電商的核心，下面通過一個簡單的分析，設計一個基礎的商品模型。 商品模型的演化 在以前，那時CMS很流行，最常見的模型是欄目-文章模型。於是做電商的時候，自然就繼承了這種一對多的關係。只是欄目變成了分類，文章變成了商品。商
單一職責原則詳解--七大面向物件設計原則（1）
單一職責原則來源： 定義：單一職責就是一個類負責一項職責.就一個類而言，應該只專注於做一件事和僅有一個引起它變化的原因。 所謂職責，我們可以理解為功能，就是設計的這個類功能應該只有一個，而不是兩個或更多。也可以理解為引用變化的原因，當你
資料庫設計原則（簡明）
本文摘錄自http://blog.csdn.net/haiross/article/details/50427382 原文有更詳細講解。 正規化標準 知乎 https://www.zhihu.com/question/24696366 基本表及其欄位之間的關係,應儘量滿
面向物件設計原則（一）——單一職責原則
單一職責原則定義（Single Responsibility Principle，SRP） 一個物件應該只包含 單一的職責，並且該職責被完整地封裝在一個類中。 Every Object should have a single responsibility, an
六大設計原則（一）單一職責原則、里氏替換原則
一、單一職責原則： 英文名Single Responsibility Principle，應該有且僅有一個原因引起類的變更。 There should never be more than one reason for a class to change。 單一職責原則提出
設計模式六大設計原則（六）：開閉原則
開發十年，就只剩下這套架構體系了！ >>>