本文最早發(fā)布于我的個(gè)人主頁
一般的RPG游戲中，玩家角色、NPC、物品、場景等一般都具有為數(shù)眾多的各種屬性，使用C++編碼時(shí)，很容易考慮設(shè)計(jì)成為大量的成員變量和相應(yīng)的存取函數(shù)：
class CObject
{
public:
long GetAttrA(void) const { return m_lAttrA; }
void SetAttrA(long lVal) { m_lAttrA = lVal; }
long GetAttrB(void) const { return m_lAttrB; }
void SetAttrB(long lVal) { m_lAttrB = lVal; }
...
long GetAttrN(void) const { return m_lAttrN; }
void SetAttrN(long lVal) { m_lAttrN = lVal; }
private:
long m_lAttrA;
long m_lAttrB;
...
long m_lAttrN;
};
乍一看，非常清晰明了。在一個(gè)稍顯復(fù)雜的項(xiàng)目中，想記住、甚至找到每一個(gè)屬性是非常難的，況且除了屬性，還有大量的邏輯處理，甚至是不同項(xiàng)目間的數(shù)據(jù)交互，比如將屬性的數(shù)據(jù)庫存取。這么做的缺點(diǎn)大致有這么幾點(diǎn)：
1. 屬性沒有明確分門別類，尤其在多人協(xié)作、多模塊編寫時(shí)，往往上面一批、下面一批，甚至有重復(fù)屬性、廢棄屬性，難于管理和把握；
2. 對于數(shù)據(jù)庫存取，需要寫單獨(dú)的存取接口，而且一旦屬性有增減、修改，存取接口要隨之修改；
3. 通過接口函數(shù)進(jìn)行簡單的屬性存取面臨大量的堆棧保存，即使使用內(nèi)聯(lián)或宏定義，也是治標(biāo)不治本。
針對上述問題，我的思路也比較簡單：對基本類型數(shù)據(jù)進(jìn)行二次封裝。
struct tagDBAttrs
{
long lA;
long lB;
...
long lN;
};
class CObject
{
public:
const tagDBAttrs& GetDBAttrs(void) const { return m_DBAttrs; }
void SetDBAttrs(const tagDBAttrs& rDBAttrs)
{
memcpy(&m_DBAttrs, rDBAttrs, sizeof(m_DBAttrs));
}
private:
tagDBAttrs m_DBAttrs;
string m_strA;
CObject* m_pObjB;
CShape* m_pShapeC;
...
};
之所以提到基本類型數(shù)據(jù)，主要緣于基本類型構(gòu)成的結(jié)構(gòu)可以通過sizeof運(yùn)算符直接確定，而像類對象等組合類型，其深拷貝、賦值、操作及賦值等邏輯則較為復(fù)雜，一般無法統(tǒng)一處理。
以上面的tagDBAttrs為例，對于基本類型數(shù)據(jù)處理具有非常大的優(yōu)勢，尤其在數(shù)據(jù)整體存取時(shí)，此外，增減基本類型屬性也比較簡單，而且不需要重寫Get/Set接口，同時(shí)方便了對屬性的分門別類處理。
此處順便談?wù)勱P(guān)于開發(fā)中的一些雜的體會。
對于工作不久的同學(xué)而言，拿到一個(gè)任務(wù)有可能出現(xiàn)以下兩種情況：
1. 以快速開發(fā)為重，前期進(jìn)展較快，在小型模塊開發(fā)中順風(fēng)順?biāo)?，但在面對?fù)雜任務(wù)時(shí)，因?yàn)閷η捌谠O(shè)計(jì)重視不足，后期會不斷調(diào)整代碼，甚至在基本功能開發(fā)結(jié)束后，因?yàn)檫壿嫾軜?gòu)問題，導(dǎo)致bug隱患較多較深，容易陷入泥沼，痛苦掙扎；
2. 隨時(shí)隨處追求代碼結(jié)構(gòu)的優(yōu)美和執(zhí)行效率的優(yōu)化，精益求精，往往在前期設(shè)計(jì)上花費(fèi)過多的心思，以達(dá)到較合理的邏輯結(jié)構(gòu)，甚至拖延整個(gè)項(xiàng)目的開發(fā)進(jìn)度，這種同學(xué)一般說來，代碼質(zhì)量較高，后期bug較少。
其實(shí)，上面說的就是我自己，我剛開始工作的時(shí)候，上面給我一個(gè)編寫?yīng)毩⒐ぞ叩娜蝿?wù)，當(dāng)時(shí)急于表現(xiàn)，缺乏項(xiàng)目實(shí)戰(zhàn)經(jīng)驗(yàn)，為編碼而編碼，邏輯結(jié)構(gòu)不注重?cái)U(kuò)展性，設(shè)計(jì)不合理，在進(jìn)行到后期時(shí)，面對出現(xiàn)的新需求無法應(yīng)對，導(dǎo)致最后推到重來。
后來，慢慢接受了注重前期設(shè)計(jì)的觀念，更因?yàn)樽约旱耐昝狼榻Y(jié)和代碼潔癖，不僅經(jīng)常調(diào)整自己編碼中不優(yōu)美的片段，甚至越俎代庖去修改其他同事的代碼，追求處處的高效，耗費(fèi)大量時(shí)間精力，難以自拔。
在任何一個(gè)項(xiàng)目中，都有輕重主次之分，也就是所謂的『8020原則』，關(guān)于『8020原則』怎么理解都行，我的理解就是，每個(gè)項(xiàng)目中的效率瓶頸是20%的核心代碼，80%的時(shí)間和工作重心應(yīng)該放到這20%的核心代碼上。放到一個(gè)小的模塊中也是這樣，應(yīng)該確定工作重心，在開發(fā)進(jìn)度的限制下，對核心代碼精益求精，對非效率瓶頸可以適當(dāng)減少側(cè)重。
對于新人，最難的就是從整體的高度確定20%的工作重心，這主要依賴于自身素質(zhì)的提高和開發(fā)經(jīng)驗(yàn)的積累。而對需求深入細(xì)致的分析和對邏輯精益求精的設(shè)計(jì)本身可以訓(xùn)練一個(gè)人分析問題、解決問題的能力。
總結(jié)一下的話，也正是我們項(xiàng)目組歷來所倡導(dǎo)和堅(jiān)持的：
1. 精益求精；
2. 細(xì)節(jié)決定成敗，態(tài)度制約能力。