聊一聊設計模式(一)-- 六大原則

前言

去年的11月份吧,我考下了中級軟件設計師的證書,裏面的必考題之一就是設計模式,雖然也沒有很難考,可是若是你是要去國企工做的讀者,其實我建議仍是考上一考,一方面是對知識的複習,另外一方面就是多少加一點工資。 如下附上一個報名的連接:bm.ruankao.org.cn/sign/welcom… java

思惟導圖

設計模式.png

六大原則

文章結構:定義 ---> 白話git

單一職責原則

定義:就一個類而言,應該僅有一個引發它變化的緣由。github

其實字面意思就已經表達的比較明確,單一,也就是幹盡可能少的事情。在HDU中能夠對耦合和內聚程度的評判有必定的瞭解。 什麼叫作少,其實很難有一個標準。可是在Android的MVC框架中,Activity既做爲View,又起着Controller的做用的時候是否顯得會很臃腫呢?他須要進行頁面的刷新,網絡處理,消息處理等等,寫起來容易,可是在咱們進行維護的時候,是否是會很頭疼呢。數據庫

開放封閉原則

定義:類,模塊,函數等應該是能夠擴展的,可是不能夠修改。設計模式

在平常的項目開發中,需求一直是處於一個變更的狀態,可是這一樣也會成爲項目開發的壁壘,若是你的Bean今天是一隻貓,明天就須要是一隻狗呢?從新打補丁嗎?顯然是一個很不合適的作法。而開放封閉原則,解決的就是這一類問題。不管是貓,仍是狗,他們總會有相同的特徵,抽象化也就是這個原則實現的基礎。網絡

// 定義一個動物抽象類
public abstract class Animal {
    abstract void do();
}
 
// 貓實現抽象方法
class Cat extends Animal {
    @Override
    void do() {
        System.out.println("喵");
    }
}
 
// 狗實現抽象方法
class Dog extends Animal {
    @Override
    void do() {
        System.out.println("汪");
    }
}
複製代碼

里氏替換原則

定義:全部引用基類(通常來講都是抽象類或接口)的地方必須能透明的使用其子類的對象。框架

定義的具體含義就是將一個基類對象替換成其子類對象,程序將不會產生任何錯誤和異常,反過來則不成立,若是一個軟件實體使用的是一個子類對象的話,那麼它不必定可以使用基類對象。 或者你仍是不理解的話,如下兩段代碼,就很清晰的解析了上述的含義。ide

List list = new ArrayList<String>();
ArrayList list = new List<String>();
複製代碼

ArrayList做爲咱們擼代碼日子裏的親人,你見過第二種寫法嗎? 接下來就是里氏替換原則的具體實現了。函數

/** * 基於里氏替換原則實現 */
class Manage1 {
    private Animal animal;
 
    public void setAnimal(Animal animal) {
        this.animal = animal;
    }
 
    void getSound() {
        animal.do();
    }
}

/** * 使用子類實現 */
class Manage2 {
    private Cat cat;
 
    public void setAnimal(Cat cat) {
        this.cat = cat;
    }
 
    void getSound() {
        cat.do();
    }
}
複製代碼

以上基於兩種寫法,給予讀者評判,若是使用Manage2,若是咱們但願得到Dog的聲音,那麼就須要從新實現Manager3,而後差別就是隻是把Cat置換成Dog。而Manage1很好的解決了這個問題,由於不管是Cat仍是Dog都是Animal的子類。post

依賴倒置原則

定義:高層模塊不該該依賴底層模塊,二者都應該依賴於抽象。抽象不該該依賴於細節,細節應該依賴於抽象。

兩個概念:

  • 抽象/高層模塊:接口或者抽象類,通常只定義了有什麼操做,可是沒有具體實現。
  • 細節/底層模塊:實現接口或者繼承抽象類而產生的,通常來講就是new出來的對象。

這裏的代碼與里氏替換原則一致。

迪米特原則

定義:一個軟件實體應當少的與其餘實體發生相互做用。

其實和上面的內容差很少,一樣都是爲了下降耦合程度,直接用Demo證實就清楚明瞭了。

電話網絡形式

  • 打電話的人 --> 接電話的人
  • 打電話的人 --> 中間服務商轉接 --> 接電話的人

第一種已經被時代拋棄了,雖然咱們並不知覺,可是第一種電話網絡模式,若是用在現代社會,那麼帶來的後果就是你再也看不見太陽了,頭頂密密麻麻的電話線,更況且那是座機互聯的時代,可以靠電話線來解決,可是這個時代呢?移動互聯的時代呢,不能再靠着電話線來解決問題,而是中間商的介入就改變了這個現狀。

第一種電話網絡模式

/** * 打電話的人 */
class Call {
    private Receiver receiver;
 
    public void setReceicer(Receiver receiver) {
        this.receiver = receiver;
    }
 
    public void call() {
        receiver.receive();
    }
}

/** * 接電話的人 */
class Receiver{
    
    private String number;
    Receiver(String number){
         this.number = number;
    }
    
    public void receive() {
        System.out.println("接通電話");
    }
}

class Main{
    public static void main(String[] args) {
        Call call = new Call();
        call.setReceicer(new Receiver("電話號碼"));
        call.call();
    }
}
複製代碼

第二種電話網絡模式

/** * 轉接 */
public abstract class Manager {
    abstract void link();
}
 
/** * 打電話的人 */
class Call {
    private Manager manager;
    
    public void setManager(Manager manager) {
        this.manager = manager;
    }
 
    public void call() {
        manager.link();
    }
}
 
/** * 接電話的人 */
class Receiver{
    
    private String number;
    Receiver(String number){
         this.number = number;
    }
    
    public void receive() {
        System.out.println("接通電話");
    }
}

class CMCC extends Manager {
    private String number;
  
    CMCC(String number){
      this.number = number;
    }

    public void link() {
        System.out.println("鏈接接電話的人");
        Receiver receiver = new Receiver();
        receiver.receive();
    }
}

class Main{
    public static void main(String[] args) {
        Call call = new Call();
        call.setManager(new CMCC("電話號碼"));
        call.call();
    }
}
複製代碼

這個時候兩個實體經過加入中間商的形式下降了耦合度。

接口隔離原則

定義:一個類對另外一個類的依賴應該創建在最小的接口上

一個接口內要實現的函數數量可控,有那麼一點像數據庫裏的第一範式。讓咱們從Demo看看使用原則的與否的不一樣之處。

正常實現

// 特徵
interface Character {
    void look();
    void nature();
}

class Dog implements Character{
    @Override
    void look() {
        System.out.println("能看");
    }
    @Override
    void nature() {
        System.out.println("淘氣");
    }
}
複製代碼

基於接口隔離原則實現

// 外觀
interface Facade {
     void look();
}
// 內在
interface Inherent {
    void nature();
}

class Dog implements Inherent{
    @Override
    void nature() {
        System.out.println("淘氣");
    }
}
複製代碼

總結

七大原則其實代表的意思仍是比較明確的,雖然可能寫法上的難度會有必定的增長,可是若是使用得當,後期的維護成本將會大大下降。

以上就是個人學習成果,若是有什麼我沒有思考到的地方或是文章內存在錯誤,歡迎與我分享。


相關文章推薦:

聊一聊設計模式(二)-- 建立型設計模式

聊一聊設計模式(三)-- 結構型設計模式

聊一聊設計模式(四)-- 行爲型設計模式

相關文章
相關標籤/搜索