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

            積木

            No sub title

              C++博客 :: 首頁 :: 聯系 :: 聚合  :: 管理
              140 Posts :: 1 Stories :: 11 Comments :: 0 Trackbacks

            常用鏈接

            留言簿(1)

            我參與的團隊

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            #

            Facade模式

             (Facade模式)門面模式與Proxy模式其實還是有點相似的。也是主要實現一種功能的封裝。Facade模式,主要是將幾個有相關性的功能操作,封裝到一起,由統一的接口提供。
            使用時,通過該接口即可完成所有相關的功能。此有個好處,就是提高解耦性與增加高聚性。實現中,查處問題也相對方便。
             簡單,代碼不就給了。

            posted @ 2011-05-20 00:39 Jacc.Kim 閱讀(315) | 評論 (0)編輯 收藏

            Proxy模式

             代理模式其,思想倒類似于封裝的概念。主要是將某功能操作通過另一對象,來全權處理。對
            被代理的對象,它不管你是如何處理。它只要結果。比如:對數據的提取。原本可能要經過N個對象共
            同配合,最終取得數據。此時,可以用一個代理對象,來全權處理之。又比如說:我們上網,打開網頁,
            可以通過windows的網絡功能模塊,去解析,并最終打開網頁。同時也可以通過代理,解析并最終打開網
            頁。

             下面是參考代碼
            class Subject
            {
            public:
             virtual void Request() = 0;
            protected:
             Subject(){}
            };

            class ImplSubject
            {
            public:
             virtual void Request(){ //....}
            };

            class Proxy
            {
            public:
             Proxy(){}
             Proxy(Subject* sub){m_pSub = sub;}
            private:
             Subject* m_pSub;
             void Request(){ m_pSub->Request();}
            };

            int main(int argc, char* argv[])
            {
             Subject* sub = new ImplSubject();
             Proxy* p = new Proxy(sub);
             p->Request();
             return 0;
            }

            posted @ 2011-05-20 00:38 Jacc.Kim 閱讀(429) | 評論 (0)編輯 收藏

             

            十:Flyweight模式(即:享元模式)

             說的直觀點,Flyweight模式其實就是實現一個對象緩存池。取對象,優先從該池中取出。而它們的區別在于:從前者中取東西時,如果不存在。則可以新產生一個,并返回。
            而從后者中取時,存在就返回,不存在,就返回為空。
             由上面的解釋,不難想象,該模式的實現:
            class Flyweight
            {
            public:
             ...
            };

            class SubFlyweightObjX : public Flyweight
            {
            ...
            };

            class SubFlyweightObjY : public Flyweight
            {
            ...
            };

            //Flyweight類的結構
            class FlyweightBuffFactory
            {
            public:
             Flyweight* GetFlyweight(...condition...)
             {
              for (vector<Flyweight* >::iterator iter = m_vBuffer.begin(); iter != m_vBuffer.end(); iter++)
              {
               if (iter.xxx = condition)
                return (Flyweight*)iter;//注:如果此句不行用這句:return (Flyweight*)(&(*iter));
              }
              Flyweight* pReturn = new xxx;
              m_vBuffer.push_back(pReturn);
              return pReturn;
             }

            private:
             vector<Flyweight* > m_vBuffer;
            };

            posted @ 2011-05-20 00:38 Jacc.Kim 閱讀(233) | 評論 (0)編輯 收藏

            九:Decorator模式(即:裝飾模式)

             (注2)假設有這樣的一個問題存在(其實現實開發中,非常經常遇到):基類BasicClassX有N個的派生類。因為它們沒有功能接口void UnknowFunction(void);
            按正常的。我們的處理方法,(1) 可以通過直接修改BasicClassX基類,在此添加virtual void UnknowFunction(void);虛接口并實現,然后所有derived
            class中均可見。(2) 又或是在BasicClassX基類,添加了純虛接口,然后在具體某派生類中進行了實現。在實現使用中,用該derived class來處理。
             (注3)但這樣做會有這樣的問題存在:a) 會有可能讓繼承的深度,變的很深。系統的類將變的很多,很復雜。b) 類的結構也將變的復雜化。(因為現
            在是增加個接口,以后要是又有其他的接口功能需要添加了???) c) 無形中,會加重基類的負擔。因為必須得保證擴展該接口,否則基類看不到該接
            口。
             (注1)為了解決上面的問題。Decorator模式就可以幫助我們很輕松地解決。我們實現一個Decorator類。該類,只要引用一個BasicClassX指針對象即可。
            然后在Decorator類中,擴展功能接口,這樣,新擴展的功能就與BasicClassX的相關類,無任何關系。只是在BasicClassX相關類需要該擴展接口的地方,
            使用Decorator類來處理即可。就相當于BasicClassX的對象(或是它的derived class object)委托Decorator來實現處理一樣。但又同時像是將BasicClassX
            對象與Decorator對象進行組合在一起使用。從而達到新接口的擴展作用。Decorator模式就是這么回事。
             下面簡要提煉下Decorator類的設計
             SubClassA : BasicClassX;
             SubClassB : BasicClassX;
             SubClassC : SubClassA;
             ...
             SubClassN : ... : BasicClassX;

             class Decorator : BasicClassX
             {
             public:
              Decorator(BasicClassX* pBObj){m_pBOjb = pBObj;}
              void DoOperate(void)
              {
               m_pBObj->DoOperator();
               // do new interface
               this->DoNewInterfaceFunction();
              }
              //new extened interface function
              void DoNewInterfaceFunction(void){//do something...}
              // new extened other interface function
              ...
              
              //write down other code in here you knowned.
              ...
             private:
              BasicClassX* m_pBObj;
             }
             個人認為,Decorator模式,你說它有用。它確實有用。說它沒用。其實它也沒用。為啥這樣說了?因為它完全可以通過,繼承,或者直接修改原有的類體系來
            實現。但它的存在,也確實會讓系統的思路清晰些。至少代碼相對不會那么亂。

            posted @ 2011-05-20 00:35 Jacc.Kim 閱讀(228) | 評論 (0)編輯 收藏

            設計模式學習總結之六

            八:Composite模式(即:復合模式)

             復合模式旨在將遞歸處理,轉化為一種順序處理。明顯地,遞歸處理,相對較耗資源。也相對較為抽象些。而用一個Composite類對象來轉化處理
            遞歸處理。將顯得直觀些。它與Decorator模式的區別是:Composite模式,旨在構造一個類。這個類,將原本是遞歸組織的樹狀結構,轉換為直觀地轉化為
            順序結構。即:它重要于轉化表現。而Decorator模式(即:修飾模式),其重要簡化管理原本系統類體系結構。不至于將類繼承體系越來越深。同時,不
            至于讓原本設計好的類,越來越復雜化。同時又可以為原本類體系添加新的功能(即:書上所述的新的職責)。

             下面簡要看下該模式的代碼結構:

            class ClassNode
            {
            public:
             //寫下構造函數等
             ...
            public:
             virtual void Operation(void);
             virtual void Add(ClassNode* pNode);
             virtual void Remove(ClassNode* pNode);
             virtual ClassNode* GetNode(int iIndex);
            }

            //Composite類
            class Composite : public ClassNode
            {
            public:
             typedef vector<ClassNode* > NODELISTVEC;
            public:
             void Operation(void)
             {
              for (NODELISTVEC::iterator iter = m_vNodeList.begin(); iter != m_vNodeList.end(); iter++)
               iter->Operation();
             }
             void Add(ClassNode* pNode){//do something...}
             void Remove(ClassNode* pNode){//do something...}
             ClassNode* GetNode(int iIndex){//do something...}
            private:
             NODELISTVEC m_vNodeList;
            }

            //調用
            int main(int argc, char* argv[])
            {
             Composite* MyCompositeForNodes = new ...;
             ClassNode* xxx = new ...;//創建節點。當然這里只是為了演示,所以只創建一個節點。一棵樹有可能有N個節點。
             MyCom,positeForNodes.Add(xxx );
             ...
             MyCompositeForNodes.Operation();
            }

            //個人認為,該模式,很怪啊。。因為通過這樣轉換后,原本的父子關系就被破壞掉了。
            //如果有大俠理解的深的話,,還請不吝補充下。。不盛感激。

            posted @ 2011-05-18 00:46 Jacc.Kim 閱讀(251) | 評論 (0)編輯 收藏

            設計模式學習總結之五

            七:Decorator模式(即:裝飾模式)

             (注2)假設有這樣的一個問題存在(其實現實開發中,非常經常遇到):基類BasicClassX有N個的派生類。因為它們沒有功能接口void UnknowFunction(void);
            按正常的。我們的處理方法,(1) 可以通過直接修改BasicClassX基類,在此添加virtual void UnknowFunction(void);虛接口并實現,然后所有derived
            class中均可見。(2) 又或是在BasicClassX基類,添加了純虛接口,然后在具體某派生類中進行了實現。在實現使用中,用該derived class來處理。
             (注3)但這樣做會有這樣的問題存在:a) 會有可能讓繼承的深度,變的很深。系統的類將變的很多,很復雜。b) 類的結構也將變的復雜化。(因為現
            在是增加個接口,以后要是又有其他的接口功能需要添加了???) c) 無形中,會加重基類的負擔。因為必須得保證擴展該接口,否則基類看不到該接
            口。
             (注1)為了解決上面的問題。Decorator模式就可以幫助我們很輕松地解決。我們實現一個Decorator類。該類,只要引用一個BasicClassX指針對象即可。
            然后在Decorator類中,擴展功能接口,這樣,新擴展的功能就與BasicClassX的相關類,無任何關系。只是在BasicClassX相關類需要該擴展接口的地方,
            使用Decorator類來處理即可。就相當于BasicClassX的對象(或是它的derived class object)委托Decorator來實現處理一樣。但又同時像是將BasicClassX
            對象與Decorator對象進行組合在一起使用。從而達到新接口的擴展作用。Decorator模式就是這么回事。
             下面簡要提煉下Decorator類的設計
             SubClassA : BasicClassX;
             SubClassB : BasicClassX;
             SubClassC : SubClassA;
             ...
             SubClassN : ... : BasicClassX;

             class Decorator : BasicClassX
             {
             public:
              Decorator(BasicClassX* pBObj){m_pBOjb = pBObj;}
              void DoOperate(void)
              {
               m_pBObj->DoOperator();
               // do new interface
               this->DoNewInterfaceFunction();
              }
              //new extened interface function
              void DoNewInterfaceFunction(void){//do something...}
              // new extened other interface function
              ...
              
              //write down other code in here you knowned.
              ...
             private:
              BasicClassX* m_pBObj;
             }
             個人認為,Decorator模式,你說它有用。它確實有用。說它沒用。其實它也沒用。為啥這樣說了?因為它完全可以通過,繼承,或者直接修改原有的類體系來
            實現。但它的存在,也確實會讓系統的思路清晰些。至少代碼相對不會那么亂。

            posted @ 2011-05-17 01:16 Jacc.Kim 閱讀(290) | 評論 (0)編輯 收藏

            設計模式學習總結之四

            六:Bridge模式(即:橋接模式)

             講之前,先聲明:由于本人電腦不是很好,沒法裝上vc環境運行。因此以下代碼,僅是手工輸入,在環境中未必能編譯通過。
            但以下,僅僅只是介紹一種思想。僅供參考。同時,如果說明有誤之處,歡迎指正。另外,則于一次性手工輸入下面那么多東東,確實
            不容易,所以Delphi的具體實現。就不在此列出。如有興趣用Delphi實現的朋友,也可以找本人交流,本人盛感榮幸。
            (當然如果是C++的朋友也同樣、甚至更加歡迎)

             看了這么多次的橋接模式,這次總算明白了。要想理解橋接模式,個人認為,還是有必要同抽象及其實現進行一下比較。
             1) 抽象及實現。我相信,跟不同的人說話,都會有訣竅在里頭。同是coder,相信,最默契的溝通,還是code吧。我們來看下抽象及其實現的代碼。
            //抽象基類聲明
            class AbstractClassX
            {
            private:
             //xxx
            protected:
             //xxx
            public:
             //xxx
             void DoSomething(void) = 0;
             //xxx
            }

            //AbstractClassX的具體實現 ClassXImplX1
            class ClassXImplX1 : public AbstractClassX
            {
            ....
            public:
             void DoSomething(void){ // do something with method 1... }
            }

            //AbstractClassX的具體實現 ClassXImplX2
            class ClassXImplX2 : public AbstractClassX
            {
            ....
            public:
             void DoSomething(void){ // do something with method 2... }
            }

             在實際應用中,我們用的是抽象類。而實際上實例化的,卻是某具體子類。這種實現被我們多數人所使用。而它實際上解決的只是這么一類問題,即:同一行為的不同表現。當
            然大多數需求,用此就可以了。
             但現在假如說有這么一種情況:假如說,上面的處理僅僅只適用于平臺A,而用戶卻希望同時,它也要能夠在平臺B上也能夠一樣的操作。那當如何?
            很明顯的,此種需要,并不是行為上的需求,因為不論是在平臺A上還是平臺B上,都要執行相同的操作。而且表示也是一樣的。該需要的實現。實際上是需要我們重新封裝個抽象層,
            來專門處理平臺B上的該行為。而實際的實現,卻還是跟平臺A上的一樣。其實我們仔細一想。其實平臺A了的抽象(即:AbstractClassX)與平臺B上的抽象(假如為:AbstractClassY),
            其實它們是類似的。因為需要處理的功能一樣。因此,我們就想,如果將這種抽象與實現具體分離開來。在抽象中,留個具體實現的抽象引用(此其實就是該模式所指的Bridge----即:橋
            通過該橋,將抽象與具體的實現連接起來。因此,我想該模式的名稱就是因此得來的吧)。那樣。抽象可以不受限制的擴展,實現也同樣可以不受限制的擴展。這樣,系統的框架就不需要
            更改,其不妙哉?!因此就有了如下的code

            //******************************************************************
            //* 抽象聲明及抽象部分的實現
            //******************************************************************
            //抽象的抽象基類聲明
            class AbstractClass
            {
            private:
             //xxx
            protected:
             AbstractImpl* m_pAIObj; //具體的抽象實現的抽象對象(這話很ao口,但理解了這話,也就理解了該模式。可以大言不慚地說,該模式的秘密就在這句話上)
             //xxx
            public:
             //xxx
             void DoSomething(void) = 0;
             //xxx
            }

            //平臺A上的抽象的具體實現(注意:此實現子類,是針對抽象的)
            class AbstractClassA : public AbstractClass
            {
            private:
             //xxx
            protected:
             //xxx
            public:
             //xxx
             void DoSomething(void) { m_pAIObj.DoSomething(); }
             //xxx
            }

            //平臺B上的抽象的具體實現(注意:此實現子類,是針對抽象的)
            class AbstractClassB : public AbstractClass
            {
            private:
             //xxx
            protected:
             //xxx
            public:
             //xxx
             void DoSomething(void) { m_pAIObj.DoSomething(); }
             //xxx
            }

            //******************************************************************
            //* 實現的抽象聲明及其實現
            //******************************************************************
            //實現部分的抽象基類聲明
            class AbstractImplClass
            {
            private:
             //xxx
            protected:
             //xxx
            public:
             //xxx
             void DoSomething(void) = 0;
             //xxx
            }

            //具體算法1的具體實現
            class ImplX : public AbstractImplClass
            {
            private:
             //xxx
            protected:
             //xxx
            public:
             //xxx
             void DoSomething(void) { // do something... }
             //xxx
            }

            //具體算法1的具體實現
            class ImplY : public AbstractImplClass
            {
            private:
             //xxx
            protected:
             //xxx
            public:
             //xxx
             void DoSomething(void) { // do something... }
             //xxx
            }

            //******************************************************************
            //* 實際應用方面
            //******************************************************************

            int main(int argc, char* argv[])
            {
             AbstractImplClass* pImplObj = new ImplX();//或new ImplY();等等。
             //下面注意下:因為上面的代碼中,本人為了簡寫,并沒有明確寫出抽象部分的具體構造函數。
             //相信,是程序員,看完下面這行都懂得,上面的抽象部分的聲明,應該聲明一個什么樣的
             //構造函數吧。
             AbstractClass* pAbstractObj = new AbstractClassA(pImplObj);//或new AbstractClassB(pImplObj);等等。

             //do other something...

             //在此補充一點:有上面的設計,系統的框架將都無需修改。不論是實現的具體算法改變了,還是
             //抽象的需求變動。程序都無需要修改框架代碼,,僅僅只需要寫個具體的實現類(不管是實現的實現類,還是
             //抽象的實現類)即可。這就是橋接模式。
            }

            posted @ 2011-05-16 00:42 Jacc.Kim 閱讀(211) | 評論 (0)編輯 收藏

            設計模式學習總結之三

            五:Prototype模式(即:原型模式)

             此模式其實很簡單,主要就是通過“克隆”的技術,來產生出新的對象來。其與抽象工廠模式以及Builder模式的區別是:抽象工廠模式式,主要用來產生多個有相互依賴關系的對象的創建。
            而構建模式則主要用來處理一個復雜模塊的一步步構建工作。原型模式,則注重通過自身,來復制出一份與自身一樣的實例對象來。原型本身也有點類似一個抽象工廠。
             原型模式常用的接口一般有:Clone(); Asign(); 還有拷貝構造函數。(對Delphi來說,主要還是前兩種方法)

             前面一至五,可被歸納為:創建型模式

            posted @ 2011-05-15 15:48 Jacc.Kim 閱讀(249) | 評論 (0)編輯 收藏

            設計模式學習總結之二

            三:Singleton模式(單實例模式)

             顧名思義,即單例模式。其主要思想就是在項目中,僅創建一個實例對象。該對象的抽象,除了通過指定的獲取實例接口外,再沒其他辦法可以初始化。
            此可以保證整個系統生命周期內,僅會有一個實例存在。可以想象一下,它是可以與先前說的工廠模式或抽象工廠模式結合使用的。因為一般來說,工廠可能只會
            有一個(至少對某種邏輯處理來說是這樣的)。
             在C++中,實現單例模式,相對比較直觀及合理。將該實例定義成static成員即可。并提供獲取及釋放該成員的接口。而在delphi中,(就本來的了解來說)
            似乎并沒有直觀的靜態成員這一說法。但可以定義一個全局變量,并提供獲取與釋放變量的接口來模擬。(但,畢竟沒辦法同類型的實例被創建出來,所以最好要加
            詳細注釋說明。告知其他組員,此為單實例)

             參考的c++實現:
             class CA
             {
             private:
              CA(){}
             private:
              static CA* m_pAObj;
             public:
              virtual ~CA(){}
              static CA* GetAObj(void)
              {
               if (m_pAObj == NULL)
                m_pAObj = new CA();
               return m_pAObj;
              }
              static void SafeReleaseAObj(void)
              {
               if (m_pAObj != NULL)
                delete m_pAObj;
               m_pAObj = NULL;
              }
             };
             static CA* CA::m_pAObj = NULL;

             參考的Delphi實現:
             unit xxx
             interface
             uses
               xxx,...,yyy;
             type
               TMyClass = class
               //xxxx
               end;
             var
               gAObj: TMyClass;//此為全局的單實例對象。
             function GetAObj: TMyClass;
             procedure SafeReleaseAObj;
             implemention//這個單詞忘了是不是這么寫。反應是實現的那個單詞。。
             procedure SafeReleaseAObj;
             begin
               if Assigned(gAObj) then
                 FreeAndNil(gAObj);
             end;
             funciton GetAObj: TMyClass;
             begin
               if not Assigned(gAObj) then
                 gAObj = TMyClass.Create;
               Result := gAObj;
             end;

             //說明:以上僅是臨時寫的,并未在程序中編譯測試。但思路肯定不會錯。可供參考用。
             
            四:Builder模式(即:構建模式)

             往往在實際項目的開發過程中會發現,某些模塊的功能過于復雜。此時,我們自然就會想到將其進行進一步的劃分。如:細分成DA,DB,...,DN。然后由該模塊的某個管理角色進行協調運作。
            這樣,Builder模式將可用在此設計上。其思想,就是將復雜問題進一步細化。

            posted @ 2011-05-15 15:31 Jacc.Kim 閱讀(299) | 評論 (0)編輯 收藏

            設計模式學習總結之一

             設計模式其實只是一種程序設計的思想準則。通過該思想準則來指導我們的程序開發行為,盡量讓開發的程序更加穩健、高效、思路清晰、少bug......
            開發一程序項目,往往并不只限于單一地使用某一模式。往往會多種模式同時使用。

             其實,設計模式在具體項目中的應用開發中。要說要用xxx/xxx模式來搭框架開發等等,這些都是不對的。因為個人認為,設計模式的應用,是隨著項目的
            不同而定的。因為不同的項目有著不同的解決方案。而不同的解決方案,將決定著,需要使用哪xxx/哪xxx模式來處理會比較好,此時才能說,確定了項目
            的框架等等。
             比如說:本來需要開發一個本地資源管理的項目。如果你一開始就給它定了一定要用單實例模式來搭框架實現。那我們就不明白了這個實例,在框架中,
            到底它應該是什么。反過來,正常的,我們應該根據這個項目的需要來確定應該用到的模式。就拿該例子來說。我們可以對資源方面,使用抽象工棧模式
            在資源與展現及其處理方面,我們可以應用觀察模式(即:所謂的observer模式)。如此一來,我很明確了,該系統大置的框架。這正應了剛開始的一句話
            :設計模式只是一種程序設計的思想準則,它只是用來指導程序開發的行為。

             當然想懂得設計模式的東東,確實還是離不開面向對象(的思想)。對oo思想更解的越深刻,學起設計模式的將相對越輕松,也更解的會更深刻些(當然,
            學習它將是個不斷迭代的過程的)。反過來,對設計模式理解的越深刻,對oo的理解及應用與設計,也將大大有益。

            一:Factory模式(工廠模式)

             所謂的Factory模式,即:它能類似工廠一樣,不斷地產生(即:創建)“產品”出來。但它所創建出來的那些“產品”,一般是抽象類的產品。舉例:
            假如有抽象類AbstractBasicClass。我們要想使用它,必須得有它的實現類。按正常來說,我們可以直接通過其具體的子類實例化一個產品出來。但這樣會
            有個問題,當AbstractBasicClass擁有N種不同的實現子類時,那我們到底要使用哪種具體子類來實例化,并且,各個不同的具體實現子類的命名,也將是
            個可怕的問題。因此這樣的維護將變得十分復雜。而Factory的設計就可以起來很好的一個維護作用。其實Factory模式的設計,還有一個好處,就是使得實例
            化得到了推遲(到了后期----一般指執行期)。

            二:AbstractFactory模式(抽象工廠模式)

             上面Factory模式,其實針對的是一類類的情況,即:處理的上上面的AbstractBasicClass這一類類的情況。而實際項目中,卻往往需要處理N種的這樣抽象類、
            的情況。此時,我們將這N種類的產品創建都歸到一個Factory中時,此時的Factory即為一個AbstractFactory了。因此說,Factory與AbstractFactory只不過
            是處理的類各類的個數差異罷了。其思想是類似的。
             但一般來說AbstractFactory所產生出來的種抽象類,其實它們之間,一般來說,或多或少,會是有一定的關系的。比如:一個Abstractfactory產生出兩個
            抽象類的產品A和B。則A可能就需要B的某些功能,反之類似。

             小結:Factory與AbstractFactory的設計,最終的目的都只是為了使用系統抽象類的維護更加簡單些。

            posted @ 2011-05-15 12:14 Jacc.Kim 閱讀(455) | 評論 (0)編輯 收藏

            僅列出標題
            共14頁: First 6 7 8 9 10 11 12 13 14 
            久久无码人妻一区二区三区| 久久国产精品偷99| 色婷婷狠狠久久综合五月| 日韩一区二区三区视频久久| 欧美午夜精品久久久久久浪潮| 无码人妻少妇久久中文字幕 | 国产亚洲欧美精品久久久| 国产午夜福利精品久久2021 | 久久婷婷五月综合成人D啪| 亚洲欧美日韩久久精品第一区| 久久精品免费大片国产大片| 狠狠色婷婷久久一区二区| 久久亚洲高清综合| 久久99精品国产99久久6| 狠狠色丁香婷婷久久综合不卡| 久久久久久久97| 国产精品久久久久乳精品爆| 午夜精品久久久久久毛片| 国产AV影片久久久久久| 看久久久久久a级毛片| 久久久久久毛片免费看| 久久精品一区二区三区不卡| 欧美日韩久久中文字幕| 久久婷婷人人澡人人| 波多野结衣中文字幕久久| 久久久久久精品免费看SSS| 久久久久久久综合日本| 国内精品久久久久久久久电影网| 97久久超碰成人精品网站| 狠狠色丁香久久综合五月| 日韩AV无码久久一区二区| 亚洲av成人无码久久精品| 久久国产劲爆AV内射—百度| 日批日出水久久亚洲精品tv| Xx性欧美肥妇精品久久久久久| 久久久国产精品福利免费| 狠狠狠色丁香婷婷综合久久俺| 97久久精品无码一区二区| 国产亚洲色婷婷久久99精品| 国产精品毛片久久久久久久| 国产精品久久久久久福利漫画|