總想寫一些東西，但總是發(fā)現(xiàn)想寫的內(nèi)容還沒(méi)積累到可以寫出來(lái)的程度。沒(méi)有壓力是不行的，至少每月得來(lái)那么一次才對(duì)，不然就鬧出人命了。^3^
很羨慕那些做題的同學(xué)，每道題的算法都可以發(fā)一篇博文，可惜我多數(shù)情況下都看不懂也就不細(xì)看。不過(guò)有空的時(shí)候細(xì)看一篇，google其中理論，還是很長(zhǎng)見識(shí)的。很久前我就看過(guò)一篇最大流最小割的，大學(xué)學(xué)過(guò)忘了，這次算記住了。

1.虛函數(shù)vs回調(diào)函數(shù)
可能通過(guò)繼承進(jìn)行復(fù)用真不是什么好東西。
最初為bo2服務(wù)器組設(shè)計(jì)通信層的時(shí)候，使用的socket c++wrap lib的設(shè)計(jì)理念是通過(guò)繼承來(lái)對(duì)模式化的網(wǎng)絡(luò)編程代碼進(jìn)行復(fù)用，以及通過(guò)實(shí)現(xiàn)指定的虛函數(shù)來(lái)開展應(yīng)用上的業(yè)務(wù)。
這樣的接口，一看便知。最接近基本認(rèn)識(shí)的做法，就是繼承TcpSocket，然后按業(yè)務(wù)需求實(shí)現(xiàn)那些虛函數(shù)。
第一版的bo2服務(wù)器組就是在這種想法下實(shí)現(xiàn)通信層的。這造成了一些問(wèn)題，服務(wù)器組里面有很多服務(wù)器，每個(gè)服務(wù)器需要的TcpSocket子類并不是完全一致的，畢竟不同的連接處理的消息都不太一樣，于是TcpSocket的子類的數(shù)量就寫的有些多了，而且每個(gè)服務(wù)器都寫。

不久后，以將通信層劃入一個(gè)獨(dú)立的線程為契機(jī)，重構(gòu)開始了。因?yàn)閷?duì)第一版的設(shè)計(jì)不甚滿意加上多線程的情況下無(wú)法直接給應(yīng)用層拿著TcpSocket的指針（這個(gè)庫(kù)默認(rèn)情況自動(dòng)析構(gòu)已斷開的Socket對(duì)象），最終的手段是，實(shí)現(xiàn)唯一的TcpSocket子類，在虛函數(shù)中統(tǒng)一的調(diào)用3個(gè)與之對(duì)應(yīng)但全局唯一的回調(diào)函數(shù)。于是，第二版展現(xiàn)的是，每個(gè)服務(wù)器都有一個(gè)類似network的模塊，實(shí)現(xiàn)這3個(gè)回調(diào)函數(shù)，不同的連接如果有不同的代碼的話，則根據(jù)連接的id進(jìn)行跳轉(zhuǎn)。
總算砍斷繼承的鎖鏈了。

不過(guò)事情并沒(méi)有在這里就完全結(jié)束了。bo2服務(wù)器組并不會(huì)僅僅只有當(dāng)前這些數(shù)量的服務(wù)器，以后隨著新的需求而將不斷增加，如何能讓新來(lái)的同學(xué)更快的開發(fā)新的業(yè)務(wù)服務(wù)器而不必在通信層上花費(fèi)任何精力呢，答案就是把每個(gè)服務(wù)器的network模塊統(tǒng)一并入appbase中。
只是連接上某個(gè)服務(wù)器并不能成為bo2服務(wù)器組的一分子。連接誰(shuí)，連接上之后要交代什么信息，這都是有規(guī)定的。而這些工作都是在每個(gè)服務(wù)器的network模塊單獨(dú)做的，勢(shì)必不能讓新同學(xué)為這些差不多重復(fù)的代碼而煩惱。
多數(shù)類似的服務(wù)器的network模塊并入appbase并不算太難，不過(guò)困難的是一些核心服務(wù)器，他們不太一樣，很多連接需要好幾個(gè)不同的onconnect和ondisconnect回調(diào)，可是第二版使用的是全局唯一的回調(diào)，而且現(xiàn)在也帶著默認(rèn)代碼隱藏到appbase里了。
修改了一下，最終我讓每個(gè)連接都可以指定自己獨(dú)有的onconnect和ondisconnect回調(diào)，但是新同學(xué)不必?fù)?dān)心這個(gè)，因?yàn)樗麄兪裁匆膊恍枰付ê蛯?shí)現(xiàn)，他們只要在service模塊中專心處理消息就可以了。

繞了三版，得出的是每個(gè)連接都可以指定不同回調(diào)函數(shù)的方案(onRead是統(tǒng)一的)，就跟TcpSocket的三個(gè)虛函數(shù)一樣，想想都好笑。不過(guò)有了繼承不是復(fù)用的好方式這種想法，算是一種收獲吧。


2.統(tǒng)一的定義stl庫(kù)包含頭
幾天前出了個(gè)bug，就是debug運(yùn)行正常，release運(yùn)行崩潰那種，崩潰的位置在一處list<t>::begin()調(diào)用上。最終查證的結(jié)果是因?yàn)閎o2項(xiàng)目通過(guò)一些stl宏對(duì)stl容器進(jìn)行了裁減，統(tǒng)一用std_inc.h導(dǎo)入stl庫(kù)，而崩潰的地方是很早的代碼，直接包含的是stl庫(kù)文件，引起不同編譯單元中對(duì)這個(gè)容器大小認(rèn)識(shí)不一致，運(yùn)行時(shí)崩潰。
結(jié)論是，如果在項(xiàng)目中使用stl庫(kù)，那么將所有常用的stl頭文件都寫在一個(gè)std_inc.h中，在使用stl的模塊中包含該文件，而不是其他，并建立預(yù)編譯頭導(dǎo)入該文件，就能避免出現(xiàn)類似的問(wèn)題。
出bug的時(shí)候，完全不知如何下手，只好完全依賴更NB的同學(xué)，看著人家把崩潰的代碼拷到剛創(chuàng)建對(duì)象的地方，調(diào)試未崩，然后再在創(chuàng)建對(duì)象的地方調(diào)用崩潰代碼所屬的函數(shù)，調(diào)試崩潰。翻到我寫的類的頭文件中include的幾行說(shuō)，stl容器大小不一致。
看得我是一臉慚愧。


3.
我蠻喜歡看包子山同學(xué)的GWeekly系列，不過(guò)他最近都不更新了。每周都寫博我是抗不住的，每月勒令自己的話，還是能嘮叨些文字的。仿照GWeekly的命名，我也來(lái)一個(gè)month-flow系列吧，實(shí)在沒(méi)有成體形的內(nèi)容可寫的情況下，每月必定嘮叨一篇。