亚洲色欲啪啪久久WWW综合网,亚洲av伊人久久综合密臀性色 ,国产精一品亚洲二区在线播放

騎警

posted @ 2007-07-20 17:28 AAAAA 閱讀(299) | 評(píng)論 (1) | 編輯收藏

常聽說這么一句話(大意是這樣)：不必可以去套用設(shè)計(jì)模式，如果按照面向?qū)ο蟮幕驹瓌t編程，自然是優(yōu)雅的設(shè)計(jì)，即使沒有刻意使用模式，設(shè)計(jì)也會(huì)近乎于模式。開始感覺有一點(diǎn)玄，但在看了《C#設(shè)計(jì)模式縱橫談》視頻后，覺得有所收獲。下面，就參考視頻的內(nèi)容，嘗試著寫這么一個(gè)過程：根據(jù)面向?qū)ο蟮囊话阍瓌t對(duì)設(shè)計(jì)進(jìn)行重構(gòu)，逐漸演化出觀察者模式。
涉及的面向?qū)ο笤O(shè)計(jì)原則：單一職責(zé)原則、封裝變化、面向接口編程、依賴倒置原則、開閉原則。

1.發(fā)布訂閱模型：

假如有需求如下:

銀行需要把帳戶的如匯款、轉(zhuǎn)賬或取款等操作通知用戶，途徑包括手機(jī)短信、 email等。如圖所式。

自然地，我們可以這樣做：

public class ATM
{
     BankAccount bankAccount;

     public void process()
     {
          //bankAccount...
         this.sendEmail(userEmail);
         this.sendPhone(phoneNumber);
     }

     private void sendEmail(String userEmail)
     {
         //
     }

    private void sendMobile(String phoneNumber)
     {
         //
     }
}

ATM機(jī)的 process()方法在處理完業(yè)務(wù)邏輯后，由email和phone通知用戶。

2.初步重構(gòu)

好像有bad smells，恩，根據(jù)單一職責(zé)原則。新增Email類和Phone類，并把相關(guān)業(yè)務(wù)邏輯改到BankAccount類完成。于是我們的代碼可以這樣：

public class ATM
{
    BankAccount bankAccount;


    public void process()
    {
          //

          bankAccount.withDraw();
    }

}

public class BankAccount
{
    Email email;
    Mobile mobile;

    public void withDraw()
    {
         //

         email.sendEmail(userEmail);
         mobile.sendMobile(phoneNumber);
    }
}

public class Email
{
    public void sendEmail(String userEmail)
    {
    }
}

public class Mobile
{
    public void sendMobile(String phoneNumber)
    {
    }
}

下面是代碼的UML圖：

3.擁抱變化

這個(gè)解決方案有問題嗎?可能沒有問題。它實(shí)現(xiàn)了我們的需求：在帳戶有操作變動(dòng)的時(shí)候，通知Email和Mobile去發(fā)送信息給用戶。但這樣設(shè)計(jì)就足夠了嗎？可能足夠了，可能還不夠。
考慮如下兩種情況：
1.在很長(zhǎng)一段時(shí)間里，訂閱方式很穩(wěn)定，比如系統(tǒng)只通過郵件和手機(jī)短信進(jìn)行信息訂閱，那么這個(gè)實(shí)現(xiàn)沒有太大問題；
2.在近一兩年或更短的時(shí)間，更多的訂閱方式將會(huì)源源不斷地被加進(jìn)來：比如可以登錄官方網(wǎng)站等等，那這個(gè)實(shí)現(xiàn)就有問題：再看一下我們的UML圖，類BankAccount依賴于Email和Mobile類！就是說，如果需要添加新的訂閱方式ATM類的process()方法勢(shì)必要重新設(shè)計(jì)！

于是我們的BankAccount類不得不變成：

public class  BankAccount
{
    Email email;
    Mobile mobile;
    Web web;

    public void withDraw()
    {
          //
         email.sendEmail(userEmail);
         mobile.sendMobile(phoneNumber);
         web.sendWeb(webSite);
    }

}

如果還有另一種方式，那么process()方法就又會(huì)需要加入：otherSubscribe.send...();等方法，另外如果訂閱類的接口(這里指sendEmail等方法)發(fā)生變化，BankAccount的withDraw()方法也必須有相應(yīng)的變化！這當(dāng)然是種災(zāi)難。我們必須改變這種情況。
先解決遺留問題：第一種情況：訂閱方式相對(duì)穩(wěn)定的情況下呢？不改動(dòng)會(huì)產(chǎn)生災(zāi)難嗎？
個(gè)人認(rèn)為：不會(huì)。比如某個(gè)系統(tǒng)信息只通過手機(jī)短信訂閱，那就沒有必要太在意這個(gè)問題。考慮周全一點(diǎn)不好嗎，如果將來有類似需求呢？小心過度設(shè)計(jì)！為了將來可能出現(xiàn)需求而進(jìn)行的預(yù)先設(shè)計(jì)并不太好。有需求，才有設(shè)計(jì)。

現(xiàn)在來看解決之道：

運(yùn)用面向?qū)ο蟮乃枷耄橄蟪鰡栴}所在。BankAccount類依賴于 Email類和Mobile類，而Email和Mobile是具體的類，ATM依賴于具體的類了，而且還不止一個(gè)！回憶一下依賴倒置原則：具體應(yīng)該依賴于抽象，底層模式應(yīng)該依賴于高層模式。那怎么實(shí)現(xiàn)依賴倒置原則呢?面向?qū)ο缶幊讨杏幸粭l總的原則：封裝變化。如何實(shí)現(xiàn)封裝變化？需要我們這樣：面向接口編程。

回顧一下：我們?cè)谠O(shè)計(jì)中實(shí)現(xiàn)類依賴了具體的類，違反了依賴倒置原則。為了遵循依賴倒置原則，我們采用面向接口編程的方法，從而實(shí)現(xiàn)了面向?qū)ο蟮囊粭l總的原則：封裝變化。

看代碼：

public interface AccountObserver
{
    public void upDate(UserAccount userAccount);
}

public class Email implements AccountObserver
{
    public void upDate(UserAccount userAccount)
    {
    }
}

public class Mobile
{
    public void upDate(UserAccount userAccount)
    {
    }
}

public class BankAccount
{
    List <AccountObserver> observer = new ArrayList<AccountObserver>;

    public void withDraw()
    {
         //
         for (AccountObserver ao : observer)
         {
            ao.upDate(userAccount)
          }
    }

    public void addOberver(AccountObserver accountObserver)
    {
          observer.add(accountObserver);
     }
}

UML圖：

現(xiàn)在，BankAccount依賴于interface AccountObserver。Email和Mobile實(shí)現(xiàn)AccountObserver接口。通過遵循面向接口編程遵循了依賴倒置原則。

4.開閉原則

終于修改好了，我們解決了訂閱者變化的問題。但如果發(fā)布者也傾向于變化呢？這就牽涉到面向?qū)ο罄锏牧硪粋€(gè)原則：開閉原則。即：對(duì)擴(kuò)展開放，對(duì)修改關(guān)閉。具體怎么做呢？通過抽象類，從抽象類繼承具體類。
看最終的代碼(只寫幾個(gè)關(guān)鍵的方法，全貌可看最后的UML圖)：

訂閱：

public interface AccountObserver
{
    public void upDate(UserAccount userAccount);
}

public class Email implements AccountObserver
{
    public void upDate(UserAccount userAccount)
    {
    }
}

public class Mobile implements AccountObserver
{
    public void upDate(UserAccount userAccount)
    {
    }
}

發(fā)布：

public abstract class Subject
{
     List <AccountObserver> observer = new ArrayList<AccountObserver>;

    protected void withDraw()
    {
         //
         notify();

    }

    protected void notify(UserAccount userAccount)
    {
         for (AccountObserver ao : observer)
         {
            ao.upDate(userAccount)
          }
     }

    protected void addOberver(AccountObserver accountObserver)
    {
          observer.add(accountObserver);
     }

      protected void deleteOberver(AccountObserver accountObserver)
    {
          observer.remove(accountObserver);
     }

}

public class BankAccount extends Subject
{
    public void withDraw()
    {
         //
         for (AccountObserver ao : observer)
         {
            ao.upDate(userAccount)
          }
    }

}

看UML圖：

5.觀察者模式概況

這就是觀察者模式了，對(duì)比一下官方的UML圖，是不是一目了然了呢？
稍作說明(這里的依賴都是指廣義的依賴)：
1.被觀察者ConcreteSubject繼承自Subject抽象類；
2.Subject抽象類依賴于觀察者Observer抽象接口；
3.觀察者ConcreteObserver實(shí)現(xiàn)Observer 接口；
4.觀察者ConcreteObserver間接依賴于ConcreteSubject類。
如果要增加具體的觀察者，只要再實(shí)現(xiàn)Obsever接口即可，而被觀察方不需要做任何修改。而如果需要修改被觀察者，只要從Subject抽象類繼承即可。

posted @ 2007-07-10 10:36 AAAAA 閱讀(323) | 評(píng)論 (0) | 編輯收藏