在學習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原則, 這是我學習觀察者模式最大的收穫.
- 擴充套件閱讀
- Java實現簡易聯網坦克對戰小遊戲
- 換一種方式瞭解人工智慧