一、設計模式在JDK中的應用(結合JDK源碼,分析JDK對設計模式的支持與應用)。課設內容包括:java
用UML類圖分析JDK所支持或應用的設計模式的結構,並與GOF的結構加以對比;舉例並演示相關類的應用;至少5種設計模式。編程
二、課程設計報告的內容及要求設計模式
報告必須手寫在學校指定的課程設計專用本上,類型一的報告內容以下:安全
第一章 設計模式概述app
第二章 JDK分析阿里雲
第三章 相關設計模式簡介(背景、UML結構、角色、職責)spa
第四章 設計模式在JDK中的應用(背景、UML結構、角色、職責)設計
第五章 應用實例代理
第六章 課設總結對象
參考文獻
附錄:應用實例代碼(打印)
1、特色:
一、單例類只能有一個實例。
二、單例類必須本身建立本身的惟一實例。
三、單例類必須給全部其餘對象提供這一實例。
單例模式確保某個類只有一個實例,並且自行實例化並向整個系統提供這個實例。
二.分類
(一)、懶漢式單例
//懶漢式單例類.在第一次調用的時候實例化本身
Singleton經過將構造方法限定爲private避免了類在外部被實例化,在同一個虛擬機範圍內,Singleton的惟一實例只能經過getInstance()方法訪問。
(事實上,經過Java反射機制是可以實例化構造方法爲private的類的,那基本上會使全部的Java單例實現失效。此問題在此處不作討論,姑且掩耳盜鈴地認爲反射機制不存在。) 點擊閱讀此篇
1、 概念
建造模式是對象的建立模式。建造模式能夠將一個產品的內部表象(internal representation)與產品的生產過程分割開來,從而可使一個建造過程生成具備不一樣的內部表象的產品對象。
一、產品的內部表象
一個產品常有不一樣的組成成分做爲產品的零件,這些零件有多是對象,也有可能不是對象,它們一般又叫作產品的內部表象(internal representation)。不一樣的產品能夠有不一樣的內部表象,也就是不一樣的零件。使用建造模式可使客戶端不須要知道所生成的產品有哪些零件,每一個 產品的對應零件彼此有何不一樣,是怎麼建造出來的,以及怎麼組成產品。
二、對象性質的建造
有些狀況下,一個對象的一些性質必須按照某個順序賦值纔有意義。在某個性質沒有賦值以前,另外一個性質則沒法賦值。這些狀況使得性質自己的建造涉 及到複雜的商業邏輯。這時候,此對象至關於一個有待建造的產品,而對象的這些性質至關於產品的零件,建造產品的過程是建造零件的過程。因爲建造零件的過程 很複雜,所以,這些零件的建造過程每每被「外部化」到另外一個稱作建造者的對象裏,建造者對象返還給客戶端的是一個所有零件都建造完畢的產品對象。點擊閱讀此篇
工廠模式
在面向對象編程中, 最一般的方法是一個new操做符產生一個對象實例,new操做符就是用來構造對象實例的。可是在一些狀況下, new操做符直接生成對象會帶來一些問題。舉例來講, 許多類型對象的創造須要一系列的步驟: 你可能須要計算或取得對象的初始設置; 選擇生成哪一個子對象實例; 或在生成你須要的對象以前必須先生成一些輔助功能的對象。在這些狀況,新對象的創建就是一個「過程」,不只是一個操做,像一部大機器中的一個齒輪傳動。
模式的問題:你如何能輕鬆方便地構造對象實例,而沒必要關心構造對象實例的細節和複雜過程呢?
解決方案:創建一個工廠來建立對象
1、引言
1)尚未工廠時代:假如尚未工業革命,若是一個客戶要一款寶馬車,通常的作法是客戶去建立一款寶馬車,而後拿來用。
2)簡單工廠模式:後來出現工業革命。用戶不用去建立寶馬車。由於客戶有一個工廠來幫他建立寶馬.想要什麼車,這個工廠就能夠建。好比想要寶馬系列車。工廠就建立這個系列的車。即工廠能夠建立產品。
3)工廠方法模式時代:爲了知足客戶,車系列愈來愈多,奔馳等系列,一個工廠沒法建立全部的車系列。因而由單獨分出來多個 具體的工廠。每一個具體工廠建立一種系列。即具體工廠類只能建立一個具體產品。
4)抽象工廠模式時代:隨着客戶的要求愈來愈高,車進行分類,分爲商務車和運動車兩個族點擊閱讀此篇
1、概述
定義:原型模式屬於對象的建立模式。經過給出一個原型對象來指明全部建立的對象的類型,而後用複製這個原型對象的辦法建立出更多同類型的對象。簡言之:就是複製粘貼。這就是選型模式的用意。
2、結構
原型模式主要用於對象的複製,它的核心是就是類圖中的原型類Prototype。Prototype類須要具有如下兩個條件:
一、實現Cloneable接口。在java語言有一個Cloneable接口,它的做用只有一個,就是在運行時通知虛擬機能夠安全地在實現了此接 口的類上使用clone方法。在java虛擬機中,只有實現了這個接口的類才能夠被拷貝,不然在運行時會拋出 CloneNotSupportedException異常。
二、重寫Object類中的clone方法。Java中,全部類的父類都是 Object類,Object類中有一個clone方法,做用是返回對象的一個拷貝,可是其做用域protected類型的,通常的類沒法調用,因 此,Prototype類須要將clone方法的做用域修改成public類型。點擊閱讀此篇
一、概述
適配器模式把一個類的接口變換成客戶端所期待的另外一種接口,從而使本來因接口不匹配而沒法在一塊兒工做的兩個類可以在一塊兒工做。
二、適配器模式的用途
即Adapter模式使得本來因爲接口不兼容而不能一塊兒工做的那些類能夠在一塊兒工做。
下面是兩個典型例子
1、概述
1.裝飾模式(Decorator)的定義:又名包裝(Wrapper)模式,裝飾模式以對客戶端透明的方式擴展對象的功能,是繼承關係的一個替代方案。
2.裝飾模式以對客戶端透明的方式動態的給一個對象附加上更多的責任。換言之客戶端並不會覺的對象在裝飾前和裝飾後有什麼區別。
3.裝飾模式能夠在不創造更多的子類的模式下,將對象的功能加以擴展。
2、裝飾模式的結構
裝飾模式的類圖以下:
代理模式
一、生活中:
代理就是一我的或者一個組織表明其餘人去作一件事的現實生活中的。在一些狀況下,一個客戶不想或者不可以直接引用一個對象,而代理對象能夠在客戶端和目標對象之間起到中介的做用。
二、官方:
代理模式是對象的結構模式。代理模式給某一個對象提供一個代理對象,並由代理對象控制對原對象的引用
1、靜態代理
類圖結構以下
1、定義
Facade(外觀)模式爲子系統中的各種(或結構與方法)提供一個簡明一致的界面,隱藏子系統的複雜性,使子系統更加容易使用。
2、結構
門面(Facade)角色 :客戶端能夠調用這個角色的方法。此角色知曉相關的(一個或者多個)子系統的功能和責任。在正常狀況下,本角色會將全部從客戶端發來的請求委派到相應的子系統去。
子系統(SubSystem)角色 :能夠同時有一個或者多個子系統。每一個子系統都不是一個單獨的類,而是一個類的集合(如上面的子系統就是由SystemA、SystemB、 SystemC三個類組合而成)。每一個子系統均可以被客戶端直接調用,或者被門面角色調用。子系統並不知道門面的存在,對於子系統而言,門面僅僅是另一 個客戶端而已。點擊閱讀此篇
1、定義
將抽象部分與實現(行爲)部分分離,使它們均可以獨立的變化。
橋接模式的作法是把變化部分(實現)抽象出來,使變化部分與主類(抽象)分離開來,從而將多個維度的變化完全分離。最後,提供一個管理類(以下面的引擎類)來組合不一樣維度上的變化,經過這種組合來知足業務的須要。
2、結構
圖-橋接模式結構圖