【編程總結】足球俱樂部

(一)登陸模塊

程序的第一個模塊就是登陸模塊,做成一個提供註冊和登陸功能的類。密碼保存的結構爲:

0

1

 

 

 

 

..

512

513

 

 

 

 

1024

V1

Gap1

gap

Offset

gap

正文

 

V3

Gap2

Gap

長度

gap

正文

 

V2

參數包括密鑰文件驗證的和密鑰信息提取(間隔量,偏移量)的。整個思路是半動態的,同樣的用戶名密碼每次生成的密鑰文件是不同的,正文在密鑰文件中的位置也是變化的,但是控制這些變化的參數在程序中是靜態的,反編譯技術應該就能夠找出這些規律,從而僞造密鑰文件或用其他方式來破解。

 

(二)文件系統

文件系統是用VC提供的CFile類和CARCHIVE來做的,是將文件全部加載到內存,修改後將內存內容全部放回硬盤,不是分段讀寫修改操作,因爲那樣做太複雜,也容易出錯,在文件數據量不大的情況並不實惠。

關於CFile文件讀寫小結:

文件指針從0開始,讀寫後都會自動向後推,當前指向下一次讀寫的位置。

seek調整文件指針,0不移動,n移動n格。

 

(三)對話框類之間的交互

  對話框類的交互是設計的一個小小的難點吧,因爲要涉及到五個以上對話框,所以他們之間的交互是一個問題。這種交互包括數據和方法。

  我並不是採用繼承的方法模型化他們的關係,而是用包含的模型。我認爲繼承關係並不合適,首先他們都是對話框,另外,他們的生命週期重疊、地位一致,等等,而包含關係能夠表示這一切。其他對話框包含在一個主對話框下,於是就形成一個類包含其他好幾個類的關係,他們之間的數據交換關係有兩種(我採用的),一種是直接的,通過this指針把控制權賦給所屬的類(因爲下屬類是上級類的數據成員,所以在其方法中並沒有上級類的實例或實例指針來直接操控上級類),這種方法比較直接,還有一種相對不怎麼直接的方法,就是通過上級類調用下屬類的方法把指定的數據指針或引用傳給下屬類,這種方法可以良好的控制他們之間交互的數據,如果沒有這種控制的需求,或需要控制任何可能的上級類的數據,那麼這種方法都不是最優選擇。但我似乎沒有發現在這種類與類包含關係中有像繼承關係中的protected關係之類的直接的指定數據傳遞並且私有化的機制。

  通過this指針的傳遞可以實現方法的調用。這裏要說的是VC中模態對話框的創建中存在的一個tricky問題,當你domodal一個模態對話框,並在這個對話框類中domodal一個新的模態對話框,並通過這個對話框來onOK前一個模態對話框,會出現錯誤,或者在下一次domodal時候會出錯。具體原因我也不太瞭解,應該是模態對話框機制的問題,只能由自身終結,要做對話框間的頻繁切換,非模態對話框或許是更好的選擇。

 

(四)命令式搜索

  這個要求輸入命令字符串,查找出滿足要求的俱樂部或球員。這是一個難點,但也不是特別難,因爲已經做過相關的數學式的計算的程序。主要就是把命令表達式通過預處理將具體每原子項(也就是要求)的真值求出來形成邏輯表達式(比如@name=ct||@name=tc,就逐一掃描所有球員,把滿足條件的原子項換位1,不滿足的換爲0,最後就成了0 || 1這樣的邏輯表達式了),邏輯表達式的計算就可以用堆棧來做了。把邏輯表達式值爲1的俱樂部或球員取出來放到一個表中,就得到搜索結果了。

 

(五)網絡交互:

  socket 來傳送信息。交互分爲阻塞和非阻塞的,阻塞的就是等待迴應,不迴應進城就堵塞住了,執行不了其他操作,非堵塞就是不管迴應發送完信息後先返回,等對方的回覆到了再響應。其實,由於這個項目的要求是基於小數據的,並且,所有的功能都是符合阻塞模型的,所以用阻塞模型就能很直接的解決問題,但是我由於對話框類的存在等總總問題莫名其妙地就選擇了非阻塞的方式,但這也能良好的工作。從服務器來看,服務器是響應型的,接收到信息就處理,處理後就響應客戶端。從客戶端來看,客戶端是基於用戶消息型的,用戶交互產生消息,消息響應中發送信息到客服端,得到請求後回覆客戶,請求失敗也作出一定的迴應。

  在整個網絡模型的具體實現中,技術核心包括,對話框與網絡的關係以及數據傳輸的格式。對話框與網絡的關係是,網絡得到相應的信息後,並根據當前所處的對話框狀態,跳轉到下一個對話框狀態,隱藏當前對話框,刷新新的對話框並顯示,用的是有限狀態自動機模型。

對於多客戶的支持來自兩個方面,一個是數據格式上的,每次交互都發送驗證信息,並且驗證消息附帶動態碼(每一個俱樂部客戶在每一次登陸都會生成隨機的驗證碼),另外,當服務端正在進行相關信息的修正時,客戶端的“寫操作”是被禁止的,就保證了數據的統一性。數據傳輸的格式是:

  服務端到客戶端:驗證碼+信息槽1+信息槽2。驗證信息每次都傳,信息槽1用來傳送操作指令,有相對統一的格式,而信息槽2的格式則依賴於信息槽1中的指令。

客戶端到服務端:身份碼+即時碼+請求信息。

信息傳遞的格式滿足了基於消息的運作機制。

 

(六)其他

程序的代碼量在四五千行之間,編碼時間是一週中課餘時間。

總的說是學到了一些東西,對面向對象的編程當中類的關係有了更多的理解,對MFC的使用也學了一些東西,網絡編程也開了個頭。

 

附圖幾張:

 

 

發佈了36 篇原創文章 · 獲贊 58 · 訪問量 21萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章