• <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>
            posts - 58,  comments - 75,  trackbacks - 0

            ??? 接口,通俗的來說就是定義了一組要實現(xiàn)的功能,這些功能被表現(xiàn)為一組函數(shù),
            這些函數(shù)在語義上給定接口實現(xiàn)類的責(zé)任。
            ??? C++中常用的定義接口的方法是純虛類。但是定義的函數(shù)卻是要確定操作類型的
            但是從接口在語義上的考慮,其實是不需要的。
            ??? 用模板技術(shù)來改變。
            ??? 定義一個接口類,在類中只定義接口函數(shù),這些函數(shù)是Client要使用的,這個
            類是一個模板類,如下
            ??? template< typename T >
            ??? class Interface
            ??? {
            ??? public:
            ??????? template< typename T1 >
            ??????? void Fun( const T &t );
            ???
            ??????? ......
            ??? };
            ??? 這種方式解決了接口函數(shù)被類型限制。
            ??? 模板類的參數(shù)是一個繼承類,這個繼承類完成實際的操作。實體類的定義如下
            ??? class C : public Interface< C >
            ??? {
            ??????? ......
            ??? };

            ??? 子類去一個個的實例話其實很不好,也不符合一般C++的編程方法。由于在模板
            編程的情況下,更注重的是語義的符合,所以可以在子類中使用重載的方法去實現(xiàn)對
            不同類型的實際處理(畢竟沒有類的編寫者知道自己這個類要處理的類型)。那么可
            以載接口類中寫些代碼,來調(diào)用子類的函數(shù),這種調(diào)用實際上在語義上定義了子類要
            實現(xiàn)的責(zé)任。上面的接口的定義變成下面這個樣子
            ??? template< typename T >
            ??? class Interface
            ??? {
            ??? public:
            ??????? T* This( void ) { return static_cast< T* >( this ); }

            ??????? template< typename T1 >
            ??????? void Fun( const T &t )
            ??????? {
            ??????????? this->This()->Ope( t );
            ??????? }
            ???
            ??????? ......
            ??? };
            ???
            ??? 這樣,子類只用實現(xiàn)對不同類型的處理的Ope函數(shù)了,對外的公共接口還是一樣的。
            顯現(xiàn)中要講基類編程子類的友員,Ope定義在protected或private作用域中。??

            posted on 2007-01-13 18:06 walkspeed 閱讀(2287) 評論(0)  編輯 收藏 引用

            只有注冊用戶登錄后才能發(fā)表評論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理



            <2007年6月>
            272829303112
            3456789
            10111213141516
            17181920212223
            24252627282930
            1234567

            常用鏈接

            留言簿(4)

            隨筆分類(64)

            隨筆檔案(58)

            文章分類(3)

            文章檔案(3)

            相冊

            收藏夾(9)

            C++零碎

            好友

            搜索

            •  

            積分與排名

            • 積分 - 160866
            • 排名 - 163

            最新評論

            閱讀排行榜

            評論排行榜

            无码专区久久综合久中文字幕| 久久无码国产专区精品| 久久精品人妻中文系列| 狠狠干狠狠久久| 久久亚洲电影| 777午夜精品久久av蜜臀| 久久精品国产一区| 久久高潮一级毛片免费| 99国产欧美久久久精品蜜芽 | 久久青青草原国产精品免费| 久久久久无码精品| 久久狠狠色狠狠色综合| 久久久无码精品午夜| 久久久一本精品99久久精品88| 久久国产成人午夜aⅴ影院 | 久久亚洲春色中文字幕久久久| 久久综合成人网| 狠狠色丁香婷婷久久综合五月 | 久久亚洲AV成人无码国产 | 久久久久亚洲AV无码观看| 欧洲人妻丰满av无码久久不卡| 精品久久久久一区二区三区| 7777久久久国产精品消防器材| 亚洲国产精品热久久| 久久99国产亚洲高清观看首页| 久久男人AV资源网站| 99国产欧美精品久久久蜜芽| 狠狠色丁香久久婷婷综合图片| 久久国产免费直播| 丁香久久婷婷国产午夜视频| 久久国产福利免费| 精品国产一区二区三区久久久狼| 久久国产精品99国产精| 99蜜桃臀久久久欧美精品网站| 久久成人18免费网站| 办公室久久精品| 精品久久777| 精品久久香蕉国产线看观看亚洲| 久久精品夜夜夜夜夜久久| 午夜精品久久久久久99热| 99久久这里只精品国产免费|