[TOC] 在學習Observer觀察者模式時發現它符合敏捷開發中的OCP開放 封閉原則, 本文通過一個場景從差的設計開始, 逐步向Observer模式邁進, 最後的代碼能體現出OCP原則帶來的好處, 最後分享Observer模式在自己的項目中的實現. 場景引入 在一戶人家中, 小孩在睡覺, 小孩睡 ...
目錄
在學習Observer觀察者模式時發現它符合敏捷開發中的OCP開放-封閉原則, 本文通過一個場景從差的設計開始, 逐步向Observer模式邁進, 最後的代碼能體現出OCP原則帶來的好處, 最後分享Observer模式在自己的項目中的實現.
場景引入
- 在一戶人家中, 小孩在睡覺, 小孩睡醒後需要吃東西.
- 分析上述場景, 小孩在睡覺, 小孩醒來後需要有人給他喂東西.
- 考慮第一種實現, 分別創建小孩類和父親類, 它們各自通過一條線程執行, 父親線程不斷監聽小孩看它有沒有醒, 如果醒了就喂食.
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原則, 這是我學習觀察者模式最大的收穫.