• <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>
            隨筆 - 119  文章 - 290  trackbacks - 0

            博客搬家了哦,請移步
            叫我abc

            常用鏈接

            留言簿(12)

            隨筆分類

            我的博客

            搜索

            •  

            積分與排名

            • 積分 - 303713
            • 排名 - 84

            最新評論

            閱讀排行榜

            之所以說這個,是因為之前的一篇文章http://www.shnenglu.com/darkdestiny/archive/2006/05/31/7986.html
            Arcrest給我一些留言,我特別在意的是他說到的第五條,使用文件這種方法很局限,缺點太多,最重要的等于是給這個類強加了一個讀取文件的依賴。如果參數太長,應該考慮重構,用類來替代,至于類實例的初始化,從文件讀取還是從網絡讀取,那是新的類的職責了.
            類的初始化,我一直堅持在構造函數中完全進行,而不是放到類似于init函數中等待顯式的調用.基于這樣的邏輯:一個實例,他誕生是因為需要他,那么他就應該在誕生之時完全做好準備,此時構造和init是連續執行的,那么就應該把init納入構造函數中.一種反對的意見是構造函數可能會拋出異常,使得類的構造是不完整的,所以把初始化推到init,會是一個完整的類.對于這種反對意見我總是有點窒息,因為我缺少關于不完整構造的知識,好像在《有效C++》里面提到過,不過我沒有找到.
            在我所做的一些工作中,每個類的初始化是依賴一個ini文件,向構造函數傳遞一個文件名,然后讀取key-value對,所以一直寫有一個ConfigFile的類處理這種事情,不知道是不是Arcrest所說的文件依賴,畢竟我的水平還不是太能理解過于簡練和抽象的表達.
            如果參數太長,應該考慮重構,用類來替代,至于類實例的初始化,從文件讀取還是從網絡讀取,那是新的類的職責了.我不太理解"用類來代替"的意思,不過后面提到的職責使我想到了一個接口.
            ?1//?接口,從某種數據源中讀取指定字段的值
            ?2class??StreamReader
            ?3{
            ?4public:
            ?5????virtual??~StreamReader();
            ?6????virtual??const??string&??GetType()?const;
            ?7????virtual??void??Open(const??string??&src);
            ?8????virtual??void??Close();
            ?9????virtual??void??GetValue(const??string??&key,??int??&value)?const;
            10????virtual??void??GetValue(const??string??&key,??float??&value)?const;
            11????virtual??void??GetValue(const??string??&key,??string??&value)?const;
            12}
            ;
            那么根據可能的不同的數據源,比如ini文件,或者xml文件,或者二進制文件,又或者網絡,都可以寫出相應的子類.然后由需要初始化的類創建StreamReader實例,從傳入構造函數的字符串打開相應的源,進行讀取.
            那么應該創建哪種源的StreamReader的實例呢?需要初始化的類不應該負責判斷這些東西吧?是的,不需要,所以需要包裝一個負責判斷這些區別的類.
            ?1//?負責注冊,管理,判斷,打開
            ?2//?單件模式
            ?3class??StreamReaderManager
            ?4{
            ?5public:
            ?6???static?StreamReaderManager&??GetSingleton();
            ?7???void??Register(StreamReader??&sr);
            ?8//?這個就是負責判斷源類型并創建適當StreamReader的地方
            ?9???StreamReader*??Open(const??string??&src);
            10}
            ;
            利用這個manager,在需要初始化的類里面就可以比較好看的初始化你那海量的成員變量了.

            ^_^,感謝Arcrest
            posted on 2006-07-02 13:12 LOGOS 閱讀(910) 評論(7)  編輯 收藏 引用

            FeedBack:
            # re: 談類的初始化 2006-07-03 17:57 pandaxiaoxi
            你好,我剛開始寫blog,發代碼格式很不好看,你的代碼怎么那么好看哪?能教教我怎么做的嗎?  回復  更多評論
              
            # re: 談類的初始化 2006-07-03 18:16 LOGOS
            @pandaxiaoxi
            在編輯文章的時候,網站的編輯工具中有一個"代碼"的按鈕,點擊那個你就明白了  回復  更多評論
              
            # re: 談類的初始化 2006-07-04 10:37 天爬者
            看到你處理用文件初始化類的代碼

            我們工程中也大量遇到!原來我們也曾采用過類似你代碼里面的方案

            但是現在我們采用的是boost序列化的方案來解決

            基本上用序列化對比你的方法3個差別

            1.一般來說既然有loadfromfile的過程 就還需要寫savetofile,boost 把讀寫的操作統一了。

            2.使用鍵值存取變量導致每個變量都需要有一個 全局唯一字符串的名稱,并且使用時候必須知道型別

            3.boost封裝了標準容器的序列化,而普通方法遇到的時候則必須自己書寫迭代讀寫  回復  更多評論
              
            # re: 談類的初始化 2006-07-04 22:11 笑笑生
            boost序列化很方便  回復  更多評論
              
            # re: 談類的初始化 2006-07-05 10:23 LOGOS
            謝謝兩位.我搜索了一些boost序列化的文章,的確是挺簡潔的.  回復  更多評論
              
            # re: 談類的初始化 2006-07-12 15:41 Arcrest
            那個參數太長,意思可以考慮把之間有相互關系的參數合并到一個類中作為成員變量,然后傳入類的實例

            針對接口編程確實才是真正的OOP
            用StreamReader/Writer,使得操作配置文件的都針對這個接口來操作,而不關心數據從哪兒來,當然個人覺得,GetValue/SetValue的接口應該和Open/Save分開,打開數據和保存數據的操作一般是開始和結束的,而使用GetValue/SetValue則可能到處都使用,不過還是看你應用了,抽象和分離職責是OOP設計中的最難的。

            設計個好的比較通用的配置庫確實不容易,以前參考過apache的jakarta commons的Configuration的項目,但是終覺得對C++不適合,缺少的東西太多,人家Java畢竟不只是語言,而更是一個平臺。 也看過eMule等開源軟件的配置設計,感覺五花八門,什么都有,得出的結論是針對具體的項目寫,通用的太難。

            以上大俠提到的boost的serialization還沒看過,是在io的庫中嗎?不過boost的都是好東東的說,:)
              回復  更多評論
              
            # re: 談類的初始化 2006-07-13 18:49 LOGOS
            嗯.我已經下了boost練習了一下.
            發現它不能適合類的初始化,因為初始化的數據是手工編輯的.
            boost/serialization的數據格式有3,binary,txt,xml.
            binary的基本上不指望能手工編輯.
            txt的話基本上看不明白它的結構是如何安排的,也不能手工編輯.
            xml的話,雖然有key-value對,但是boost/serialization并不關心配對情形,它參照的只是先后順序,也就是說:
            <key1>5</key1> 和 <key2>5</key2>
            <key2>6</key2> <key1>6</key1>
            是完全一樣的....
            順序過于嚴格,而key的數量又太多的話,由于編輯數據產生的奇異狀況估計沒那么容易捕獲.

            不過對于序列化(非初始化),的確是一個相當棒的方案.  回復  更多評論
              
            国产精品免费久久久久久久久| 久久精品99久久香蕉国产色戒| 久久综合狠狠综合久久激情 | 国产精品成人久久久久三级午夜电影| 国产精品99久久久久久www| 久久91精品综合国产首页| 久久久久青草线蕉综合超碰| 伊人久久大香线蕉av不卡| 久久er热视频在这里精品| 色综合久久中文字幕综合网| 久久天天躁狠狠躁夜夜96流白浆| 久久国产精品免费| 性欧美丰满熟妇XXXX性久久久 | 久久93精品国产91久久综合| 久久精品国产男包| 99久久免费只有精品国产| 婷婷综合久久中文字幕蜜桃三电影 | 一本久道久久综合狠狠躁AV| 久久国产精品久久久| 7777精品伊人久久久大香线蕉| 亚洲国产成人久久综合一| 久久精品亚洲一区二区三区浴池 | 久久精品国产亚洲av高清漫画| 久久伊人中文无码| 99久久精品国产毛片| 久久青青草原精品影院| 久久99精品久久久久久hb无码| 久久九九兔免费精品6| 久久婷婷五月综合97色直播| 国产精品久久久久久久久鸭| 国产亚洲欧美精品久久久| 日本强好片久久久久久AAA | 2020国产成人久久精品| 国产—久久香蕉国产线看观看| 97精品国产97久久久久久免费| 久久精品黄AA片一区二区三区| 日韩精品久久久久久久电影蜜臀 | 精产国品久久一二三产区区别| 亚洲精品99久久久久中文字幕| 亚洲日韩欧美一区久久久久我| 久久婷婷人人澡人人爽人人爱|