摘要: JFreeChart 是一組功能強大、靈活易用的Java繪圖API,使用它可以生成多種通用性的報表,包括柱狀圖、餅圖、曲線圖、甘特圖等。目前 JFreeChart 的最新版本是 1.0.14 ……
閱讀全文
posted @
2012-08-07 00:03 fancydeepin 閱讀(6609) |
評論 (2) |
編輯 收藏
摘要: 適配器模式(Adapter 模式),將一個類的接口轉換成客戶希望的另外一個接口。Adapter 模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作 ……
閱讀全文
posted @
2012-08-05 16:50 fancydeepin 閱讀(1123) |
評論 (0) |
編輯 收藏
摘要: Builder 模式 —— 建造者模式(又譯成生成器模式)的主要功能是構建復雜的產品,它是將一個復雜對象的構建與它的表示分離,使得同樣的構建過程可以創建不同的表示...
閱讀全文
posted @
2012-08-05 14:03 fancydeepin 閱讀(5856) |
評論 (4) |
編輯 收藏
摘要: 依賴倒轉原則(Dependence Inversion Principle,簡稱DIP)講的是:
1)高層模塊不應該依賴底層模塊,兩個都應該依賴抽象。
2)抽象不應該依賴細節,細節應該依賴抽象。
依賴倒轉的另外一種表述是:要針對接口編程,不要針對實現編程。
也就是說,應該使用 java 接口或抽象 java 類進行變量的類型聲明、參量的類型聲明、方法的返回類型聲明、以及數據類型的轉換等;
不應該使用具體的 java 類型進行變量的類型聲明、參量的類型聲明、方法的返回類型聲明、以及數據類型的轉換等。
閱讀全文
posted @
2012-08-04 16:18 fancydeepin 閱讀(639) |
評論 (0) |
編輯 收藏
摘要: 里氏代換原則(LiskovSubstitution Principle,簡稱LSP)說的是:一個軟件實體如果使用的是一個基類的話,那么一定適用于其子類,而且它根本不能夠察覺出基類對象
和子類對象的區別。也就是說,在軟件實體里面,把父類都換成其子類,程序的行為是不會發生變化的。
里氏代換原則(LSP):子類型必須能替換掉它的父類型,反過來代換原則不成立。
里氏代換原則是繼承復用的基石,只有當衍生類可以替換掉基類,軟件單位的功能不會受到影響的時候,基類才能真正被復用,而衍生類也才能夠在基類的基礎上添加新的行為。
閱讀全文
posted @
2012-08-02 13:18 fancydeepin 閱讀(889) |
評論 (1) |
編輯 收藏
摘要: 所謂的開閉原則(Open-Closed Principle,簡稱 OCP)說的是:軟件實體(類、模塊、功能等)應該可以被擴展,但不可被修改。
開閉原則說白了就是,應該在不修改現有代碼的基礎上,引入新功能。
開閉原則中的“開”,是指對于組件功能的擴展是開放的,是允許對其進行功能擴展的;開閉原則中的“閉”,是指對于原有代碼的修改是封閉的,即不應該修改原有的代碼。
而實際上,要做到百分之百的封閉是不可能的,但是在系統設計的時候,還是應該盡量做到這一點。
閱讀全文
posted @
2012-08-02 11:03 fancydeepin 閱讀(871) |
評論 (0) |
編輯 收藏
摘要: 多例模式實際上就是單例模式的推廣,多例模式又劃分為有上限多例模式和無上限多例模式兩種,有上限多例模式中的多例類的實例是有上限的,
當這個多例類中的上限數值上等于 1 時,此時,多例類退化回到了單例類;而對于無上限多例模式中的多例類,它的上限是沒有限制的,也就是說它的上限數值是不確定的,
這個多例類并不一定能夠退化成單例類
閱讀全文
posted @
2012-07-31 17:44 fancydeepin 閱讀(4026) |
評論 (0) |
編輯 收藏
摘要:
閱讀全文
posted @
2012-07-31 11:29 fancydeepin 閱讀(20475) |
評論 (0) |
編輯 收藏
摘要: 工廠方法模式又稱為多態性工廠模式或虛擬構造子模式;與簡單工廠模式不同,在工廠方法模式中,核心的工廠類不再負責所有具體產品實例的創建,
而僅僅是需要負責給出具體工廠子類必須實現的接口,讓工廠子類去負責具體產品實例的創建。
閱讀全文
posted @
2012-07-30 17:43 fancydeepin 閱讀(1911) |
評論 (0) |
編輯 收藏
摘要: 簡單工廠模式又稱為靜態工廠方法模式,是工廠模式中的一種形態之一,是一個很根本的設計模式;
簡單工廠模式一般涉及三個角色:工廠角色、具體產品角色、抽象產品角色,模式的核心是工廠類,這個類含有必要的邏輯判斷,
它根據傳進的不同參數來判斷應當創建哪一個具體產品類的實例,而客戶端則可以免去直接創建具體產品實例,而僅僅負責"消費"產品,這種做法很好的實現了責任的分割。
閱讀全文
posted @
2012-07-30 14:36 fancydeepin 閱讀(1590) |
評論 (0) |
編輯 收藏
摘要: 不扯太多概念性的東西,簡單點來說,插入排序 將數組所有元素劃分為有序區和無序區,假設當前數組有 N 個元素,
開始默認第一個元素(下標為0)所處的位置是有序區,假設讓 i 指向無序區,第二個元素(i=1)至數組最后一個元素(i=N-1)屬于無序區;
假設數組元素是按從左至右存放的,則每趟排序是將下標 i 所指向的有效值插入有序區的適當位置,使得每趟排序完成之后,有序區的所有元素總是保持有序狀態。
按這樣來回 N -1 趟插入之后,則 N 個元素已成有序狀態。
閱讀全文
posted @
2012-07-19 00:20 fancydeepin 閱讀(2651) |
評論 (0) |
編輯 收藏
摘要: 與單向冒泡相似的,雙向冒泡排序就是在一趟排序完成之后,同時向兩端有序的將元素冒出,使得兩端總是保持有序狀態,中間無序。
假設有 N 個待排序元素,則最多只需要 N /2 趟排序,就能使得所有元素變成有序的了。由于最近在搞排序算法,當然,在寫這篇隨筆
之前也有在網上搜索過與雙向冒泡排序相關的資料,我找到的都是通過嵌套了 while 循環語句來實現雙向冒泡排序的,而我接下來的,
并沒有這樣做,而是直接在單向冒泡排序算法中直接來修改,這樣很容易的也能實現雙向冒泡排序;
閱讀全文
posted @
2012-07-18 17:55 fancydeepin 閱讀(1104) |
評論 (0) |
編輯 收藏
摘要: N 個元素數據需要進行 N - 1 趟排序,第 i 趟排序,需要對元素數據做兩兩比較 N - i 次,每趟排序完成之后,剩余較大的元素(升序)或較小的元素(降序)將冒到
數組最末端,此后,該項元素就此排定,不需要再移動。
閱讀全文
posted @
2012-07-18 15:25 fancydeepin 閱讀(690) |
評論 (0) |
編輯 收藏
摘要: maven3 入門;
如何創建一個 maven 項目;
eclipse maven3 HelloWorld;
閱讀全文
posted @
2012-07-13 13:06 fancydeepin 閱讀(17011) |
評論 (1) |
編輯 收藏
摘要: 前言:
逛開源社區的時候無意發現的,用了一段時間,覺得還可以,特此推薦一下。
lombok 提供了簡單的注解的形式來幫助我們簡化消除一些必須有但顯得很臃腫的 java 代碼。特別是相對于 POJO,光說不做不是我的風格,先來看看吧。
閱讀全文
posted @
2012-07-12 21:53 fancydeepin 閱讀(154854) |
評論 (8) |
編輯 收藏