中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

1. 單一職責原則(SRP)

定義：就一個類而言，應該僅有一個引起它變化的原因。

從這句定義我們很難理解它的含義，通俗講就是我們不要讓一個類承擔過多的職責。如果一個類承擔的職責過多，就等于把這些職責耦合在一起，一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到破壞。

比如我經?？吹揭恍〢ndroid開發在Activity中寫Bean文件，網絡數據處理，如果有列表的話Adapter 也寫在Activity中，問他們為什么除了好找也沒啥理由了，把他們拆分到其他類豈不是更好找，如果Activity過于臃腫行數過多，顯然不是好事，如果我們要修改Bean文件，網絡處理和Adapter都需要上這個Activity來修改，就會導致引起這個Activity變化的原因太多，我們在版本維護時也會比較頭疼。也就嚴重違背了定義“就一個類而言，應該僅有一個引起它變化的原因”。

當然如果想爭論的話，這個模式是可以引起很多爭論的，但請記住一點，你寫代碼不只是為了你也是為了其他人。

2. 開放封閉原則(ASD)

定義：類、模塊、函數等等等應該是可以拓展的，但是不可修改。

開放封閉有兩個含義，一個是對于拓展是開放的，另一個是對于修改是封閉的。對于開發來說需求肯定是要變化的，但是新需求一來，我們就要把類重新改一遍這顯然是令人頭疼的，所以我們設計程序時面對需求的改變要盡可能的保證相對的穩定，盡量用新代碼實現拓展來修改需求，而不是通過修改原有的代碼來實現。

假設我們要實現一個列表，一開始只有查詢的功能，如果產品又要增加添加功能，過幾天又要增加刪除功能，大多數人的做法是寫個方法然后通過傳入不同的值來控制方法來實現不同的功能，但是如果又要新增功能我們還得修改我們的方法。用開發封閉原則解決就是增加一個抽象的功能類，讓增加和刪除和查詢的作為這個抽象功能類的子類，這樣如果我們再添加功能，你會發現我們不需要修改原有的類，只需要添加一個功能類的子類實現功能類的方法就可以了。

3.里氏替換原則(LSP)

定義：所有引用基類（父類）的地方必須能透明地使用其子類的對象

里氏代換原則告訴我們，在軟件中將一個基類對象替換成它的子類對象，程序將不會產生任何錯誤和異常，反過來則不成立，如果一個軟件實體使用的是一個子類對象的話，那么它不一定能夠使用基類對象。

里氏代換原則是實現開閉原則的重要方式之一，由于使用基類對象的地方都可以使用子類對象，因此在程序中盡量使用基類類型來對對象進行定義，而在運行時再確定其子類類型，用子類對象來替換父類對象。

在使用里氏代換原則時需要注意如下幾個問題：

子類的所有方法必須在父類中聲明，或子類必須實現父類中聲明的所有方法。根據里氏代換原則，為了保證系統的擴展性，在程序中通常使用父類來進行定義，如果一個方法只存在子類中，在父類中不提供相應的聲明，則無法在以父類定義的對象中使用該方法。

我們在運用里氏代換原則時，盡量把父類設計為抽象類或者接口，讓子類繼承父類或實現父接口，并實現在父類中聲明的方法，運行時，子類實例替換父類實例，我們可以很方便地擴展系統的功能，同時無須修改原有子類的代碼，增加新的功能可以通過增加一個新的子類來實現。里氏代換原則是開閉原則的具體實現手段之一。

Java語言中，在編譯階段，Java編譯器會檢查一個程序是否符合里氏代換原則，這是一個與實現無關的、純語法意義上的檢查，但Java編譯器的檢查是有局限的。

4.依賴倒置原則(DIP)

定義：高層模塊不應該依賴低層模塊，兩個都應該依賴于抽象。抽象不應該依賴于細節，細節應該依賴于抽象。

在Java中，抽象就是指接口或者抽象類，兩者都是不能直接被實例化的；細節就是實現類，實現接口或者繼承抽象類而產生的就是細節，也就是可以加上一個關鍵字new產生的對象。高層模塊就是調用端，低層模塊就是具體實現類。

依賴倒置原則在Java中的表現就是：模塊間通過抽象發生，實現類之間不發生直接依賴關系，其依賴關系是通過接口或者抽象類產生的。如果類與類直接依賴細節，那么就會直接耦合，那么當修改時，就會同時修改依賴者代碼，這樣限制了可擴展性。

5.迪米特原則(LOD)

定義：一個軟件實體應當盡可能少地與其他實體發生相互作用。

也稱為最少知識原則。如果一個系統符合迪米特法則，那么當其中某一個模塊發生修改時，就會盡量少地影響其他模塊，擴展會相對容易，這是對軟件實體之間通信的限制，迪米特法則要求限制軟件實體之間通信的寬度和深度。迪米特法則可降低系統的耦合度，使類與類之間保持松散的耦合關系。

迪米特法則要求我們在設計系統時，應該盡量減少對象之間的交互，如果兩個對象之間不必彼此直接通信，那么這兩個對象就不應當發生任何直接的相互作用，如果其中的一個對象需要調用另一個對象的某一個方法的話，可以通過第三者轉發這個調用。簡言之，就是通過引入一個合理的第三者來降低現有對象之間的耦合度。

在將迪米特法則運用到系統設計中時，要注意下面的幾點：在類的劃分上，應當盡量創建松耦合的類，類之間的耦合度越低，就越有利于復用，一個處在松耦合中的類一旦被修改，不會對關聯的類造成太大波及；在類的結構設計上，每一個類都應當盡量降低其成員變量和成員函數的訪問權限；在類的設計上，只要有可能，一個類型應當設計成不變類；在對其他類的引用上，一個對象對其他對象的引用應當降到最低。

6.接口隔離原則(ISP)

定義：一個類對另一個類的依賴應該建立在最小的接口上。

建立單一接口，不要建立龐大臃腫的接口，盡量細化接口，接口中的方法盡量少。也就是說，我們要為各個類建立專用的接口，而不要試圖去建立一個很龐大的接口供所有依賴它的類去調用。

采用接口隔離原則對接口進行約束時，要注意以下幾點：

接口盡量小，但是要有限度。對接口進行細化可以提高程序設計靈活性，但是如果過小，則會造成接口數量過多，使設計復雜化。所以一定要適度。

為依賴接口的類定制服務，只暴露給調用的類它需要的方法，它不需要的方法則隱藏起來。只有專注地為一個模塊提供定制服務，才能建立最小的依賴關系。

提高內聚，減少對外交互。使接口用最少的方法去完成最多的事情。

這六個原則，可以使我們在應用的迭代維護中更加方便、輕松的應對，讓我們的軟件更加靈活。在后續的文章中我會給大家介紹其他的設計模式

文章鏈接：http://blog.csdn.net/itachi85/article/details/50491657

本文由 @劉望舒 原創發布于人人都是產品經理?，未經許可，禁止轉載。