<tt id="a3jom"></tt>
    1. <tt id="a3jom"><noscript id="a3jom"></noscript></tt>

        <tt id="a3jom"></tt>

        《Java設計模式》PPT課件

        上傳人:xt****7 文檔編號:176503475 上傳時間:2022-12-22 格式:PPT 頁數:46 大?。?07KB
        收藏 版權申訴 舉報 下載
        《Java設計模式》PPT課件_第1頁
        第1頁 / 共46頁
        《Java設計模式》PPT課件_第2頁
        第2頁 / 共46頁
        《Java設計模式》PPT課件_第3頁
        第3頁 / 共46頁
        資源描述:

        《《Java設計模式》PPT課件》由會員分享,可在線閱讀,更多相關《《Java設計模式》PPT課件(46頁珍藏版)》請在裝配圖網上搜索。

        1、Java設計模式錢江Java設計模式p軟件設計模式基礎p面向對象設計原則p創建模式p結構模式p行為模式軟件設計模式基礎p什么是設計模式廣義講,軟件設計模式是可解決一類軟件問題并能重復使用的軟件設計方案狹義講,設計模式是對被用來在特定場景下解決一般設計問題的類和相互通信的對象的描述。是在類和對象的層次描述的可重復使用的軟件設計問題的解決方案模式體現的是程序整體的構思,所以有時候它也會出現在分析或者是概要設計階段 模式的核心思想是通過增加抽象層,把變化部分從那些不變部分里分離出來軟件設計模式基礎p模式的基本要素模式的基本要素模式名稱模式名稱(Pattern Name)(Pattern Name)問

        2、題問題(Problem)(Problem):描述應該在何時使用模式。解釋了設計問題和問題存在的前因后果,可能還描述模式必須滿足的先決條件解決方案解決方案(Solution)(Solution):描述了設計的組成成分、相互關系及各自的職責和協作方式。模式就像一個模板,可應用于多種場合,所以解決方案并不描述一個具體的設計或實現,而是提供設計問題的抽象描述和解決問題所采用的元素組合(類和對象)效果效果(consequences)(consequences):描述模式的應用效果及使用模式應權衡的問題軟件設計模式基礎p如何描述設計模式如何描述設計模式u模式名和分類模式名和分類:模式名簡介的描述了模式的本

        3、質。u意圖意圖:設計模式是做什么的?它的基本原理和意圖是什么?它解決的是什么樣的特定設計問題?u別名別名:模式的其他名稱u動機動機:說明一個設計問題以及如何用模式中的類、對象來解決該問題的特定情景u適用性適用性:什么情況下可以使用該設計模式?該模式可用來改進哪些不良設計?如何識別這些情況?u結構結構:采用對象建模技術對模式中的類進行圖形描述u參與者參與者:指設計模式中的類和(或)對象以及它們各自的職責軟件設計模式基礎p如何描述設計模式如何描述設計模式u協作協作:模式的參與者如何協作以實現其職責u效果效果:模式如何支持其目標?使用模式的效果和所需做的權衡取舍?系統結構的哪些方面可以獨立改變?u實

        4、現實現:實現模式時需了解的一些提示、技術要點及應避免的缺陷,以及是否存在某些特定于實現語言的問題u代碼示例代碼示例:用來說明怎樣實現該模式的代碼片段u已知應用已知應用:實際系統中發現的模式的例子u相關模式相關模式:與這個模式緊密相關的模式有哪些?其不同之處是什么?這個模式應與哪些其他模式一起使用?動手實踐p從兩幅撲克牌中任意抽取10張牌,打印出相同的牌面向對象設計原則面向對象設計原則面向對象設計原則p單一職責原則(SRP,Single Responsibility Principle)p開放封閉原則(OCP,Open Closed Principle)p依賴倒轉原則(DIP,Dependenc

        5、e Inversion Principle)p接口隔離原則(ISP,Interface Segregation Principle)p里氏代換原則(LSP,Liskov Substitution Principle)面向對象設計原則p單一職責原則(SRP)對于單一職責原則,其核心思想為:一個類,最好只做一件事,只有一個引起它的變化。單一職責原則可以看做是低耦合、高內聚在面向對象原則上的引申,將職責定義為引起變化的原因,以提高內聚性來減少引起變化的原因。職責過多,可能引起它變化的原因就越多,這將導致職責依賴,相互之間就產生影響,從而大大損傷其內聚性和耦合度。通常意義下的單一職責,就是指只有一種單

        6、一功能,不要為類實現過多的功能點,以保證實體只有一個引起它變化的原因。專注,是一個人優良的品質;同樣的,單一也是一個類的優良設計。交雜不清的職責將使得代碼看起來特別別扭牽一發而動全身,有失美感和必然導致丑陋的系統錯誤風險。面向對象設計原則p開放封閉原則(OCP)開放封閉原則是面向對象所有原則的核心,軟件設計追求的目標就是封裝變化、降低耦合,而開放封閉原則就是這一目標的最直接體現。開放封閉原則,其核心思想是:軟件實體應該是可擴展的,而不可修改軟件實體應該是可擴展的,而不可修改的。也就是,對擴展開放,對修改封閉的。的。也就是,對擴展開放,對修改封閉的。因此,開放封閉原則主要體現在兩個方面:對擴展開

        7、放,意味著有新的需求或變化時,可以對現有代碼進行擴展,以適應新的情況對修改封閉,意味著類一旦設計完成,就可以獨立完成其工作,而不要對其進行任何嘗試的修改。實現開放封閉原則的核心思想就是對抽象編程,而不對具體編程,因為抽象相對穩定。讓類依賴于固定的抽象,所以修改就是封閉的;而通過面向對象的繼承和多態機制,又可以實現對抽象類的繼承,通過覆寫其方法來改變固有行為,實現新的拓展方法,所以就是開放的?!靶枨罂偸亲兓睕]有不變的軟件,所以就需要用封閉開放原則來封閉變化滿足需求,同時還能保持軟件內部的封裝體系穩定,不被需求的變化影響。面向對象設計原則p依賴倒轉原則(DIP)依賴倒置原則其核心思想是:依賴于抽

        8、象。具體而言就是高層模塊不依賴于底層模塊,二者都同依賴于抽象;抽象不依賴于具體,具體依賴于抽象。依賴一定會存在于類與類、模塊與模塊之間。當兩個模塊之間存在緊密的耦合關系時,最好的方法就是分離接口和實現:在依賴之間定義一個抽象的接口使得高層模塊調用接口,而底層模塊實現接口的定義,以此來有效控制耦合關系,達到依賴于抽象的設計目標。抽象的穩定性決定了系統的穩定性,因為抽象是不變的,依賴于抽象是面向對象設計的精髓,也是依賴倒置原則的核心。依賴于抽象是一個通用的原則,而某些時候依賴于細節則是在所難免的,必須權衡在抽象和具體之間的取舍,方法不是一層不變的。依賴于抽象,就是對接口編程,不要對實現編程。面向對

        9、象設計原則p接口隔離原則(ISP)對于接口隔離原則,其核心思想是:使用多個小的專門的接口,而不要使用一個大的總接口。具體而言,接口隔離原則體現在:接口應該是內聚的,應該避免“胖”接口。一個類對另外一個類的依賴應該建立在最小的接口上,不要強迫依賴不用的方法,這是一種接口污染。接口有效地將細節和抽象隔離,體現了對抽象編程的一切好處,接口隔離強調接口的單一性。而胖接口存在明顯的弊端,會導致實現的類型必須完全實現接口的所有方法、屬性等;而某些時候,實現類型并非需要所有的接口定義,在設計上這是“浪費”,而且在實施上這會帶來潛在的問題,對胖接口的修改將導致一連串的客戶端程序需要修改,有時候這是一種災難。在

        10、這種情況下,將胖接口分解為多個特點的定制化方法,使得客戶端僅僅依賴于它們的實際調用的方法,從而解除了客戶端不會依賴于它們不用的方法。分離的手段主要有以下兩種:1、委托分離,通過增加一個新的類型來委托客戶的請求,隔離客戶和接口的直接依賴,但是會增加系統的開銷。2、多重繼承分離,通過接口多繼承來實現客戶的需求,這種方式是較好的。面向對象設計原則p里氏代換原則(LSP)里氏替換原則核心思想是:子類必須能夠替換其基類子類必須能夠替換其基類。這一思想體現為對繼承機制的約束規范,只有子類能夠替換基類時,才能保證系統在運行期內識別子類,這是保證繼承復用的基礎。在父類和子類的具體行為中,必須嚴格把握繼承層次中

        11、的關系和特征,將基類替換為子類,程序的行為不會發生任何變化。同時,這一約束反過來則是不成立的,子類可以替換基類,但是基類不一定能替換子類。里氏替換原則,主要著眼于對抽象和多態建立在繼承的基礎上,因此只有遵循了里氏替換原則,才能保證繼承復用是可靠地。實現的方法是面向接口編程面向接口編程:將公共部分抽象為基類接口或抽象類,在子類中通過覆寫父類的方法實現新的方式支持同樣的職責。里氏替換原則是關于繼承機制的設計原則,違反了里氏替換原則就必然導致違反開放封閉原則。里氏替換原則能夠保證系統具有良好的拓展性,同時實現基于多態的抽象機制,能夠減少代碼冗余,避免運行期的類型判別。設計模式設計模式Java設計模式

        12、-創建模式p創建模式工廠模式(Factory)原型模式(Prototype)生成器模式(Builder)單態模式(Singleton)Java設計模式-創建模式p創建模式-工廠模式(Factory)工廠模式就相當于創建實例對象的new,雖然這樣做,可能多做一些工作,但會給系統帶來更大的可擴展性和盡量少的修改量。在實際應用中,工廠方法用得比較多一些,而且是和動態類裝入器組合在一起應用。u簡單工廠(SimpleFactory)u工廠方法(FactoryMethod)u抽象工廠(AbstractFactory)工廠模式-簡單工廠p簡單工廠UMLCreator+factory():ProductCon

        13、creteProductProduct工廠模式-簡單工廠p簡單工廠模式特點優點:模式的核心是工廠類,該類中含有必要的判斷邏輯,可以決定在什么時候創建哪一個產品類的實例,客戶端可以免除直接創建產品對象的責任,而僅僅負責“消費”產品。簡單工廠模式實現了對責任的分割。缺點:當產品類有復雜的多層次等級結構時,工廠類只有它自己。以不變應萬變。模式中工廠類集中了所有的產品創建邏輯,形成一個無所不知的全能類。將多個創建邏輯放在一個類中,當產品類有不同接口種類時,工廠類需要判斷在什么時候創建某種產品,使得系統在將來進行功能擴展時較為困難。該模式采用靜態方法作為工廠方法,而靜態方法無法由子類繼承,因此工廠角色無

        14、法形成基于繼承的等級結構。工廠模式-工廠方法p工廠方法UMLCreator+factory():ProductConcreteProduct1ProductConcreteProduct2ConcreteCreator1+factory():ProductConcreteCreator2+factory():Product工廠模式-工廠方法p工廠方法模式特點 優點:多態性:客戶代碼可以做到與特定應用無關,適用于任何實體類。子類提供掛鉤?;悶楣S方法提供缺省實現,子類可以重寫新的實現,也可以繼承父類的實現。-加一層間接性,增加了靈活性 連接并行的類層次結構。良好的封裝性,代碼結構清晰。擴展性好

        15、,在增加產品類的情況下,只需要適當修改具體的工廠類或擴展一個工廠類,就可“擁抱變化”。屏蔽產品類。產品類的實現如何變化,調用者都不需要關心,只需關心產品的接口,只要接口保持不變,系統中的上層模塊就不會發生變化。典型的解耦框架。高層模塊只需要知道產品的抽象類,其他的實現類都不需要關心,符合迪米特法則,符合依賴倒置原則,符合里氏替換原則。缺點:需要Creator和相應的子類作為factory method的載體,如果應用模型確實需要creator和子類存在,則很好;否則的話,需要增加一個類層次。工廠模式p抽象工廠UMLCreator+factoryA():ProductA+factoryB():P

        16、roductBProductA1ProductAProductA2ConcreteCreator1+factoryA():ProductA+factoryB():ProductBConcreteCreator2+factoryA():ProductA+factoryB():ProductBProductBProductB1ProductB2工廠模式-抽象工廠p抽象工廠特點優點:分離了具體的類,一個工廠封裝創建產品對象的責任和過程,它將客戶與類的實現分離 易于交換產品系列,只需改變具體的工廠就可以使用不同的產品配置。有利于產品的一致性,當一個系列中的產品對象被設計成一起工作時,一個應用一次只能使

        17、用同一個系列中的對象。缺點:難以支持新的產品等級結構,支持新的產品等級結構就要擴展抽象工廠接口。Java設計模式-創建模式p創建模式-原型模式(Prototype)Prototype模式允許一個對象再創建另外一個可定制的對象,根本無需知道任何如何創建的細節,工作原理是:通過將一個原型對象傳給那個要發動創建的對象,這個要發動創建的對象通過請求原型對象拷貝它們自己來實施創建。因為Java中的提供clone()方法來實現對象的克隆,所以Prototype模式實現一下子變得很簡單。Java設計模式-創建模式p創建模式-生成器模式(Builder)將一個復雜對象的構建與它的表示分離,使得同樣的構建過程可

        18、以創建不同的表示。Builder模式是一步一步創建一個復雜的對象,它允許用戶可以只通過指定復雜對象的類型和內容就可以構建它們。用戶不知道內部的具體構建細節。p為何使用是為了將構建復雜對象的過程過程和它的部件部件解耦。因為一個復雜的對象,不但有很多大量組成部分,如汽車,有很多部件:車輪、方向盤、發動機、還有各種小零件等等,部件很多,但遠不止這些,如何將這些部件裝配成一輛汽車,這個裝配過程也很復雜,Builder模式就是為了將部件和組裝過程分開。生成器模式p生成器模式UMLDirector-builder:Builder+Director()+construct():voidBuilder+bui

        19、ldPart1():void+buildPart2():void+getResult():ProductConcreteBuilder+buildPart1():void+buildPart2():void+getResult():ProductProduct1public void construct()builder=new ConcreteBuilder();builder.buildPart1();builder.buildPart2();builder.getResult();/other codeProduct生成器模式特點p生成器模式優點:他使你可以改變一個產品的內部表示它將構造

        20、代碼和表示代碼分開它使你可對構造過程進行更精細的控制Java設計模式-創建模式p創建模式-單態模式(Singleton)Singleton模式主要作用是保證在Java應用程序中,一個類Class只有一個實例存在。在很多操作中,比如建立目錄、數據庫連接都需要這樣的單線程操作。還有,Singleton能夠被狀態化;這樣,多個單態類在一起就可以作為一個狀態倉庫一樣向外提供服務,比如,你要論壇中的帖子計數器,每次瀏覽一次需要計數,單態類能否保持住這個計數,并且能synchronize的安全自動加1,如果你要把這個數字永久保存到數據庫,你可以在不修改單態接口的情況下方便的做到。另外方面,Singleto

        21、n也能夠被無狀態化,提供工具性質的功能。Java設計模式-結構模式p結構模式外觀模式(Facade)代理模式(Proxy)適配器模式(Adapter)組合模式(Composite)裝飾模式(Decorator)橋接模式(Bridge)享元模式(Flyweight)Java設計模式-外觀模式p結構模式-外觀模式(Facade)為子系統中的一組接口提供一個一致的界面,例如:數據庫JDBC的應用。Java設計模式-代理模式p結構模式-代理模式(Proxy)對于開銷很大的對象,只有在使用它時才創建,使用代理原則可以為我們節省很多寶貴的Java內存。Java設計模式-適配器模式p結構模式-適配器模式(A

        22、dapter)如何將兩個不兼容的類糾合在一起使用,通常的解決方案是:修改各自類的接口,但是如果我們沒有源代碼,或者我們不愿意為了一個應用而修改各自的接口,怎么辦?Java設計模式-組合模式p結構模式-組合模式(Composite)將對象組合成樹形結構以表示“整體部分”的層次結構。Composite模式使單個對象和組合對象的使用具有一致性。Composite將遍歷(Iterator)整個樹形結構,尋找同樣包含這個方法的對象并實現調用執行。Java設計模式-裝飾模式p結構模式-裝飾模式(Decorator)裝飾模式是在不必改變原類文件和使用繼承的情況下,動態的擴展一個對象的功能。它是通過創建一個包

        23、裝對象,也就是裝飾來包裹真實的對象。結構模式-裝飾模式p裝飾模式UMLComponent+operation():voidComcreteComponent+operation():voidDecorator+component:Component+Decorator()+Decorator(:Component)+operation():voidpublic void operation()component.operation();ComcreteDecoratorA-AddedState+operation():voidComcreteDecoratorB+operation():voi

        24、d+addBehavior()public void operation()super.operation();/在此或者其他地方添加行為,以擴展Component addBehavior();結構模式-裝飾模式p裝飾模式特點比繼承更靈活從為對象添加功能的角度來看,裝飾模式比繼承來得更靈活。繼承是靜態的,而且一旦繼承是所有子類都有一樣的功能。而裝飾模式采用把功能分離到每個裝飾器當中,然后通過對象組合的方式,在運行時動態的組合功能,每個被裝飾的對象,最終有哪些功能,是由運行期動態組合的功能來決定的。更容易復用功能裝飾模式把一系列復雜的功能,分散到每個裝飾器當中,一般一個裝飾器只實現一個功能,這樣

        25、實現裝飾器變得簡單,更重要的是這樣有利于裝飾器功能的復用,可以給一個對象增加多個同樣的裝飾器,也可以把一個裝飾器用來裝飾不同的對象,從而復用裝飾器的功能。簡化高層定義裝飾模式可以通過組合裝飾器的方式,給對象增添任意多的功能,因此在進行高層定義的時候,不用把所有的功能都定義出來,而是定義最基本的就可以了,可以在使用需要的時候,組合相應的裝飾器來完成需要的功能。會產生很多細粒度對象前面說了,裝飾模式是把一系列復雜的功能,分散到每個裝飾器當中,一般一個裝飾器只實現一個功能,這樣會產生很多細粒度的對象,而且功能越復雜,需要的細粒度對象越多。Java設計模式-橋接模式p結構模式-橋接模式(Bridge)

        26、Bridge模式是一種抽象與其實現相分離的模式。它主要應用于:當事物是一組變化量,和對這些事物的操作方法(實現)也是一組變化量的情況,也就是說它們都是多變的。Java設計模式-享元模式p結構模式-享元模式(Flyweight)運用共享技術有效地支持大量細粒度對象。也就是說在一個系統中如果有多個相同的對象,那么只共享一份就可以了,不必每個都去實例化一個對象。Flyweight模式是一個提高程序效率和性能的模式,會大大加快程序的運行速度。例如:Xml文件中的數據處理。Java設計模式-行為模式p行為模式 模板模式(Template)備忘機制模式(Memento)觀察者模式(Observer)職責鏈

        27、模式(ChainofResponsibility)命令模式(Command)狀態模式(State)策略模式(Strategy)中介者模式(Mediator)解釋器模式(Interpreter)參觀者模式(Visitor)Java設計模式-行為模式p行為模式-觀察者模式(Observer)定義對象間的一種一對多的依賴關系,當一個對象的狀態發生改變時,所有依賴于它的對象都將得到通知并自動更新。具體的說,如果我們希望網上商店的商品在名稱、價格等方面有變化時,系統就能自動通知會員,這時就需要使用Observer模式。行為模式-觀察者模式p觀察者模式UMLSubject-observersList:Li

        28、st+attach(Observer):void+detach(Observer):void+notifyObservers():voidConcreteSubject-state:String+change():voidObserver+update():voidConcreteObserver+update():void0.*public void change(String newState)this.state=newState;this.notifyObservers();行為模式-觀察者模式p觀察者模式特點 優點:觀察者模式在被觀察者和觀察者之間建立一個抽象的耦合。被觀察者角色所知

        29、道的只是一個具體觀察者列表,每一個具體觀察者都符合一個抽象觀察者的接口。被觀察者并不認識任何一個具體觀察者,它只知道它們都有一個共同的接口。由于被觀察者和觀察者沒有緊密地耦合在一起,因此它們可以屬于不同的抽象化層次。如果被觀察者和觀察者都被扔到一起,那么這個對象必然跨越抽象化和具體化層次。觀察者模式支持廣播通訊。被觀察者會向所有的登記過的觀察者發出通知 缺點:如果一個被觀察者對象有很多的直接和間接的觀察者的話,將所有的觀察者都通知到會花費很多時間。如果在被觀察者之間有循環依賴的話,被觀察者會觸發它們之間進行循環調用,導致系統崩潰。在使用觀察者模式是要特別注意這一點。如果對觀察者的通知是通過另外

        30、的線程進行異步投遞的話,系統必須保證投遞是以自動的方式進行的。雖然觀察者模式可以隨時使觀察者知道所觀察的對象發生了變化,但是觀察者模式沒有相應的機制使觀察者知道所觀察的對象是怎么發生變化的。Java設計模式-行為模式p行為模式-策略模式(Strategy)具體的說,就是定義一系列的算法,把這些算法封裝成一個個單獨的類,在使用的時候就可以靈活的選用。策略模式UML圖策略模式特點p優點:提供了一種替代繼承的方法,而且既保持了繼承的優點(代碼重用)還比繼承更靈活(算法獨立,可以任意擴展)。避免程序中使用多重條件轉移語句,使系統更靈活,并易于擴展。遵守大部分GRASP原則和常用設計原則,高內聚、低偶合。p缺點:因為每個具體策略類都會產生一個新類,所以會增加系統需要維護的類的數量。46Question?請填寫反饋表THANKYOU

        展開閱讀全文
        溫馨提示:
        1: 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
        2: 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
        3.本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
        4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
        5. 裝配圖網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
        6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
        7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
        關于我們 - 網站聲明 - 網站地圖 - 資源地圖 - 友情鏈接 - 網站客服 - 聯系我們

        網站客服QQ:2846424093或766697812

        copyright@ 2020-2023  zhuangpeitu.com 裝配圖網版權所有   聯系電話:0512-65154990  

        備案號:蘇ICP備12009002號-6   經營許可證:蘇B2-20200052  蘇公網安備:32050602011098


        本站為文檔C2C交易模式,即用戶上傳的文檔直接被用戶下載,本站只是中間服務平臺,本站所有文檔下載所得的收益歸上傳人(含作者)所有。裝配圖網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對上載內容本身不做任何修改或編輯。若文檔所含內容侵犯了您的版權或隱私,請立即通知裝配圖網,我們立即給予刪除!

        特级毛片a片全部免费播,特级毛片a片全部免费观看,特级毛片免费无码不卡观看,特级全黄a片高清视频

        <tt id="a3jom"></tt>
        1. <tt id="a3jom"><noscript id="a3jom"></noscript></tt>

            <tt id="a3jom"></tt>