• <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>

            冷夜 C++ 小棧

            關(guān)于C++的一些經(jīng)驗(yàn)與心得,還會有一些技術(shù)文摘

              C++博客 :: 首頁 :: 聯(lián)系 :: 聚合  :: 管理
              6 Posts :: 5 Stories :: 12 Comments :: 0 Trackbacks

            常用鏈接

            留言簿(10)

            我參與的團(tuán)隊(duì)

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            一個有趣的現(xiàn)象,摘自CSDN 吹云Blog《C++從零開始(十二)——何謂面向?qū)ο缶幊趟枷搿吩?/FONT>http://blog.csdn.net/chuiyun/archive/2004/11/26/194722.aspx

                之所以摘錄這段文章,是因?yàn)槲移婀窒旅娴睦泳谷徽娴哪軌蚓幾g通過--在引用的文件中篡改類的private為public就可以直接訪問私有變量,而且能夠正常訪問和賦值。
                下面是摘錄的原文,有興趣的朋友不妨也試試編個代碼試驗(yàn)一下。

            -------------------------------------------------------------------

            封裝

                先來看現(xiàn)在在各類VC教程中關(guān)于對象的講解中經(jīng)常能看見的如下的一個類的設(shè)計(jì)。
                class Person
                { private: char m_Name[20]; unsigned long m_Age; bool m_Sex;
                  public:  const char* GetName() const;  void SetName( const char* );
                           unsigned long GetAge() const; void SetAge( unsigned long );
                           bool GetSex() const;          void SetSex( bool );
                };
                上面將成員變量全部定義為private,然后又提供三對Get/Set函數(shù)來存取上面的三個成員變量(因?yàn)樗鼈兪莗rivate,外界不能直接存取),這三對函數(shù)都是public的,為什么要這樣?那些教材將此稱作封裝,是對類Person的內(nèi)部內(nèi)存布局的封裝,這樣外界就不知道其在內(nèi)存上是如何布局的并進(jìn)而可以保證內(nèi)存的有效性(只由類自身操作其實(shí)例)。
                首先要確認(rèn)上面設(shè)計(jì)的荒謬性,它是正宗的“有門沒鎖”毫無意義。接著再看所謂的對內(nèi)存布局的封裝。回想在《C++從零開始(十)》中說的為什么每個要使用類的源文件的開頭要包含相應(yīng)的頭文件。假設(shè)上面是在Person.h中的聲明,然后在b.cpp中要使用類Person,本來要#include "Person.h",現(xiàn)在替換成下面:
                class Person
                { public: char m_Name[20]; unsigned long m_Age; bool m_Sex;
                  public: const char* GetName() const;  void SetName( const char* );
                          unsigned long GetAge() const; void SetAge( unsigned long );
                          bool GetSex() const;          void SetSex( bool );
                };
                然后在b.cpp中照常使用類Person,如下:
                Person a, b; a.m_Age = 20; b.GetSex();
                這里就直接使用了Person::m_Age了,就算不做這樣蹩腳的動作,依舊#include "Person.h",如下:
                struct PERSON { char m_Name[20]; unsigned long m_Age; bool m_Sex; };
                Person a, b; PERSON *pP = ( PERSON* )&a; pP->m_Age = 40;
                上面依舊直接修改了Person的實(shí)例a的成員Person::m_Age,如何能隱藏內(nèi)存布局?!請回想聲明的作用,類的內(nèi)存布局是編譯器生成對象時(shí)必須的,根本不能對任何使用對象的代碼隱藏有關(guān)對象實(shí)現(xiàn)的任何東西,否則編譯器無法編譯相應(yīng)的代碼。
                那么從語義上來看。Person映射的不是真實(shí)世界中的人的概念,應(yīng)該是存放某個數(shù)據(jù)庫中的某個記錄人員信息的表中的記錄的緩沖區(qū),那么緩沖區(qū)應(yīng)該具備那三對Get/Set所代表的功能嗎?緩沖區(qū)是緩沖數(shù)據(jù)用的,緩沖后被其它操作使用,就好像箱子,只是放東西用。故上面的三對Get/Set沒有存在的必要,而三個成員變量則不能是private。當(dāng)然,如果Person映射的并不是緩沖區(qū),而在其它的世界中具備像上面那樣表現(xiàn)的語義,則像上面那樣定義就沒有問題,但如果是因?yàn)閷?nèi)存布局的封裝而那樣定義類則是大錯特錯的。
                上面錯誤的根本在于沒有理解何謂封裝。為了說明封裝,先看下MFC(Microsoft Foundation Class Library——微軟功能類庫,一個定義了許多類的庫文件,其中的絕大部分類是封裝設(shè)計(jì)。關(guān)于庫文件在說明SDK時(shí)闡述)中的類CFile的定義。從名字就可看出它映射的是操作系統(tǒng)中文件的概念,但它卻有這樣的成員函數(shù)——CFile::Open、CFile::Close、CFile::Read、CFile::Write,有什么問題?這四個成員函數(shù)映射的都是對文件的操作而不是文件所具備的功能,分別為打開文件、關(guān)閉文件、從文件讀數(shù)據(jù)、向文件寫數(shù)據(jù)。這不是和前面說的成員函數(shù)的語義相背嗎?上面四個操作有個共性,都是施加于文件這個資源上的操作,可以將它們叫做“被功能”,如文件具有“被打開”的功能,具有“被讀取”的功能,但應(yīng)注意它們實(shí)際并不是文件的功能。
                按照原來的說法,應(yīng)該將文件映射為一個結(jié)構(gòu),如FILE,然后上面的四個操作應(yīng)映射成四個函數(shù),再利用名字空間的功能,如下:
                namespace OFILE
                {
                    bool Open( FILE&, … );  bool Close( FILE&, … );
                    bool Read( FILE&, … );  bool Write( FILE&, … );
                }
                上面的名字空間OFILE表示里面的四個函數(shù)都是對文件的操作,但四個函數(shù)都帶有一個FILE&的參數(shù)。回想非靜態(tài)成員函數(shù)都有個隱藏的參數(shù)this,因此,一個了不起的想法誕生了。
                將所有對某種資源的操作的集合看成是一種資源,把它映射成一個類,則這個類的對象就是對某個對象的操作,此法被稱作封裝,而那個類被稱作包裝類或封裝類。很明顯,包裝類映射的是“對某種資源的操作”,是一抽象概念,即包裝類的對象都是無狀態(tài)對象(指邏輯上應(yīng)該是無狀態(tài)對象,但如果多個操作間有聯(lián)系,則還是可能有狀態(tài)的,但此時(shí)它的語義也相應(yīng)地有些變化。如多一個CFile::Flush成員函數(shù),用于刷新緩沖區(qū)內(nèi)容,則此時(shí)就至少有一個狀態(tài)——緩沖區(qū),還可有一個狀態(tài)記錄是否已經(jīng)調(diào)用過CFile::Write,沒有則不用刷新)。
                現(xiàn)在應(yīng)能了解封裝的含義了。將對某種資源的操作封裝成一個類,此包裝類映射的不是世界中定義的某一“名詞性概念”,而是世界的“動詞性概念”或算法中“對某一概念的操作”這個人為定出來的抽象概念。由于包裝類是對某種資源的操作的封裝,則包裝類對象一定有個屬性指明被操作的對象,對于MFC中的CFile,就是CFile::m_hFile成員變量(類型為HANDLE),其在包裝類對象的主要運(yùn)作過程(前面的CFile::Read和CFile::Write)中被讀。
                有什么好處?封裝提供了一種手段以將世界中的部分“動詞性概念”轉(zhuǎn)換成對象,使得程序的架構(gòu)更加簡單(多條“動詞性概念”變成一個“名詞性概念”,減少了“動詞性概念”的數(shù)量),更趨于面向?qū)ο蟮木幊趟枷搿?BR>    但應(yīng)區(qū)別開包裝類對象和被包裝的對象。包裝類對象只是個外殼,而被包裝的對象一定是個具有狀態(tài)的對象,因?yàn)椴僮骶褪歉淖冑Y源的狀態(tài)。對于CFile,CFile的實(shí)例是包裝類對象,其保持著一個對被包裝對象——文件內(nèi)核對象(Windows操作系統(tǒng)中定義的一種資源,用HANDLE的實(shí)例表征)——的引用,放在CFile::m_hFile中。因此,包裝類對象是獨(dú)立于被包裝對象的。即CFile a;,此時(shí)a.m_hFile的值為0或-1,表示其引用的對象是無效的,因此如果a.Read( … );將失敗,因?yàn)椴僮魇┘拥馁Y源是無效的。對此,就應(yīng)先調(diào)用a.Open( … );以將a和一特定的文件內(nèi)核對象綁定起來,而調(diào)用a.Close( … );將解除綁定。注意CFile::Close調(diào)用后只是解除了綁定,并不代表a已經(jīng)被銷毀了,因?yàn)閍映射的并不是文件內(nèi)核對象,而是對文件內(nèi)核對象操作的包裝類對象。
                如果仔細(xì)想想,就會發(fā)現(xiàn),老虎能夠吃兔子,兔子能夠被吃,那這里應(yīng)該是老虎有個功能是“吃兔子”還是多個兔子的包裝類來封裝“吃兔子”的操作?這其實(shí)不存在任何問題,“老虎吃兔子”和“兔子被吃”完全是兩個不同的操作,前者涉及兩種資源,后者只涉及一種資源,因此可以同時(shí)實(shí)現(xiàn)兩者,具體應(yīng)視各自在相應(yīng)世界中的語義。如果對于真實(shí)世界,則可以簡略地說老虎有個“吃”的功能,可以吃“肉”,而動物從“肉”和“自主能動性”多重繼承,兔子再從動物繼承。這里有個類叫“自主能動性”,指動物具有意識,能夠自己動作,這在C++中的表現(xiàn)就是有成員函數(shù)的類,表示有功能可以被操作,但收音機(jī)也具有調(diào)臺等功能,難道說收音機(jī)也能自己動?!這就是世界的意義——運(yùn)轉(zhuǎn)。

            (本文是本人以baodi_z的網(wǎng)名原發(fā)表在CSDN的個人BLOG,原文發(fā)表于 2004年12月09日 2:09 PM )

            posted on 2005-09-12 23:35 冷夜 閱讀(2157) 評論(8)  編輯 收藏 引用 所屬分類: C++ 經(jīng)驗(yàn)與技巧冷夜文摘

            Feedback

            # re: 關(guān)于封裝--一個有趣的C++例子 2005-09-13 09:28 atempcode
            有什么奇怪。本來private就是compile time check, 不是 run time check.  回復(fù)  更多評論
              

            # re: 關(guān)于封裝--一個有趣的C++例子 2005-09-13 20:14 冷夜
            呵呵,這個我沒有研究透,所以剛開始覺得很意外  回復(fù)  更多評論
              

            # re: 關(guān)于封裝--一個有趣的C++例子 2005-09-13 23:15 可冰
            其實(shí)他這個方式不一定有效,因?yàn)镃++的類成員的內(nèi)存布局可以與聲明的順序不一樣,而不象C的結(jié)構(gòu)中的成員一樣,要完全的一致.所以他這樣的實(shí)現(xiàn)有賴于編譯器的實(shí)現(xiàn),而不能得到語言級的保證.  回復(fù)  更多評論
              

            # re: 關(guān)于封裝--一個有趣的C++例子 2005-09-13 23:42 冷夜
            樓上說的有理  回復(fù)  更多評論
              

            # re: 關(guān)于封裝--一個有趣的C++例子 2005-09-16 10:42 ffox
            class Person
            { private: char m_Name[20]; unsigned long m_Age; bool m_Sex;
            public: const char* GetName() const; void SetName( const char* );
            unsigned long GetAge() const; void SetAge( unsigned long );
            bool GetSex() const; void SetSex( bool );
            };
            person類的設(shè)計(jì)本來就有問題,我的理解:把變量放在private中,又在public中對三個變量進(jìn)行操作,這樣和把變量聲明稱public又有什么區(qū)別?不都是要對變量進(jìn)行操作嗎,既然把變量放在private中,就要把對變量操作的member也同樣放在private中.  回復(fù)  更多評論
              

            # re: 關(guān)于封裝--一個有趣的C++例子 2005-09-18 08:44 FrameSniper
            沒什么可奇怪的!  回復(fù)  更多評論
              

            # re: 關(guān)于封裝--一個有趣的C++例子 2005-09-18 17:48 可冰
            @ffox:
            這樣是將對變量的讀寫操作封裝起來以接口的形式提供,它在提供了一定的接口一致性.如果以后要在讀寫變量的操作內(nèi)加入其它的操作,那么原有的代碼就可以不加任何修改,只改這樣的接口就行了.也就是對外部封閉了細(xì)節(jié),使編程簡單一點(diǎn).
            但我也覺得不能用"一刀切"的方式將所有的成員變量都加以這樣的封裝,這樣無疑會使代碼增長(而且可能還有我所不知道的缺點(diǎn)).
            所以,可以作如下的總結(jié):
            對于要對外部提供應(yīng)用的變量,最好以接口的形式提供;而如果只是內(nèi)部用的話,在用途只是用于保存變量的值的話,直接聲明為public會好一些.
            具體的情況還要加以區(qū)別對待,根據(jù)實(shí)際情況加以應(yīng)用.  回復(fù)  更多評論
              

            # re: 關(guān)于封裝--一個有趣的C++例子 2007-07-18 17:13 pchobby
            看下面阿:
            class Date{
            private:
            int year,month,day; //日期類的 年月日
            pubilc:
            void setdate(int& y,int& m,int& d) const{
            year=y;month=m;day=d; //向變量賦值
            }

            //假如我想知道現(xiàn)在是什么日期,怎么辦?
            //倘若真要想那樣封裝,我怎么得到日期呢?直接放在public下面?!
            };

            關(guān)于篡改的問題,說實(shí)話俺也很驚訝,要知道兩次聲明的可不一樣啊。。。。。  回復(fù)  更多評論
              

            一本大道久久东京热无码AV| 亚洲精品蜜桃久久久久久| 精品国产99久久久久久麻豆| 色欲综合久久躁天天躁| 99久久精品国产一区二区| 亚洲人成精品久久久久| 99精品久久精品一区二区| 99久久精品国产一区二区| 日本WV一本一道久久香蕉| 久久国产高潮流白浆免费观看| 94久久国产乱子伦精品免费| 少妇熟女久久综合网色欲| 欧美激情精品久久久久| 久久精品青青草原伊人| 久久综合丁香激情久久| 成人综合久久精品色婷婷| 婷婷综合久久狠狠色99h| 国产精品一区二区久久精品涩爱| 久久国产高清字幕中文| 久久夜色精品国产噜噜亚洲a| 国产精品久久久久久久久免费| 久久综合一区二区无码| 国内精品伊人久久久久av一坑| 亚洲精品综合久久| 观看 国产综合久久久久鬼色 欧美 亚洲 一区二区 | 亚洲国产成人久久精品动漫| 欧美精品福利视频一区二区三区久久久精品| 婷婷久久五月天| 久久久国产一区二区三区| 国产精品久久精品| 亚洲AV日韩AV永久无码久久| 一本大道久久东京热无码AV| 国产一区二区三精品久久久无广告| 久久66热人妻偷产精品9| 亚洲精品乱码久久久久久自慰| 中文成人久久久久影院免费观看| 青草影院天堂男人久久| 欧美精品一区二区精品久久| 久久福利青草精品资源站免费| 久久精品国产99国产电影网| 99久久777色|