亚洲免费在线-亚洲免费在线播放-亚洲免费在线观看-亚洲免费在线观看视频-亚洲免费在线看-亚洲免费在线视频

一些軟件設計的原則

系統(tǒng) 1860 0

本文為大家介紹軟件設計中的一些原則,都是經(jīng)過長期經(jīng)驗總結(jié)出來的知識,每一個程序員都應該了解,相信對大家在進行軟件設計的過程中會有很大幫助。?

Don’t Repeat Yourself (DRY) ?
DRY 是一個最簡單的法則,也是最容易被理解的。但它也可能是最難被應用的(因為要做到這樣,我們需要在泛型設計上做相當?shù)呐Γ@并不是一件容易的事)。它意味著,當我們在兩個或多個地方的時候發(fā)現(xiàn)一些相似的代碼的時候,我們需要把他們的共性抽象出來形一個唯一的新方法,并且改變現(xiàn)有的地方的代碼讓他們以一些合適的參數(shù)調(diào)用這個新的方法。?
參考: http://en.wikipedia.org/wiki/KISS_principle ?

Program to an interface, not an implementation ?
這是設計模式中最根本的哲學,注重接口,而不是實現(xiàn),依賴接口,而不是實現(xiàn)。接口是抽象是穩(wěn)定的,實現(xiàn)則是多種多樣的。以后面我們會面向?qū)ο蟮腟OLID原則中會提到我們的依賴倒置原則,就是這個原則的的另一種樣子。還有一條原則叫 Composition over inheritance(喜歡組合而不是繼承),這兩條是那23個經(jīng)典設計模式中的設計原則。?

Command-Query Separation (CQS)? – 命令-查詢分離原則 ?
查詢:當一個方法返回一個值來回應一個問題的時候,它就具有查詢的性質(zhì);?
命令:當一個方法要改變對象的狀態(tài)的時候,它就具有命令的性質(zhì);?

通常,一個方法可能是純的Command模式或者是純的Query模式,或者是兩者的混合體。在設計接口時,如果可能,應該盡量使接口單一化,保證方法的行為嚴格的是命令或者是查詢,這樣查詢方法不會改變對象的狀態(tài),沒有副作用,而會改變對象的狀態(tài)的方法不可能有返回值。也就是說:如果我們要問一個問題,那么就不應該影響到它的答案。實際應用,要視具體情況而定,語義的清晰性和使用的簡單性之間需要權(quán)衡。將Command和Query功能合并入一個方法,方便了客戶的使用,但是,降低了清晰性,而且,可能不便于基于斷言的程序設計并且需要一個變量來保存查詢結(jié)果。?

在系統(tǒng)設計中,很多系統(tǒng)也是以這樣原則設計的,查詢的功能和命令功能的系統(tǒng)分離,這樣有則于系統(tǒng)性能,也有利于系統(tǒng)的安全性。?

參考: http://en.wikipedia.org/wiki/Command-query_separation ?

You Ain’t Gonna Need It (YAGNI) ?
這個原則簡而言之為——只考慮和設計必須的功能,避免過度設計。只實現(xiàn)目前需要的功能,在以后您需要更多功能時,可以再進行添加。?

如無必要,勿增復雜性。?
軟件開發(fā)先是一場溝通博弈。?

以前本站有一篇關于 過度重構(gòu)的文章 ,這個示例就是這個原則的反例。而,WebSphere的設計者就 表示過他過度設計了這個產(chǎn)品 。我們的程序員或是架構(gòu)師在設計系統(tǒng)的時候,會考慮很多擴展性的東西,導致在架構(gòu)與設計方面使用了大量折衷,最后導致項目失敗。這是個令人感到諷刺的教訓,因為本來希望盡可能延長項目的生命周期,結(jié)果反而縮短了生命周期。?

參考: http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It ?

Law of Demeter – 迪米特法則 ?
迪米特法則(Law of Demeter),又稱“最少知識原則”(Principle of Least Knowledge),其來源于1987年荷蘭大學的一個叫做Demeter的項目。Craig Larman把Law of Demeter又稱作“不要和陌生人說話”。在《程序員修煉之道》中講LoD的那一章叫作“解耦合與迪米特法則”。關于迪米特法則有一些很形象的比喻:?
如果你想讓你的狗跑的話,你會對狗狗說還是對四條狗腿說??
如果你去店里買東西,你會把錢交給店員,還是會把錢包交給店員讓他自己拿??

和狗的四肢說話?讓店員自己從錢包里拿錢?這聽起來有點荒唐,不過在我們的代碼里這幾乎是見怪不怪的事情了。?

對于LoD,正式的表述如下:?


在《Clean Code》一書中,有一段Apache framework中的一段違反了LoD的代碼:?

final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();?

這么長的一串對其它對象的細節(jié),以及細節(jié)的細節(jié),細節(jié)的細節(jié)的細節(jié)……的調(diào)用,增加了耦合,使得代碼結(jié)構(gòu)復雜、僵化,難以擴展和維護。?

在《重構(gòu)》一書中的代碼的環(huán)味道中有一種叫做“Feature Envy”(依戀情結(jié)),形象的描述了一種違反了LoC的情況。Feature Envy就是說一個對象對其它對象的內(nèi)容更有興趣,也就是說老是羨慕別的對象的成員、結(jié)構(gòu)或者功能,大老遠的調(diào)用人家的東西。這樣的結(jié)構(gòu)顯然是不合理的。我們的程序應該寫得比較“害羞”。不能像前面例子中的那個不把自己當外人的店員一樣,拿過客人的錢包自己把錢拿出來。“害羞”的程序只和自己最近的朋友交談。這種情況下應該調(diào)整程序的結(jié)構(gòu),讓那個對象自己擁有它羨慕的feature,或者使用合理的設計模式(例如Facade和Mediator)。?

參考: http://en.wikipedia.org/wiki/Principle_of_Least_Knowledge ?

面向?qū)ο蟮腟.O.L.I.D 原則 ?

一般來說這是面向?qū)ο蟮奈宕笤O計原則,但是,我覺得這些原則可適用于所有的軟件開發(fā)。?

Single Responsibility Principle (SRP) – 職責單一原則 ?

關于單一職責原則,其核心的思想是: 一個類,只做一件事,并把這件事做好,其只有一個引起它變化的原因 。單一職責原則可以看作是低耦合、高內(nèi)聚在面向?qū)ο笤瓌t上的引申,將職責定義為引起變化的原因,以提高內(nèi)聚性來減少引起變化的原因。職責過多,可能引起它變化的原因就越多,這將導致職責依賴,相互之間就產(chǎn)生影響,從而極大的損傷其內(nèi)聚性和耦合度。單一職責,通常意味著單一的功能,因此不要為一個模塊實現(xiàn)過多的功能點,以保證實體只有一個引起它變化的原因。?

Unix/Linux是這一原則的完美體現(xiàn)者。各個程序都獨立負責一個單一的事。?
Windows是這一原則的反面示例。幾乎所有的程序都交織耦合在一起。?

Open/Closed Principle (OCP) – 開閉原則 ?

關于開發(fā)封閉原則,其核心的思想是:模塊是可擴展的,而不可修改的。也就是說, 對擴展是開放的,而對修改是封閉的 。?

對擴展開放,意味著有新的需求或變化時,可以對現(xiàn)有代碼進行擴展,以適應新的情況。?
對修改封閉,意味著類一旦設計完成,就可以獨立完成其工作,而不要對類進行任何修改。?

對于面向?qū)ο髞碚f,需要你依賴抽象,而不是實現(xiàn),23個經(jīng)典設計模式中的“策略模式”就是這個實現(xiàn)。對于非面向?qū)ο缶幊蹋恍〢PI需要你傳入一個你可以擴展的函數(shù),比如我們的C 語言的qsort()允許你提供一個“比較器”,STL中的容器類的內(nèi)存分配,ACE中的多線程的各種鎖。對于軟件方面,瀏覽器的各種插件屬于這個原則的實踐。?

Liskov substitution principle (LSP) – 里氏代換原則 ?

軟件工程大師Robert C. Martin把里氏代換原則最終簡化為一句話:“Subtypes must be substitutable for their base types”。也就是,子類必須能夠替換成它們的基類。即:子類應該可以替換任何基類能夠出現(xiàn)的地方,并且經(jīng)過替換以后,代碼還能正常工作。另外,不應該在代碼中出現(xiàn)if/else之類對子類類型進行判斷的條件。里氏替換原則LSP是使代碼符合開閉原則的一個重要保證。正是由于子類型的可替換性才使得父類型的模塊在無需修改的情況下就可以擴展。?

這么說來,似乎有點教條化,我非常建議大家看看這個原則個兩個最經(jīng)典的案例——“正方形不是長方形”和“鴕鳥不是鳥”。通過這兩個案例,你會明白《墨子 小取》中說的 ——“娣,美人也,愛娣,非愛美人也….盜,人也;惡盜,非惡人也。”——妹妹雖然是美人,但喜歡妹妹并不代表喜歡美人。盜賊是人,但討厭盜賊也并不代表就討厭人類。 這個原則讓你考慮的不是語義上對象的間的關系,而是實際需求的環(huán)境。 ?

在很多情況下,在設計初期我們類之間的關系不是很明確,LSP則給了我們一個判斷和設計類之間關系的基準:需不需要繼承,以及怎樣設計繼承關系。?

Interface Segregation Principle (ISP) – 接口隔離原則 ?

接口隔離原則意思是把功能實現(xiàn)在接口中,而不是類中,使用多個專門的接口比使用單一的總接口要好。?

舉個例子,我們對電腦有不同的使用方式,比如:寫作,通訊,看電影,打游戲,上網(wǎng),編程,計算,數(shù)據(jù)等,如果我們把這些功能都聲明在電腦的抽類里面,那么,我們的上網(wǎng)本,PC機,服務器,筆記本的實現(xiàn)類都要實現(xiàn)所有的這些接口,這就顯得太復雜了。所以,我們可以把其這些功能接口隔離開來,比如:工作學習接口,編程開發(fā)接口,上網(wǎng)娛樂接口,計算和數(shù)據(jù)服務接口,這樣,我們的不同功能的電腦就可以有所選擇地繼承這些接口。?

這個原則可以提升我們“搭積木式”的軟件開發(fā)。對于設計來說,Java中的各種Event Listener和Adapter,對于軟件開發(fā)來說,不同的用戶權(quán)限有不同的功能,不同的版本有不同的功能,都是這個原則的應用。?

Dependency Inversion Principle (DIP) – 依賴倒置原則 ?

高層模塊不應該依賴于低層模塊的實現(xiàn),而是依賴于高層抽象。?

舉個例子,墻面的開關不應該依賴于電燈的開關實現(xiàn),而是應該依賴于一個抽象的開關的標準接口,這樣,當我們擴展程序的時候,我們的開關同樣可以控制其它不同的燈,甚至不同的電器。也就是說,電燈和其它電器繼承并實現(xiàn)我們的標準開關接口,而我們的開關產(chǎn)商就可不需要關于其要控制什么樣的設備,只需要關心那個標準的開關標準。這就是依賴倒置原則。?

這就好像瀏覽器并不依賴于后面的web服務器,其只依賴于HTTP協(xié)議。這個原則實在是太重要了,社會的分工化,標準化都是這個設計原則的體現(xiàn)。?

參考: http://en.wikipedia.org/wiki/Solid_(object-oriented_design) ?

Common Closure Principle(CCP)– 共同封閉原則 ?
一個包中所有的類應該對同一種類型的變化關閉。一個變化影響一個包,便影響了包中所有的類。一個更簡短的說法是:一起修改的類,應該組合在一起(同一個包里)。如果必須修改應用程序里的代碼,我們希望所有的修改都發(fā)生在一個包里(修改關閉),而不是遍布在很多包里。CCP原則就是把因為某個同樣的原因而需要修改的所有類組合進一個包里。如果2個類從物理上或者從概念上聯(lián)系得非常緊密,它們通常一起發(fā)生改變,那么它們應該屬于同一個包。?

CCP延伸了開閉原則(OCP)的“關閉”概念,當因為某個原因需要修改時,把需要修改的范圍限制在一個最小范圍內(nèi)的包里。?

參考: http://c2.com/cgi/wiki?CommonClosurePrinciple ?

Common Reuse Principle (CRP) – 共同重用原則 ?
包的所有類被一起重用。如果你重用了其中的一個類,就重用全部。換個說法是,沒有被一起重用的類不應該被組合在一起。CRP原則幫助我們決定哪些類應該被放到同一個包里。依賴一個包就是依賴這個包所包含的一切。當一個包發(fā)生了改變,并發(fā)布新的版本,使用這個包的所有用戶都必須在新的包環(huán)境下驗證他們的工作,即使被他們使用的部分沒有發(fā)生任何改變。因為如果包中包含有未被使用的類,即使用戶不關心該類是否改變,但用戶還是不得不升級該包并對原來的功能加以重新測試。?

CCP則讓系統(tǒng)的維護者受益。CCP讓包盡可能大(CCP原則加入功能相關的類),CRP則讓包盡可能小(CRP原則剔除不使用的類)。它們的出發(fā)點不一樣,但不相互沖突。?

參考: http://c2.com/cgi/wiki?CommonReusePrinciple ?

Hollywood Principle – 好萊塢原則 ?
好萊塢原則就是一句話——“don’t call us, we’ll call you.”。意思是,好萊塢的經(jīng)紀人們不希望你去聯(lián)系他們,而是他們會在需要的時候來聯(lián)系你。也就是說,所有的組件都是被動的,所有的組件初始化和調(diào)用都由容器負責。組件處在一個容器當中,由容器負責管理。?

簡單的來講,就是由容器控制程序之間的關系,而非傳統(tǒng)實現(xiàn)中,由程序代碼直接操控。這也就是所謂“控制反轉(zhuǎn)”的概念所在:?

1.不創(chuàng)建對象,而是描述創(chuàng)建對象的方式。?
2.在代碼中,對象與服務沒有直接聯(lián)系,而是容器負責將這些聯(lián)系在一起。?

控制權(quán)由應用代碼中轉(zhuǎn)到了外部容器,控制權(quán)的轉(zhuǎn)移,是所謂反轉(zhuǎn)。?

好萊塢原則就是IoC(Inversion of Control)或DI(Dependency Injection )的基礎原則。這個原則很像依賴倒置原則,依賴接口,而不是實例,但是這個原則要解決的是怎么把這個實例傳入調(diào)用類中?你可能把其聲明成成員,你可以通過構(gòu)造函數(shù),你可以通過函數(shù)參數(shù)。但是 IoC可以讓你通過配置文件,一個由Service Container 讀取的配置文件來產(chǎn)生實際配置的類。但是程序也有可能變得不易讀了,程序的性能也有可能還會下降。?

參考:?

[url]http://en.wikipedia.org/wiki/Hollywood_Principle [/url]?
[url]http://en.wikipedia.org/wiki/Inversion_of_Control [/url]?

High Cohesion & Low/Loose coupling & – 高內(nèi)聚, 低耦合 ?
這個原則是UNIX操作系統(tǒng)設計的經(jīng)典原則,把模塊間的耦合降到最低,而努力讓一個模塊做到精益求精。?

內(nèi)聚:一個模塊內(nèi)各個元素彼此結(jié)合的緊密程度?
耦合:一個軟件結(jié)構(gòu)內(nèi)不同模塊之間互連程度的度量?

內(nèi)聚意味著重用和獨立,耦合意味著多米諾效應牽一發(fā)動全身。?

參考:?

http://en.wikipedia.org/wiki/Coupling_(computer_science) ?
[url]http://en.wikipedia.org/wiki/Cohesion_(computer_science) [/url]?

Convention over Configuration(CoC)– 慣例優(yōu)于配置原則 ?
簡單點說,就是將一些公認的配置方式和信息作為內(nèi)部缺省的規(guī)則來使用。例如,Hibernate的映射文件,如果約定字段名和類屬性一致的話,基本上就可以不要這個配置文件了。你的應用只需要指定不convention的信息即可,從而減少了大量convention而又不得不花時間和精力啰里啰嗦的東東。配置文件很多時候相當?shù)挠绊戦_發(fā)效率。?

Rails 中很少有配置文件(但不是沒有,數(shù)據(jù)庫連接就是一個配置文件),Rails 的fans號稱期開發(fā)效率是 java 開發(fā)的 10 倍,估計就是這個原因。Maven也使用了CoC原則,當你執(zhí)行mvn -compile命令的時候,不需要指源文件放在什么地方,而編譯以后的class文件放置在什么地方也沒有指定,這就是CoC原則。?

參考: http://en.wikipedia.org/wiki/Convention_over_Configuration ?

Separation of Concerns (SoC) – 關注點分離 ?
SoC 是計算機科學中最重要的努力目標之一。這個原則,就是在軟件開發(fā)中,通過各種手段,將問題的各個關注點分開。如果一個問題能分解為獨立且較小的問題,就是相對較易解決的。問題太過于復雜,要解決問題需要關注的點太多,而程序員的能力是有限的,不能同時關注于問題的各個方面。正如程序員的記憶力相對于計算機知識來說那么有限一樣,程序員解決問題的能力相對于要解決的問題的復雜性也是一樣的非常有限。在我們分析問題的時候,如果我們把所有的東西混在一起討論,那么就只會有一個結(jié)果——亂。?

我記得在上一家公司有一個項目,討論就討論了1年多,項目本來不復雜,但是沒有使用SoC,全部的東西混為一談,再加上一堆程序員注入了各種不同的觀點和想法,整個項目一下子就失控了。最后,本來一個1年的項目做了3年。?

實現(xiàn)關注點分離的方法主要有兩種,一種是標準化,另一種是抽象與包裝。標準化就是制定一套標準,讓使用者都遵守它,將人們的行為統(tǒng)一起來,這樣使用標準的人就不用擔心別人會有很多種不同的實現(xiàn),使自己的程序不能和別人的配合。Java EE就是一個標準的大集合。每個開發(fā)者只需要關注于標準本身和他所在做的事情就行了。就像是開發(fā)鏍絲釘?shù)娜酥粚W⒂陂_發(fā)鏍絲釘就行了,而不用關注鏍帽是怎么生產(chǎn)的,反正鏍帽和鏍絲釘按標來就一定能合得上。不斷地把程序的某些部分抽像差包裝起來,也是實現(xiàn)關注點分離的好方法。一旦一個函數(shù)被抽像出來并實現(xiàn)了,那么使用函數(shù)的人就不用關心這個函數(shù)是如何實現(xiàn)的,同樣的,一旦一個類被抽像并實現(xiàn)了,類的使用者也不用再關注于這個類的內(nèi)部是如何實現(xiàn)的。諸如組件,分層,面向服務,等等這些概念都是在不同的層次上做抽像和包裝,以使得使用者不用關心它的內(nèi)部實現(xiàn)細節(jié)。?

說白了還是“高內(nèi)聚,低耦合”。?

參考: http://sulong.me/archives/99 ?

Design by Contract (DbC) – 契約式設計 ?
DbC的核心思想是對軟件系統(tǒng)中的元素之間相互合作以及“責任”與“義務”的比喻。這種比喻從商業(yè)活動中“客戶”與“供應商”達成“契約”而得來。例如:?

供應商必須提供某種產(chǎn)品(責任),并且他有權(quán)期望客戶已經(jīng)付款(權(quán)利)。?
客戶必須付款(責任),并且有權(quán)得到產(chǎn)品(權(quán)利)。?
契約雙方必須履行那些對所有契約都有效的責任,如法律和規(guī)定等。?

同樣的,如果在程序設計中一個模塊提供了某種功能,那么它要:?

期望所有調(diào)用它的客戶模塊都保證一定的進入條件:這就是模塊的先驗條件(客戶的義務和供應商的權(quán)利,這樣它就不用去處理不滿足先驗條件的情況)。?
保證退出時給出特定的屬性:這就是模塊的后驗條件——(供應商的義務,顯然也是客戶的權(quán)利)。?
在進入時假定,并在退出時保持一些特定的屬性:不變式。?

契約就是這些權(quán)利和義務的正式形式。我們可以用“三個問題”來總結(jié)DbC,并且作為設計者要經(jīng)常問:?

它期望的是什么??
它要保證的是什么??
它要保持的是什么??

根據(jù)Bertrand Meyer氏提出的DBC概念的描述,對于類的一個方法,都有一個前提條件以及一個后續(xù)條件,前提條件說明方法接受什么樣的參數(shù)數(shù)據(jù)等,只有前提條件得到滿足時,這個方法才能被調(diào)用;同時后續(xù)條件用來說明這個方法完成時的狀態(tài),如果一個方法的執(zhí)行會導致這個方法的后續(xù)條件不成立,那么這個方法也不應該正常返回。?

現(xiàn)在把前提條件以及后續(xù)條件應用到繼承子類中,子類方法應該滿足:?

1.前提條件不強于基類.?
2.后續(xù)條件不弱于基類.?

換句話說,通過基類的接口調(diào)用一個對象時,用戶只知道基類前提條件以及后續(xù)條件。因此繼承類不得要求用戶提供比基類方法要求的更強的前提條件,亦即,繼承類方法必須接受任何基類方法能接受的任何條件(參數(shù))。同樣,繼承類必須順從基類的所有后續(xù)條件,亦即,繼承類方法的行為和輸出不得違反由基類建立起來的任何約束,不能讓用戶對繼承類方法的輸出感到困惑。?

這樣,我們就有了基于契約的LSP,基于契約的LSP是LSP的一種強化。?

參考: http://en.wikipedia.org/wiki/Design_by_contract ?

Acyclic Dependencies Principle (ADP) – 無環(huán)依賴原則 ?
包之間的依賴結(jié)構(gòu)必須是一個直接的無環(huán)圖形,也就是說,在依賴結(jié)構(gòu)中不允許出現(xiàn)環(huán)(循環(huán)依賴)。如果包的依賴形成了環(huán)狀結(jié)構(gòu),怎么樣打破這種循環(huán)依賴呢?有2種方法可以打破這種循環(huán)依賴關系:第一種方法是創(chuàng)建新的包,如果A、B、C形成環(huán)路依賴,那么把這些共同類抽出來放在一個新的包D里。這樣就把C依賴A變成了C依賴D以及A依賴D,從而打破了循環(huán)依賴關系。第二種方法是使用DIP(依賴倒置原則)和ISP(接口分隔原則)設計原則。?

無環(huán)依賴原則(ADP)為我們解決包之間的關系耦合問題。在設計模塊時,不能有循環(huán)依賴。?

參考: http://c2.com/cgi/wiki?AcyclicDependenciesPrinciple ?

?

[ 轉(zhuǎn)自 : http://www.iteye.com/news/20930 ]

一些軟件設計的原則


更多文章、技術交流、商務合作、聯(lián)系博主

微信掃碼或搜索:z360901061

微信掃一掃加我為好友

QQ號聯(lián)系: 360901061

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。

【本文對您有幫助就好】

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描上面二維碼支持博主2元、5元、10元、自定義金額等您想捐的金額吧,站長會非常 感謝您的哦!!!

發(fā)表我的評論
最新評論 總共0條評論
主站蜘蛛池模板: 荡女人人爱np粗口 | 99在线免费视频 | 5566中文字幕亚洲精品 | 伊人色婷婷综在合线亚洲 | 国产精品久久久久亚洲 | 精品欧美高清一区二区免费 | 四虎在线影院 | 在线视频精品一区 | 国产成人高清视频免费播放 | 久操热久操 | 欧美性啪啪| 一级全黄色毛片 | 色综合网亚洲精品久久久 | 久久综合综合久久狠狠狠97色 | 日韩一区二区三区在线免费观看 | 日韩欧美第一区二区三区 | 神马老子不卡视频在线 | 婷婷激情五月 | 永久看日本大片免费 | 亚洲一区二区三区免费 | 韩日精品在线 | 亚洲另类视频在线观看 | 日韩中文一区 | 国产美女流白浆 | 99国产精品久久久久久久成人热 | 在线亚洲成人 | 天天干天天操天天透 | 99亚洲精品| 久久久精品久久视频只有精品 | 中文字幕一区2区3区 | 狠狠色噜噜狠狠狠狠 | 亚洲精品99久久一区二区三区 | 伊人婷婷色香五月综合缴缴情 | 青青操在线观看 | 婷婷在线网| 国产91一区二这在线播放 | 亚洲国产精品久久久久婷婷软件 | 88国产精品视频一区二区三区 | 国产另类图片 | 免费福利视频网 | 免费的爱爱视频 |