以練代學(xué)設(shè)計模式 -- FTP文件管理項目

不知不覺項目接近尾聲，期間畫了不少設(shè)計圖，把能用上的設(shè)計模式都用上了。

今天來盤點一下。

文章目錄

主心骨：中介者模式

撥云見日：責(zé)任鏈模式

四面開花：模板方法模式

其他小圖

潤滑油：服務(wù)器間連接

只給你看接口：線程池模塊

整體流程圖

主心骨：中介者模式

這次項目呢，我的想法是將各服務(wù)器分布與不同的主機(jī)上，所以采用TCP流進(jìn)行進(jìn)程間通信，但是呢，實現(xiàn)的時候我就發(fā)現(xiàn)，如果要將需要通信的服務(wù)器兩兩相連，且不說繁瑣，怎么拓展？

于是我絞盡腦汁，想起來了中介者模式，于是有了下面這張圖：

工程運行的時候，先啟動中控服務(wù)器，中控服務(wù)器會用accept的方式接收來自各邊緣服務(wù)器的連接。

邊緣服務(wù)器連上中控服務(wù)器之后，會發(fā)一個自認(rèn)身份的包給中控服務(wù)器，完成注冊。

此后，通過注冊的服務(wù)器向中控服務(wù)器發(fā)送的包，只需要在包頭中注明包是給哪個服務(wù)器的即可由中控服務(wù)器轉(zhuǎn)交。

往后，如果需要再添置服務(wù)器，也只需將新服務(wù)器連入中控服務(wù)器，自認(rèn)身份即可。

撥云見日：責(zé)任鏈模式

負(fù)責(zé)和客戶端建立連接的前置服務(wù)器，以及中控服務(wù)器，以及將來需要面對大量四面八方消息的服務(wù)器，肯定要用到文件描述符監(jiān)聽模型，我用epoll。

秉著“單一職責(zé)原則”，我認(rèn)為

epoll只需要且只能監(jiān)聽文件描述符，但是它不應(yīng)該知道消息內(nèi)容，更不應(yīng)該對消息進(jìn)行處理。

這個問題確實也困擾了我，我想了好久，因為我以前的做法都是epoll收到消息后，判斷是哪個地方來的消息，如果是監(jiān)聽套接字，則判定是有新連接上來，處理連接（這里就需要將網(wǎng)絡(luò)連接模塊和epoll模塊放在一起，這是其一）；如果是通信套接字（客戶端）來的消息，那么就是客戶端有消息上來，還要判斷是否空包（空包為客戶端掉線，需要處理），若不是空包，則對包進(jìn)行一個基本的判斷（這里就需要解壓包模塊的介入，這是其二），之后將包發(fā)往中控服務(wù)器（這里就需要進(jìn)程間通信模塊的介入，這是其三）；對包的處理與轉(zhuǎn)發(fā)還使用了小型線程池（這就需要線程池模塊的參與，這是其四），此外，還有日志模塊和心跳檢測模塊，

這么多東西，如今一鍋燉在epoll模型中，成何體統(tǒng)？

但是又有什么辦法呢？請求來了，自然是要回應(yīng)的啊，要回應(yīng)，就需要各個模塊之間的配合了，我思來想去，想到了責(zé)任鏈模式。

我以前一直覺得這個模式簡直是雞肋，但是這次之后我改觀了，沒有雞肋的設(shè)計模式，只有雞肋的設(shè)計師。設(shè)計模式的優(yōu)勢是什么？

將請求和處理分開。

請求者可以不知道是誰處理了，處理者也不用知道請求者的全貌。

兩者解耦，提高系統(tǒng)的靈活性。

于是便有了以下這張圖，也正是這張圖吸引了聽我講這個項目設(shè)計的朋友

：

圖我是不會再解釋的，代碼也不會放出來，因為我在我的日報博客中已經(jīng)講得清楚了。

四面開花：模板方法模式

解壓包模塊和數(shù)據(jù)庫模塊可是兩個最不穩(wěn)定的模塊了，因為這兩個模塊會經(jīng)常需要進(jìn)行拓展，它們不像epoll、進(jìn)程間通信、文件管理等模塊，定下來就基本定下來了，只要要拓展新業(yè)務(wù)，肯定要加協(xié)議，再加數(shù)據(jù)庫功能，如果將模塊寫死，便無法自由拓展。我問過不少朋他們?nèi)绾翁幚磉@種情況，他們的回答基本都是一致的：

寫完就完了，拓什么展？非要拓展，拆開重寫。

這個問題并沒有困擾我，這個問題很簡單的：依賴倒置原則，這是我很喜歡的一個原則，面向接口編程，只要我將接口定下來了，后面的拓展只要繼承父類，拓展新接口便可。

于是，圖是這樣的：

數(shù)據(jù)庫還插了單例模式，那小玩意兒就不說了。

其他小圖

再隨便放幾張叫不出模式的圖吧，不過，面向接口編程是真的利于拓展，伸縮自如哦。

潤滑油：服務(wù)器間連接

只給你看接口：線程池模塊

整體流程圖

太長了，就分左右兩塊咯。

FTP 任務(wù)調(diào)度

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。