posted @ 2006-09-12 23:36 JavaExplore 閱讀(6544) | 評論 (15) | 編輯 收藏
2、狀態:和策略非常接近,使用于有明顯狀態變化的時候
3、命令:命令的發起與執行解藕,命令類可以獨立演化,有助于做redo undo操作以及記錄所執行的命令
4、解釋:用于文法的解析
5、迭代子:java中有現成的實現,iterator
6、觀察者:常見,類似與模型視圖的關系,java中提供了oberver類和observable接口
7、調停者:處理混亂的類交互,抽象出中間類,將類間的交互都通過這個類完成
8、模版:將擁有同一父類的多個具體子類的共同操作提取出來形成抽象模版類
???????? 原則:具體的私有屬性應該放到具體類中,抽象類中調用屬性通過屬性方法而不是直接調用屬性
?????????????? 將私有屬性放到具體的類中,才能方便對父類進行多個實現。
???????? 將行為看作劃分類的標準,以前我都是將數據模型看作劃分類的思想,以后應該重新審視行為在類中的重要作用,特別是在的繼承等級中。
posted @ 2006-09-12 23:33 JavaExplore 閱讀(378) | 評論 (0) | 編輯 收藏
1 簡介
JFreeChart 是 SourceForge.net 上的一個開源項目,它的源碼和 API 都可以免費獲得。 JFreeChart 的功能非常強大,可以實現餅圖 ( 二維和三維 ) , 柱狀圖 ( 水平 , 垂直 ), 線圖 , 點圖 , 時序圖 , 甘特圖 , 股票行情圖 , 混和圖 , 溫度計圖 , 刻度圖等常用商用圖表, 圖形可以導出成 PNG 和 JPEG 格式,同時還可以與 PDF 和 EXCEL 關聯,支持對圖形的放大、縮小,支持常見圖形的 3D 顯示。
2 圖形 對象的處理
2 .1 JFreeChart對象
JFreeChart 可以生成很多圖形對象,它的工廠類提供了 33 個工廠方法用于生成不同的圖形對象(具體的工廠方法可以參見 JFreeChart 的 API 手冊或者源碼中的 ChartFactory 類 )。 JFreechart 對圖形對象的抽象具體化。圖形對象( JFreeChart ),由 Title( 主標題 ) , SubTitle (子標題 ) , Plot (圖形的繪制結構)等幾個主要對象組成。各個組成部分如下圖所示:
這是一個 JFreeChart 對象,上面的“ chart 標題”是 Title 對象,中間區域是 Plot 對象(包括繪圖區域和坐標軸區域),下面的區域是 LegendTitle 對象,是一種 SubTitle 對象。
每個 JFreeChart 對象只能有 1 個 Title 對象, 1 個 Plot 對象,可以有多個 SubTitle 對象。 JFreeChart 對象可以進行的操作有:背景的設置(背景顏色、背景圖片、透明度等)、邊框的設置(是否可見、筆畫、 Paint 等)、渲染方式的設置、標題對象的設置、子標題對象的增刪查操作。(本文中的所有操作都不提供代碼級的介紹,可參見 API 手冊或者源碼)
2 .2 主標題對象
主標題對象是 TextTitle 類型,可以進行的操作有:背景設置、字體設置(字體類型、顏色、內容、對齊方式等操作)、 tooltip 設置、 URL 設置。
2 .3 Plot 對象
Plot 對象是圖形的繪制結構對象。 JFreeChart 中含有很多不同的 Plot 對象,每一種圖形對象中的 Plot 對象都在實例化的時候創建。所有的 Plot 共有的操作有:背景設置(背景顏色、背景圖片、透明度等)、前景透明度設置、無數據存在情況的設置(顯示的字符內容、顯示的字體、顯示的 Paint )、放大縮小比例的設置,大部分 Plot 對象還有設置 Datset 、設置 Renderer 對象操作。
JFreeChart 中有 18 種 Plot 抽象類的具體實現類。 Plot 的具體實現類主要由以下重要對象組成: Renderer 對象(圖形的繪制單元——繪圖域) Datset (圖形的數據源), DomainAxis (區域軸,相當于 x 軸), RangeAxis (范圍軸,相當于 y 軸)。不同的 Plot 對象組成方式不盡相同,有的不含有 Renderer 對象,比如 CompassPlot 、 ContourPlot 、 MultiplePiePlot 、 PiePlot 等,有的不含有 DomainAxis 、 RangeAxis 對象,另外除了 FastScatterPlot 類都含有 Datset 對象, FastScatterPlot 使用 float 的二維數組充當數據源。尤其說明一點,餅狀圖相關的 Plot 對象( MultiplePiePlot 、 PiePlot 、 PiePlot3D 、 RingPlot )中都不含有 Renderer 對象、 DomainAxis 對象、 RangeAxis 對象。
一般來說, Datset 對象存儲數據模型, Renderer 對象存儲顯示模型, Plot 對象根據 Datset 對象、 Renderer 對象完成畫圖操作。
仍以上面的圖形講解 Plot 對象的組成。
上圖的中間區域是是一個 XYPlot 對象。其中的折線部分即是圖形的繪制單元 Renderer 對象。 X 軸是 DomainAxis , y 軸是 RangeAxis ,其中 Datset 對象屬于數據模型范疇,是 UI 不可見對象。該圖中的 plot 背景色、網格線的各種設置可以通過 XYPlot 對象本身完成。
下面講解 Renderer 對象、 Axis 對象( X 軸、 y 軸都屬于 Axis 對象), Datset 對象在后續章節中專門講解。
2 .3.1 Renderer對象
Renderer 對象是圖形的繪制單元。 JFreeChart 提供了兩個接口 CategoryItemRenderer 和 XYItemRenderer 、 1 個抽象類 AbstractRenderer 供具體的 Renderer 類實現,給出了將近 50 種具體實現類。
一般來說 Renderer 對象可進行的操作有:對 item label (下圖中的柱狀圖上的紅色數字即為 item label 的示例)的默認設置( item label 的產生方式、是否可見、字體、 Paint 、正反向 item label 的位置設置等)、繪制圖形的邊框默認設置( Paint 、筆畫、是否可見等)、繪制圖形的默認設置(形狀、筆畫、是否可見、對應的圖例中是否可見等,折線圖還有線條是否可見、折點圖形是否可見、折點圖形是否填充、折點圖形的形狀、對應的圖例中線條是否可見、圖形是否可見、整體是否可見等)、以及對指定 item label 的設置、指定繪制圖形的設置。可以說和具體繪制的圖形相關的屬性都可以通過 Renderer 對象設置。
不同的 Renderer 的實現類實現了不同的顯示方式,在含有 Renderer 對象的 JFreeChart 對象中, R enderer 對象決定了JFreeChart對象的顯示方式。例如:柱狀圖的Plot對象中默認的Renderer對象是 CategoryItemRenderer 對象,通過設置 Plot 對象的Renderer對象 為 LineAndShapeRenderer ,則柱狀圖變為線圖。使用中一般不需要顯式的實例化一個 R enderer 對象,一般通過 JFreeChart 對象的 Plot 對象調用現有的 R enderer 對象進行重新設置等操作。
2 .3.2 Axis對象
JFreeChart 提供了兩種類型的坐標軸: CategoryAxis (等級軸)和 ValueAxis (值軸), ValueAxis 又有 3 個子類: DateAxis (時間軸)、 NumberAxis (數字軸)、 PeriodAxis (時期軸)。這些坐標軸還有更詳細的子類,不再一一列舉
Axis 對象可進行的操作有:標題的設置(內容、字體、Paint、顯示角度等)、坐標線的設置(筆畫、Paint、是否可見等)、刻度線的設置(是否可見、筆畫、Paint、位于繪圖區域的長度、位于繪圖區域外的長度等)、刻度標示的設置(筆畫、Paint、字體、與軸的距離等)、坐標軸范圍設置等。
CategoryAxis 對象還可以進行的操作有: 刻度標示間距 設置( 最小間距、最大間距、指定間距)等。
ValueAxis 對象可進行的操作有:軸端設置(顯示的圖形形狀)、范圍設置(是否自動產生范圍、自動產生的最小范圍、最大范圍、指定確定范圍、指定范圍大小等)、間隔設置(是否自動產生間隔、指定間隔)等。
DateAxis 對象還有對時間刻度顯示格式的設置操作。
2 . 4 子標題對象
子標題對象是 Title 類型的對象,一個JFreeChart可以有多個子標題對象。JFreeChart提供了5種Title的實現,可以是圖片、文本、圖例等的形式。
(數據源以及常用圖形的處理以及進一步的討論在后續文章中介紹)
posted @ 2006-09-01 23:21 JavaExplore 閱讀(9947) | 評論 (1) | 編輯 收藏
1、代理模式:參與角色:代理與真實實體共同的抽象角色、代理角色、真實實體角色
?????? 遠程代理:封裝對與遠程對象復雜的調用通訊過程,象調用本地對象一樣
?????? 虛擬代理:真實實體加載時間過長的,使用虛擬代理提供友好的顯示方式,一邊加載實際的對象
?????? 安全代理:調用真實的對象之前插入權限驗證模塊
?????? 智能引用代理:調用真實的對象之后調用統計等相關操作模塊
2、享元模式:參與對象:建造工廠、抽象享元、具體享元
?????? 分析對象的內蘊與外蘊狀態,即不變的私有屬性與變化的私有屬性。建造工廠使用備忘錄模式存儲已經建造的對象,建造對象的時候,以參數的形式傳遞享元對象的內蘊屬性。實際調用中,使用傳遞外部參數的方法使用外蘊變量。
?? 復合的享元對象組成的對象,不可以整體使用享元模式,但可以單個的享元對象屬性使用該模式
?? 優點:降低內存中的對象? 缺點:設計復雜性
???????
3、門面模式:結構模式。為包含有很多對象的子系統提供統一的操作接口類,所有對該子系統的調用都通過這個類,降低子系統之間調用的復雜度,也符合笛比特法則(一個對象的朋友盡量少,只與朋友說話)
4、橋梁模式:參與角色:抽象化角色、抽象化的具體角色、實現化角色、實現化的具體角色
?兩個有繼承等級的對象群,一個對象群對另一個對象群有調用關系的時候使用
??????? 目的:使抽象化與實現化解藕
posted @ 2006-09-01 23:08 JavaExplore 閱讀(728) | 評論 (0) | 編輯 收藏
???????? 今天去jdon,看了它的設計研究欄目,bang有幾篇評論單例模式的文章,聲稱“Singleton is evil”(見http://www.jdon.com/jive/article.jsp?forum=91&thread=17578),并且引用幾篇外文頁面佐證自己的觀點,其中有一篇文章更是說,單例不僅不是一種模式,而是一種反模式。
??????? 下面我談談我對單例模式的看法。逐一分析單例模式的陷阱,幫助大家正確使用單例模式。
(1)?陷阱一:調用函數的性能瓶頸
??????? 在c++中,單例只有一種實現方式——LazySingleton, 實現如下(本文全部使用java代碼):












LazySingleton將對象的初始化推遲到調用的時候。并且為了防止多線程環境下產生多個實例,使用synchronized關鍵字保證函數getInstance調用的線程安全。synchronized關鍵字的存在保證了只會產生一個對象,但也成了多線程環境下的性能瓶頸。一個多線程的程序,到了這里卻要排隊等候成了一個單線程式的執行流程,這在高并發環境下是不可容忍的。而c++中可以使用雙重檢查機制將這種性能問題僅僅限制在第一次構造對象的時候,而java中不可以使用雙重檢查機制。
????????但是java可以實現EagerSingleton,實現如下:










(2)陷阱二:訪問互斥共享資源
?????????EagerSingleton中訪問互斥資源也要考慮線程安全問題。下面看一個例子:



















(3)陷阱三:非法邏輯陷阱
??????? 這種情況一般是濫用單例模式造成的,下面考慮一種濫用單例的情況。下面的代碼的作用是getValueByName后,馬上printValue即完成操作流程。




















該類含有一私有屬性value,在多線程環境下不能保證value值的合理邏輯,一線程getValueByName后,馬上printValue,也有可能value的值已經被其他線程修改。這種情況就屬于單例模式的濫用,該類根本不適合做成單例。
??????? 消除非法邏輯的陷阱,可以通過將該類重構為純粹的行為類完成。重構后的代碼如下:




















通過調用printName(String name)直接完成操作流程,將其中的私有屬性處理成過程式的參數傳遞,將該類修改成純粹的行為類。
??????? 含有私有屬性并且含有對它賦值操作的類并非都會調入該陷阱,構造函數里進行對私有屬性賦值不會引起非法邏輯,如下代碼














構造函數里不必要加線程安全關鍵字也可以保證線程安全,因為類加載器是線程安全的,EagerSingleton只會在類加載的時候實例化一次,這樣不會出現單例模式的線程不安全,也不會造成非法邏輯。
(4)陷阱四:單例陷阱的傳遞
??????? 當含有對象作為單例類的私有屬性時,陷阱不僅會出現在該類本身,還會傳遞到私有對象所在的類中。看如下代碼:


















??????? 消除該陷阱的方法:(1)類方法的名稱要合理,比如純粹的行為方法名:interprete,excute,operation之類的方法中就不該含有對私有屬性直接或者間接的賦值操作,每個方法的責任要明確。(2)單例類中盡量不要含有非單例類的實例作為私有屬性(容器類除外),一定要有類的實例作為私有屬性的時候,重新審視這個作為私有屬性的類,是不是也應該設計成單例類;或者保證對它的初始化賦值限制在構造函數內。
posted @ 2006-08-26 11:26 JavaExplore 閱讀(4900) | 評論 (13) | 編輯 收藏
最近發現一本<java與模式>,正好再溫故一下當年的專業課內容,下面是這幾天記的筆記.(并不是系統的講解書中的內容)
一 綜述:
1、不要使用接口定義常量
2、自己少用標志接口
3、不要繼承具體類
4、類層次的中間節點應該是接口或者抽象類,葉子是具體類
5、子類應當擴展父類的責任,而不是覆寫父類的責任
6、面向接口編程
7、不要濫用繼承,組合優先于繼承
java中設計不當的類:calendar:作為接口,含有與具體的歷法(羅馬歷法)相關的常量,不能擴展到中國的陰歷歷法(不符合開閉原則)
properies類:濫用繼承,繼承至hashtable,應當使用聚合
8、笛比特法則:只與自己的直接朋友通信,不與陌生人通信(1)狹義笛比特法則:只與朋友通訊,通過自己的朋友傳遞間接的調用(2)結合依賴倒轉原則修改:不必通過朋友傳遞間接的調用,通過陌生人的抽象接口調用陌生人的行為(依舊不能與具體的陌生人發生通信)
9、盡量降低類中成員的訪問權限,不要設計退化類(類似c中struct)。
java中的point2D以及Dinmension2D類有這種設計缺陷(不過這種情況問題不大)
10、如果多個具體的產品類沒有共同的商業邏輯,就可以把它們抽象到一個接口中,如果有共同的商業邏輯,就把共同的部分抽象到抽象類中,共同的部分盡量向類繼承層次的上層移動,以達到復用的目的
二 工廠模式
1、簡單工廠模式:參與角色:工廠/抽象產品類/具體產品類
缺點:添加新產品的時候,雖然產品相關代碼符合開閉原則,但對工廠類本身并不符合,需要修改其中的產生產品方法或者添加新的產生方法(工廠里實現的不同造成的修改不同)來支持新的產品類
退化方式:省略掉工廠角色,抽象產品類擔任具體產品類的工廠角色:提供靜態的getInstance方法,比如java類庫中的DateFormat類,(本人認為這樣很不符合開閉原則,父類中出現與具體子類相關的代碼,不方便擴展,添加新產品的時候,修改的時候缺點與原簡單工廠的工廠角色類似)
2、工廠方法模式:參與角色:抽象工廠類/具體工廠類/抽象產品類/具體產品類
消除了簡單工廠的缺點
3、抽象工廠模式:簡單工廠模式與工廠方法模式的結合
4、單例模式:餓漢和懶漢兩種,前者將本身對象作為靜態私有屬性事先生成,后者推遲到調用的時候,后者需要考慮多線程的時候,前面需要加線程安全關鍵字(注意),java中還是前者為優。
不要濫用單例,只有系統要求只有一個類的實例的時候才調用
有的單例可能有狀態屬性,這就為多例模式提供了可能
含有私有屬性的類作成單例的時候尤其要注意:一是私有屬性的線程安全,確實需要的時候可以加線程安全關鍵字,比如系統中的log類,二是確認這些屬性是不是可以所有線程共享的,類似普通類的static
三 各種具體模式(1)
1、建造模式:參與角色4個:指導者、抽象建造對象、具體建造對象、產品
一個復雜的產品有很多的零部件,就可以使用具體的建造對象來一一構造
2、原始模式:深拷貝、淺拷貝
3、適配器模式:將adaptee類適配成目標接口
4、合成模式:參與角色:composite接口、樹枝節點類、樹葉節點類
分成透明式和安全式兩種,各有優缺點
(1)前者將管理子對象的方法放到接口中,這樣樹型結構中的所有對象都是透明的,都可以統一調用,但是葉節點并沒有管理子對象的能力,因此透明但不安全
(2)后者將管理子對象的方法下放到樹枝節點類中,這樣安全但不透明
5、裝飾模式:繼承已有類的接口,提供和已有類相同的方法,并對已有類的功能提供擴展(通過組合已有對象,調用已有對象方法的時候加入新的代碼)
(1)透明的裝飾模式(純粹的裝飾模式):裝飾類、被裝飾類繼承于同一接口,而且裝飾類只實現接口的方法,不提供額外方法的實現,調用該類的時候使用接口聲明調用(實例化當然還是自己的構造函數),即該類的所有方法都是透明的
(2)半透明的裝飾模式(退化的裝飾模式):裝飾類、被裝飾類繼承于同一接口,裝飾類不僅實現接口的方法,還提供額外方法的實現,這樣要調用它獨特的方法的時候就必須使用它本身來調用,退化到一半裝飾模式、一半適配器模式。
posted @ 2006-08-24 21:25 JavaExplore 閱讀(2114) | 評論 (6) | 編輯 收藏