對于C/S類型的項目，總會有很多這樣的類層次體系：
CItemMngS是服務(wù)器端的類，CItemMngC是客戶端的類。CItemMngBase是一個已經(jīng)實現(xiàn)了固有邏輯功能的類，包含了單機項目所需要的最基本代碼。然后，CItemMngS將繼承這個類，并對基類虛函數(shù)作出修改，增加網(wǎng)絡(luò)發(fā)包的代碼。CItemMngC也將繼承這個類，同樣也對基類虛函數(shù)作出修改，增加圖形表現(xiàn)的代碼。
令人不爽的問題是，基類提供的最小接口中，徹底實現(xiàn)了和網(wǎng)絡(luò)、圖形無關(guān)的邏輯功能，沒有任何表現(xiàn)的，純數(shù)據(jù)操作的。然后派生類將重載這些接口（虛函數(shù)），將基類的那套代碼copy過來，并在合適的地方添加合適的網(wǎng)絡(luò)代碼或者圖形代碼。
重復(fù)這樣的操作，引起的一個問題是，在基類中的固有代碼還有什么意義，因為每個派生類都需要在固有代碼中嵌入一些特殊的代碼；另外一點是，這么copy和修改，誰還能保證派生類有好好履行基類所固定的功能的本質(zhì)？
這個問題我當(dāng)前所知應(yīng)對方案有兩種，一種是：
這種方式已經(jīng)能保證派生類利用并履行基類所提供的邏輯功能，但是插入的代碼只能在基類邏輯功能完成后（一般不會放在前面的），但是如果派生類要把特殊代碼插放在中間的話，就只好把邏輯功能的代碼重溫一遍了。
另一種方案作為這個方案的改進，是利用監(jiān)聽器模式：
利用這種模式，派生類根本就不需要關(guān)心基類到底提供了什么邏輯功能，并能在添加特殊處理的地方添加特殊處理。不過這種方案的一個問題是，你多數(shù)時候沒有辦法一開始就能確定所有需要的OnXXXX的函數(shù)，而是一個逐步向基類添加的過程。

我想要有效的解決這個問題應(yīng)該是依靠某個設(shè)計模式。
好了，這就是我目前掌握的笨拙方案，期待能在回復(fù)中看到有創(chuàng)意的設(shè)計。^_^