多態與面向對象(二)

2019-11-18 12:07:45

字體：大中小

來源：轉載

供稿：網友

　　Rhapsody是我們正在使用的一個集建模與代碼產生功能于一身的工具。它有一個很突出的特點，那就是支持很多OS平臺。噢，我的意思并不是說它像java一樣，有著“write once, run anywhere”的本領，事實上，您可以在Rhapsody中選擇不同的目標平臺，它將選擇對應的編譯器、連接器以輸出您想要的二進制程序。
　　
　　從代碼層面來看，Rhapsody提供了一組OS抽象基類，也就是所謂的OSAL（OS Abstract Layer），比如OMOSThread意味著一個線程、OMOSMessageQueue意味著一個消息隊列、OMOSMutex意味著一個互斥量。Rhapsody的應用程序框架正是通過操縱這些抽象基類的指針，達到與OS交流的目的。
　　
　　對于每個具體的目標平臺，Rhapsody需要從這組抽象類派生出一組具體類，并以相應平臺上的API來實現基類中所聲明的每一個接口。當然，假如Rhapsody不支持您想要的OS平臺，而您的應用程序又偏偏想要運行于其上的話，很顯然，編碼的事情就得您來做。
　　
　　或許您會同我一樣，認為它真的是不過如此。可是，請聽聽這個響亮的聲音：
　　
　　“是嗎？年輕人，請保持冷靜。”不用說，這就是Andy！
　　
　　看來另有玄機。我的目光立即開始在一個叫os.h的文件中搜索，因為所有的os抽象基類就定義在這里。忽然我發現其中竟然定義有一個叫OMOSFactory的類！
　　
　　“Factory？什么嘛，學習操作系統時，老師怎沒講這個東西？”我開始自言自語。
　　
　　“什么？連這個你都不知道啊……”Andy探出頭來，一臉的狐疑。
　　
　　這分明是激將法，我知道他想盡快將我練習成OO殺手，可也用不著這么心急嘛。繼續往下看，我發現OMOSFactory的定義如下：
　　
　　class　OMOSFactory {
　　
　　public:
　　
　　　　　　 static OMOSFactory* instance();
　　
　　virtual OMOSMessageQueue* createOMOSMessageQueue(OMBoolean shouldGrow = TRUE, const long messageQueueSize = OMOSThread::DefaultMessageQueueSize) = 0;
　　
　　　　　　 virtual OMOSThread* createOMOSThread(void tfunc(void *), void *param,
　　
　　　　　　　　　　　 const char* const threadName = NULL,
　　
　　　　　　　　　　　 const long stackSize = OMOSThread::DefaultStackSize) = 0;
　　
　　　　　　 virtual OMOSMutex* createOMOSMutex() = 0;
　　
　　　　　　 // 其它成員函數的聲明
　　
　　　　　　 ......
　　
　　};
　　
　　原來是個名副其實的對象工廠呀，也就是說，將來所有的OS對象都將通過它來創建！由于它是個抽象類，很顯然它需要被派生，并由具體的派生類來完成真正的OS對象創建工作。可是，我忽然隱約覺得有些不對。
　　
　　“既然是個基類，為什么它沒有聲明一個為virtual的析構函數呢？”我嘀咕道。
　　
　　“你怎么老是這么多的為什么，難道當初我就是看中了你提問題的能力？”Andy總不忘給我些刺激。
　　
　　“除非這個類的設計者確定不會有人企圖透過一個pointer-to-base去刪除一個derived object。”
　　
　　“既然如此，那你說說客戶如何來使用這個類？”Andy窮追不舍。
　　
　　對啊，這可是個抽象類，這就是說不可為它定義任何對象。可是現在又竟然不能動態創建一個派生類對象，同時將其地址賦值給一個類型為OMOSFactory *的指針，這該怎么辦呢？
　　
　　忽然，我發現了static OMOSFactory* instance();這么一句，馬上想到去看看這個函數的定義。在文件VxOS.cpp我找到了它：
　　
　　OMOSFactory* OMOSFactory::instance()
　　
　　{
　　
　　　　　　 static VxOSFactory theFactory;
　　
　　　　　　 return &theFactory;
　　
　　}
　　
　　同樣，在文件NtOS.cpp中同樣有它：
　　
　　OMOSFactory* OMOSFactory::instance(){
　　
　　　　　　 static NTOSFactory theFactory;
　　
　　　　　　 return &theFactory;
　　
　　}
　　
　　真相大白！不用說，VxOSFactory和NTOSFactory都是派生自OMOSFactory。事實上，針對VxWorks的OS類和工廠的定義及實現正是在VxOS.h和VxOS.cpp兩個文件中；而針對Win32平臺的OS類和工廠的定義及實現正是在NtOS.h和NtOS.cpp兩個文件中。很顯然，當客戶寫下
　　
　　OMOSFactory::instance();
　　
　　時，他將獲得一個類型為OMOSFactory *的指針，這個指針指向一個具體的派生類對象；而且，由于這個對象是被聲明為static，這表明在程序生命期間，不管上面一句被寫過多少次，只會有一個工廠對象被產生。無論何時，當客戶想要獲取一個互斥量時，他都只需這么寫：
　　
　　OMOSFactory::instance()->createOMOSMutex();
　　
　　而不用管他的程序到底想運行于哪個OS平臺之上。
　　
　　“真是個不錯的idea啊！”我發出由衷的感嘆。
　　
　　“事實上，OMOSFactory實現了一個叫SINGLETON的設計模式。”不知何時，Andy竟然出現在我的身后，臉上似乎還帶著一絲笑意，“當你保證某個類僅有一個實例，并提供一個訪問它的全局訪問點。你就可以使用這個模式。”
　　
　　“是的，您說的很對。不過我總覺得，多態的威力在這里真是發揮得淋漓盡致啊。”
　　[[The No.1 Picture.]]
　　“其實這里還有一個被稱作ABSTRACT FACTORY的設計模式，或許這個能給你一些啟示。”說著，Andy不知從何處拿出一張小圖片[1]：
　　
　　“你看，不管是OS對象，還是創建這些對象的工廠，客戶只需與它們的抽象基類打交道。而且，要正確運用這兩種模式，客戶還應該使用這些基類的指針。事實上，面對以上這這樣一個SINGLETON，除了這么做，你別無選擇。”Andy笑了笑，轉身離去

上一篇：基于.Net的AOP實現技術

下一篇：為什么很多Java開發人員都對JCP感覺很失望