• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            Creative Commons License
            本Blog采用 知識共享署名-非商業性使用-禁止演繹 3.0 Unported許可協議 進行許可。 —— Fox <游戲人生>

            游戲人生

            游戲人生 != ( 人生 == 游戲 )
            站點遷移至:http://www.yulefox.com。請訂閱本博的朋友將RSS修改為http://feeds.feedburner.com/yulefox
            posts - 62, comments - 508, trackbacks - 0, articles - 7

            簡單的屬性結構設計

            Posted on 2008-12-28 02:44 Fox 閱讀(2020) 評論(4)  編輯 收藏 引用 所屬分類: T技術碎語

            本文最早發布于我的個人主頁

            一般的RPG游戲中,玩家角色、NPC、物品、場景等一般都具有為數眾多的各種屬性,使用C++編碼時,很容易考慮設計成為大量的成員變量和相應的存取函數:

            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;
            };

            乍一看,非常清晰明了。在一個稍顯復雜的項目中,想記住、甚至找到每一個屬性是非常難的,況且除了屬性,還有大量的邏輯處理,甚至是不同項目間的數據交互,比如將屬性的數據庫存取。這么做的缺點大致有這么幾點:

            1. 屬性沒有明確分門別類,尤其在多人協作、多模塊編寫時,往往上面一批、下面一批,甚至有重復屬性、廢棄屬性,難于管理和把握;

            2. 對于數據庫存取,需要寫單獨的存取接口,而且一旦屬性有增減、修改,存取接口要隨之修改;

            3. 通過接口函數進行簡單的屬性存取面臨大量的堆棧保存,即使使用內聯或宏定義,也是治標不治本。

            針對上述問題,我的思路也比較簡單:對基本類型數據進行二次封裝。

            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;
                ...
            };
             

            之所以提到基本類型數據,主要緣于基本類型構成的結構可以通過sizeof運算符直接確定,而像類對象等組合類型,其深拷貝、賦值、操作及賦值等邏輯則較為復雜,一般無法統一處理。

            以上面的tagDBAttrs為例,對于基本類型數據處理具有非常大的優勢,尤其在數據整體存取時,此外,增減基本類型屬性也比較簡單,而且不需要重寫Get/Set接口,同時方便了對屬性的分門別類處理。


            此處順便談談關于開發中的一些雜的體會。

            對于工作不久的同學而言,拿到一個任務有可能出現以下兩種情況:

            1. 以快速開發為重,前期進展較快,在小型模塊開發中順風順水,但在面對復雜任務時,因為對前期設計重視不足,后期會不斷調整代碼,甚至在基本功能開發結束后,因為邏輯架構問題,導致bug隱患較多較深,容易陷入泥沼,痛苦掙扎;

            2. 隨時隨處追求代碼結構的優美和執行效率的優化,精益求精,往往在前期設計上花費過多的心思,以達到較合理的邏輯結構,甚至拖延整個項目的開發進度,這種同學一般說來,代碼質量較高,后期bug較少。

            其實,上面說的就是我自己,我剛開始工作的時候,上面給我一個編寫獨立工具的任務,當時急于表現,缺乏項目實戰經驗,為編碼而編碼,邏輯結構不注重擴展性,設計不合理,在進行到后期時,面對出現的新需求無法應對,導致最后推到重來。

            后來,慢慢接受了注重前期設計的觀念,更因為自己的完美情結和代碼潔癖,不僅經常調整自己編碼中不優美的片段,甚至越俎代庖去修改其他同事的代碼,追求處處的高效,耗費大量時間精力,難以自拔。

            在任何一個項目中,都有輕重主次之分,也就是所謂的『8020原則』,關于『8020原則』怎么理解都行,我的理解就是,每個項目中的效率瓶頸是20%的核心代碼,80%的時間和工作重心應該放到這20%的核心代碼上。放到一個小的模塊中也是這樣,應該確定工作重心,在開發進度的限制下,對核心代碼精益求精,對非效率瓶頸可以適當減少側重。

            對于新人,最難的就是從整體的高度確定20%的工作重心,這主要依賴于自身素質的提高和開發經驗的積累。而對需求深入細致的分析和對邏輯精益求精的設計本身可以訓練一個人分析問題、解決問題的能力。

            總結一下的話,也正是我們項目組歷來所倡導和堅持的:

            1. 精益求精;

            2. 細節決定成敗,態度制約能力。

            Feedback

            # re: 簡單的屬性結構設計  回復  更多評論   

            2008-12-28 09:33 by 萬連文
            struct tagDBAttrs
            {
            long lA;
            long lB;
            ...
            long lN;
            };

            This is POD.

            # re: 簡單的屬性結構設計  回復  更多評論   

            2008-12-28 10:01 by abettor
            博主的文章好啊!類似的問題有人提過,他說他們有一個類里有上百個屬性,而且命名大都是縮寫(據說因為是行業術語),看起來相當痛苦。當然,最痛苦的是最后還要把這東西搞成接口,因為要在這個類上實現多臺。于是,他要整出一個具有幾百個方法的接口,然后再在其實現類里一一實現這些方法。簡直讓人吐血!

            # re: 簡單的屬性結構設計  回復  更多評論   

            2009-01-08 14:26 by getborn
            其實一個類的成員函數中出現Get...Set的接口說明程序結構沒有設計好。一個類除了封裝數據之外就是封裝行為,而Get,Set這2個是不屬于對象行為的。

            面向對象可以很好地解決摟主所說的第2個缺點,而Get,Set就破壞了面向對象的封裝性,所以會造成第2個問題。

            我原來也是寫的有Get,Set,后來我發現這是從C語言帶過來的毛病,要從另外的角度進行封裝。比如樓主的游戲,不要單獨為了某個東西的屬性而1個類,要把角色,場景的行為放到類接口中,而Get,Set的操作隱藏到類里面。

            # re: 簡單的屬性結構設計  回復  更多評論   

            2009-08-17 19:24 by 李現民
            把大量的get, set函數都寫出來了,通常這意味了完成沒有封裝,或者說從訪問性上這樣做跟將該變量聲名為public是差不多的,我覺得根本的解決方案還是要保持類的數據成員數目比較小才好
            蜜臀久久99精品久久久久久小说| 日韩久久久久中文字幕人妻| 色婷婷综合久久久久中文一区二区| 久久精品国产亚洲AV蜜臀色欲| 一本久道久久综合狠狠爱| 日本欧美久久久久免费播放网| 99999久久久久久亚洲| 久久精品国产亚洲7777| 无码日韩人妻精品久久蜜桃| 伊人久久大香线蕉影院95| 亚洲国产精品狼友中文久久久| 亚洲精品乱码久久久久久蜜桃图片| 亚洲综合久久综合激情久久| yy6080久久| 久久se这里只有精品| 久久国产热精品波多野结衣AV | 久久久综合香蕉尹人综合网| 久久精品国产乱子伦| 9999国产精品欧美久久久久久| 久久精品桃花综合| 久久最近最新中文字幕大全| 亚洲乱码中文字幕久久孕妇黑人| 久久性精品| 久久无码国产| 欧美精品福利视频一区二区三区久久久精品 | 久久久久国产精品人妻| 国产精品免费久久久久影院| 无码国内精品久久人妻| 欧美亚洲国产精品久久久久| 久久精品国产精品亚洲人人| 91精品国产91久久久久久青草| 久久99久久99精品免视看动漫| 中文无码久久精品| 亚洲狠狠婷婷综合久久久久| 午夜精品久久久久久久无码| 久久亚洲AV无码西西人体| 成人精品一区二区久久| 久久免费线看线看| 一本一道久久精品综合| 久久伊人亚洲AV无码网站| 久久精品亚洲福利|