Observer觀察者模式與OCP開放-封閉原則

在學習Observer觀察者模式時發現它符合敏捷開發中的OCP開放-封閉原則, 本文經過一個場景從差的設計開始, 逐步向Observer模式邁進, 最後的代碼能體現出OCP原則帶來的好處, 最後分享Observer模式在本身的項目中的實現.html

場景引入

  • 在一戶人家中, 小孩在睡覺, 小孩睡醒後須要吃東西.
  • 分析上述場景, 小孩在睡覺, 小孩醒來後須要有人給他喂東西.
  • 考慮第一種實現, 分別建立小孩類和父親類, 它們各自經過一條線程執行, 父親線程不斷監聽小孩看它有沒有醒, 若是醒了就餵食.
public class Observer {
    public static void main(String[] args) {
        Child c = new Child();
        Dad d = new Dad(c);
        new Thread(d).start();
        new Thread(c).start();
    }
}

class Child implements Runnable {
    boolean wakenUp = false;//是否醒了的標誌, 供父親線程探測

    public void wakeUp(){
        wakenUp = true;//醒後設置標誌爲true
    }

    @Override
    public void run() {
        try {
            Thread.sleep(3000);//睡3秒後醒來.
            wakeUp();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    public boolean isWakenUp() {
        return wakenUp;
    }
}

class Dad implements Runnable{
    private Child c;

    public Dad(Child c){
        this.c = c;
    }

    public void feed(){
        System.out.println("feed child");
    }

    @Override
    public void run() {
        while(true){
            if(c.isWakenUp()){//每隔一秒看看孩子是否醒了
                feed();//醒了就餵飯
                break;
            }
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}
複製代碼

 

  • 本設計的不合理之處: 父親線程要每隔一秒去查看一次孩子是否醒了沒, 若是小孩連睡三個小時, 父親線程豈不得連着3個小時每隔一秒訪問一下, 這樣將極大地耗費掉cpu的資源. 父親線程也不方便去作些其餘的事情.
  • 這能夠說是一個糟糕的設計, 迫使咱們對他做出改進. 下面爲了能讓父親能正常幹活, 咱們把邏輯修改成改成小孩醒後通知父親餵食.
public class Observer {
    public static void main(String[] args) {
        Dad d = new Dad();
        Child c = new Child(d);
        new Thread(c).start();
    }
}

class Child implements Runnable {
    private Dad d;//持有父親對象引用

    public Child(Dad d){
        this.d = d;
    }

    public void wakeUp(){
        d.feed();//醒來通知父親餵飯
    }

    @Override
    public void run() {
        try {
            Thread.sleep(3000);//假設睡3秒後醒
            wakeUp();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

class Dad{
    public void feed(){
        System.out.println("feed child");
    }
}
複製代碼

 

  • 以上的版本比起原版在性能上有了提高, 可是小孩醒後只能固定調用父親的餵食方法, 父親不知道任何小孩醒來的任何信息, 好比幾點鐘醒的, 睡了多久. 咱們的程序應該具備適當的彈性, 可擴展性, 深刻分析下, 小孩醒了是一個事件, 小孩醒來的時間不一樣, 父親餵食的食材也可能不一樣, 那麼如何把小孩醒來這一事件的信息告訴父親呢?
  • 若是對上面的代碼進行改動的話, 最直接的方法就是給小孩添加睡醒時間字段, 調用父親的feed(Child c)方法時把本身做爲參數傳遞給父親, 父親經過小孩對象就能得到小孩醒來時的具體信息.
  • 可是根據面向對象思想, 醒來的時間不該該是小孩的屬性, 而應該是小孩醒來這件事情的屬性, 咱們應該考慮建立一個事件類.
  • 一樣是在面向對象對象的原則下, 父親對小孩進行餵食是父親的行爲, 與小孩無關, 因此小孩應該只負責通知父親, 具體的行爲由父親決定, 咱們還應該考慮捨棄父親的feed()方法, 改爲一個更加通用的actionToWakeUpEvent, 對起牀事件做出響應的方法.
  • 並且小孩醒來後可能不僅被餵飯, 還可能被抱抱, 因此父親對待小孩醒來事件的方法能夠定義的更加靈活.
public class Observer {
    public static void main(String[] args) {
        Dad d = new Dad();
        Child c = new Child(d);
        new Thread(c).start();
    }
}

class Child implements Runnable {
    private Dad d;

    public Child(Dad d){
        this.d = d;
    }

    public void wakeUp(){//經過醒來事件讓父親做出響應
        d.actionToWakeUpEvent(new WakeUpEvent(System.currentTimeMillis(), this));
    }

    @Override
    public void run() {
        try {
            Thread.sleep(3000);
            wakeUp();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

class Dad{
    public void actionToWakeUpEvent(WakeUpEvent event){
        System.out.println("feed child");
    }
}

class WakeUpEvent{
    private long time;//醒來的事件
    private Child source;//發出醒來事件的源

    public WakeUpEvent(long time, Child source){
        this.time = time;
        this.source = source;
    }
}
複製代碼
  • 顯然這個版本的可擴展性高了一些, 咱們接着分析. 因爲如今對小孩醒來事件的動做已經不止於餵食了, 若是如今加入一個爺爺類的話, 可讓爺爺在小孩醒來的時候做出抱抱小孩的響應.
  • 可是引來的問題是, 要讓爺爺知道小孩醒了, 必須在小孩類中添加爺爺字段, 假如還要讓奶奶知道小孩醒了, 還要添加奶奶字段, 這種不斷修改源代碼的作法意味着咱們的程序還存在改進的地方.
  • 在《敏捷軟件開發:原則、模式與實踐》一書中曾談到OCP(開發-封閉原則), 裏面指出軟件類實體(類, 模塊, 函數等)應該是能夠擴展的, 可是不可修改的. 爲了知足OCP原則, 最關鍵的地方在於抽象, 在本例中, 咱們能夠把監聽小孩醒來事件向上抽象出一個接口, 接口中有惟一的監聽醒來事件的方法. 實現該接口的實體類能夠根據醒來事件做出各自的動做.
  • 小孩發出醒來事件後能夠不單止通知父親一人, 他能夠把醒來事件發送給全部在他這注冊過的監聽者.
  • 因此看成出這樣的抽象後, 就不單止孩子能發出醒來的事件了, 小狗也能發出醒來的事件, 並被監聽.
public class Observer {
    public static void main(String[] args) {
        Child c = new Child();
        c.addWakeUpListener(new Dad());
        c.addWakeUpListener(new GrandFather());
        c.addWakeUpListener(new Dog());
        new Thread(c).start();
    }
}

class Child implements Runnable {
    private ArrayList<WakeUpListener> list = new ArrayList<>();

    public void addWakeUpListener(WakeUpListener l){//對外提供註冊監聽的方法
        list.add(l);
    }

    public void wakeUp(){
        for(WakeUpListener l : list){//通知全部監聽者
            l.actionToWakeUpEvent(new WakeUpEvent(System.currentTimeMillis(), this));
        }
    }

    @Override
    public void run() {
        try {
            Thread.sleep(3000);
            wakeUp();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

interface WakeUpListener{
    public void actionToWakeUpEvent(WakeUpEvent event);
}

class Dad implements WakeUpListener{
    @Override
    public void actionToWakeUpEvent(WakeUpEvent event){
        System.out.println("feed child");
    }
}

class GrandFather implements WakeUpListener{
    @Override
    public void actionToWakeUpEvent(WakeUpEvent event) {
        System.out.println("hug child");
    }
}

class Dog implements WakeUpListener{
    @Override
    public void actionToWakeUpEvent(WakeUpEvent event) {
        System.out.println("wang wang...");
    }
}

class WakeUpEvent{
    private long time;
    private Child source;//事件源

    public WakeUpEvent(long time, Child source){
        this.time = time;
        this.source = source;
    }
}
複製代碼
  • 經過上面的例子, 咱們能清楚地看到整個觀察者模式的模型, 當一個對象的發出某個事件後, 會通知全部的依賴對象, 在OCP原則下, 依賴對象響應事件的具體動做和事件發生源是徹底解耦的, 咱們能夠在不修改源碼的狀況下隨時加入新的事件監聽者, 做出新的響應.

 

在聯網坦克項目中使用觀察者模式

  • 以前寫了個網絡版的坦克小遊戲, 這裏是項目的GitHub地址
  • 在學習觀察者模式後進一步考慮遊戲中能夠改進的地方. 如今子彈打中坦克的邏輯是這樣的: 子彈檢測到打中坦克後, 首先它會設置本身的生命爲false, 而後設置坦克的生命也爲false, 最後產生一個爆炸並向服務器發送響應的消息.
public boolean hitTank(Tank t) {//子彈擊中坦克的方法
        if(this.live && t.isLive() && this.good != t.isGood() && this.getRect().intersects(t.getRect())) {
            this.live = false;//子彈死亡
            t.setLive(false);//坦克死亡
            tc.getExplodes().add(new Explode(x - 20, y - 20, tc));//產生一個爆炸
            return true;
        }
        return false;
    }
複製代碼
  • 這個設計顯然不太符合面向對象思想, 由於子彈打中坦克後, 子彈設置爲死亡是子彈的事, 可是坦克死亡則應該是坦克本身的事情.
  • 在本來的設計中, 若是咱們想給坦克加上血條不但願它被打中一次就死亡, 那麼就得在子彈打中坦克的方法中修改, 代碼的可維護性下降了.
  • 下面將使用Observer觀察者模式對這部分代碼進行重寫, 讓坦克本身對被子彈打中做出響應, 並給坦克加入血條, 每被打中一次扣20滴血.
/** * 坦克被擊中事件監聽者(由坦克實現) */
public interface TankHitListener {
    public void actionToTankHitEvent(TankHitEvent tankHitEvent);
}

public class TankHitEvent {
    private Missile source;

    public TankHitEvent(Missile source){
        this.source = source;
    }
    //省略 get() / set() 方法...
}

/* 坦克類 */
public class Tank implements TankHitListener {
    //...
    
    @Override
    public void actionToTankHitEvent(TankHitEvent tankHitEvent) {
        this.tc.getExplodes().add(new Explode(tankHitEvent.getSource().getX() - 20,
                tankHitEvent.getSource().getY() - 20, this.tc));//坦克自身產生一個爆炸
        if(this.blood == 20){//坦克每次扣20滴血, 若是隻剩下20滴了, 那麼就標記爲死亡.
            this.live = false;
            TankDeadMsg msg = new TankDeadMsg(this.id);//向其餘客戶端轉發坦克死亡的消息
            this.tc.getNc().send(msg);
            this.tc.getNc().sendClientDisconnectMsg();//和服務器斷開鏈接
            this.tc.gameOver();
            return;
        }
        this.blood -= 20;//血量減小20並通知其餘客戶端本坦克血量減小20.
        TankReduceBloodMsg msg = new TankReduceBloodMsg(this.id, tankHitEvent.getSource());//建立消息
        this.tc.getNc().send(msg);//向服務器發送消息
    }
    
    //...
}
/* 子彈類 */
public class Missile {
    //...
    
    public boolean hitTank(Tank t) {//子彈擊中坦克的方法
        if(this.live && t.isLive() && this.good != t.isGood() && this.getRect().intersects(t.getRect())) {
            this.live = false;//子彈死亡
            t.actionToTankHitEvent(new TankHitEvent(this));//告知觀察的坦克被打中了
            return true;
        }
        return false;
    }

    //...
}
複製代碼

 

總結

  • 觀察者模式遵循了OCP原則, 在這種消息廣播模型中運用觀察者模式能提升咱們程序的可擴展性與可維護性.
  • 從實戰項目咱們也能夠看到, 若是要運用觀察者模式必然要增添一些代碼量, 對應的是開發成本的增長, 在坦克項目中我是爲使用設計模式而使用設計模式, 其實若是僅僅從簡單能用的角度來看, 觀察者模式可能不是一種最佳選擇.
  • 但因爲如今處於學習階段, 我認爲不能由於項目小而不追求更合理的設計, 觀察者模式實現了消息發佈者和觀察者之間的解耦, 使得觀察者可以獨立處理響應, 符合面向對象思想; 同時對觀察者進行抽象, 使得咱們能夠不修改源碼, 經過添加的方式加入更多的觀察者, 符合OCP原則, 這是我學習觀察者模式最大的收穫.

 

相關文章
相關標籤/搜索