第一篇：學習設計模式的一些感想

設計模式在編程中的應用

我們在發現問題到解決問題這個過程中，常會發現很多問題是重復出現的，或是某個問題的變體，外在不同，而本質相同，建筑學上如是，軟件行業也是，這些問題的本質就是模式。有人說，設計模式并不是一日兩日能夠理解的，當編程經驗到了一定程度，便迫切的需要設計模式來完善自己的代碼、優雅自己的設計，以及減少重復編碼，這句話也是蠻有道理的，以自己的親身經歷來說，當剛開始編程時，沒有一點設計理念，等到開設這門課以后再細讀理解，把里面的思想帶到自己的項目中，就會覺得有很多值得深思的地方。本文以我在以往項目中遇到的三個編碼問題來談談學習設計模式的必要性。

一、代碼量激增、程序可維護性面臨挑戰

我想這樣的代碼我們從學習C語言就開始接觸，現在很多地方還在用，以后工作可能用的更多但是，大家都寫的東西，我們自己的優勢在哪里呢？

1.過多的if?else判斷 if(type == 1){ //調用獲取信息方法1 } else if(type == 2){ //調用獲取信息方法2 ??.} else { //調用獲取信息方法7 } 這是我在做一個項目中看到的一段代碼，那個條件判斷非常之長，有7個條件分支，而且其他有些地方也有根據類型來做不同處理的情況。

2.多次載入資源（例如配置文件的讀取），引起資源損耗

public static String getProperty(String propKey)throws Exception...{ Properties prop = new Properties();InputStream propConfFile = Util.class.getClassLoader().getResourceAsStream(“configure.properties”);//載入propConfFile到prop中，從prop中獲取propKey的值，并將其返回 }

該段代碼是我以前在一個項目中寫的一段代碼，該段代碼用于讀取配置文件的屬性，但該段代碼是存在一些問題的，因為在每次獲取屬性時，它都重新載入資源，造成了資源的過多損耗。

3.過多依賴實現類

1）水果接口類—Fruit.java public interface Fruit { public void grow();}

2）水果的實現類—Apple.java、Strawberry.java //略

3）測試類—Test.java public class Test { public static void main(String[] args){ Fruit apple = new Apple();Fruit strawberry = new Strawberry();} } 在我們的項目中尚未采用Spring時，類似這樣的程序很多，與實現類的過度耦合是這段代碼存在的一個主要問題。

在我編碼的過程中，遇到的問題還有很多。不夠優雅的代碼、過于僵硬的設計，等等，通過改進如上編碼來認識學習設計模式給我們的編碼帶來的好處。

二、借“設計模式”之力沖出代碼包圍圈

如上的三段代碼，都是存在不少問題的，讓我們一一討論，通過在其中應用設計模式，來優化我們的這三段代碼，提高其擴展性和易維護性。

1.解決過多的if?else判斷問題

如果在一段代碼中，不少地方需根據某類型或狀態等做出不同的處理，那當類型或狀態增加時，這些代碼將會過于僵硬，擴展性差，只有在各個分布了if?else的再增加一個else if，可維護性可想而知。設計模式中有一種模式可以解決該問題，即狀態模式。狀態模式給我們帶來的好處如下：

1）狀態模式需要對每一個對每一個系統可能取得的狀態創立一個狀態類（State）的子類，當系統的狀態變化時，系統改變所選的子類。與一個特定的狀態有關的行為都被包裝在一個特定的對象里，而且當需要增加新的狀態時，可以以子類的方式將它加到系統里，從而提高了易維護性和可擴展性；

2）由于每一個狀態都被包裝到了類里面，避免了使用過多的條件轉移語句。

下面我們對該例進行演示性的改進。我們可以定義一個類型接口，該類相當于狀態模式中的狀態類。

public interface Type { /** * 獲取信息 */ public Object getInfo();/** * 獲取結果 */ public Object getResult();} 類型

1、類型2等可以實現該接口，代碼略：

2.解決過度資源損耗問題

在該例中，每次通過getProperty(?)方法獲取某屬性時，都會重新載入文件中的所有內容，造成資源的不必要損耗。該設計模式中，對于此種情況，可以通過單例（Singleton）模式來優化處理。import //略

public class PropertiesUtil...{ private static Map propertiesMap = null;public static String getProperty(String propKey)throws Exception...{ if(propertiesMap == null)...{ //當propertiesMap為空時，載入文件，將其鍵值對放入propertiesMap中(略)} //在propertiesMap中獲得propKey屬性，并將值返回（略）} }

可以考慮實現單例模式的地方還有很多，例如：

1）對于計算機的外部資源打印機的情況，因只有一個Printer Spooler，為避免兩個打印作業同時輸出到打印機中，可考慮用單例模式實現。

2）Window的回收站在整個系統中只有唯一的一個實例，而且回收站自行提供自己的實例，回收站也是單例模式的應用

3、解決過多依賴實現類問題

在該例的測試類Test.java中，通過Fruit apple = new Apple();來獲得對象，造成了程序過多的依賴實現類，與實現類過度耦合，學習設計模式后，我們可以考慮采用工廠模式來實現,可對代碼進行如下改進：增加工廠類FruitGardener.java，該類的工廠方法如下： public static Fruit factory(String fruitType)...{ if(fruitType.equalsIgnoreCase(“apple”))...{ return new Apple();} else if(fruitType.equalsIgnoreCase(“strawberry”))...{ return new Strawberry();} else...{ return null;} }

增加了水果工廠類后，測試類也要做對應修改，修改后的Test.java的main方法如下： Fruit apple = FruitGardener.factory(“apple”);Fruit strawberry = FruitGardener.factory(“strawberry”);

在進行了對應修改后，測試類大大減少了對水果實現類的依賴，由直接new實現類變成了通過傳入字符串來獲得需要的實例，工廠模式應用很廣泛，例如在現在紅得似火的spring也在不少地方用了工廠模式，它本身就是一個很大的bean工廠，不過它在代碼上進行了更大的改進，各實現類可以通過配置文件設置。

三、設計模式 –––– 由優秀邁向卓越的階梯

從以上三個例子中我們可以看出，通過使用設計模式，優化了我們的代碼。這樣的例子在我們日常的編碼過程中有很多，在我們剛開始學習編碼時，寫這樣的代碼還說得過去，但隨著經驗的增長，我們需要更進一步，現有的設計模式給我們提供了解決大多數問題的好方案，當然，在實踐的過程中，我們甚至可以探索出新的設計模式，來解決遇到的某類問題。

學習設計模式不是一蹴而就的，很多人嘆息設計模式似乎很不錯，然而在自己的編碼設計生涯中用得極少，我想主要原因是因為對設計模式的學習還不夠，還沒將其變成屬于自己腦袋里的東西，所以當問題變著面孔出現時，認識不到問題的存在，因為不能正確的分析問題、認識問題，當然也不可能很好的解決問題。

還未學習過設計模式或對其知之甚少的程序員們，努力學習設計模式吧，那將使你由一個優秀的程序員(Coder)成為一個卓越的軟件設計師(Developer)。

第二篇：分之合經營模式學習感想

分之合經營模式學習感想

3月14日到3月16日，我有幸參加了集團公司組織的分之合經營模式的學習培訓，受益良多，分之合經營模式是一種非常科學的管理方式，接下來我想談談我個人的一些想法。

隨著中國企業的規?；l展，企業管理變革成為新的課題，這種管理變革不是原有經營模式的簡單疊加，而是一種員工活力的持續創造。那么如何創造這種活力呢？分之合模式的本質是將企業分割成眾多小的組織體，各個組織體獨立核算、獨立經營，并培養具有經營意識的領導人，讓全體員工參與到企業經營中，實行類似家庭賬本式管理，是一種團結的經營模式，全體員工共同經營。

首先，劃分分之合經營單元規模大小的原則主要是每個組織體必須能獨立完成任務，有獨立的核算組織，同時，又不能因為組織的拆分影響公司的整體目標和經營計劃。劃分的決策權力在于其直接的上級管理者，只要管理者認為有必要且該團體滿足成為組織體的條件就可以進行劃分。把原本屬于企業的事，變成每個部門每個人的事情，大大激發全員的潛能。

其次，企業的利潤是來源于生產經營的各個部門、各個環節。各部門獨立經營、獨立核算的經營管理模式，就像土地改革將集體生產與管理模式變成了承包到戶生產管理模式，產量、質量、積極性會大幅度提高；而成本、費用、浪費會大幅度降低。讓每個員工找到了當老板的感覺，實現企業每個人為自己干、為自己經營與管理。

最后，通過推行分之合經營，能夠使老板在與不在一個樣，各級管理者在與不在一個樣，大家都在認真、埋頭自己的工作，忙而不亂，老板們一直期望的理想管理模式真正變成了現實?，F在如果工作達不到日清日畢，大家會主動愉快的偷著加班。所以說分之合經營模式是從骨髓里給管理者和員工注入了瘋狂為自己工作的基因。經營企業最終是經營人才，經營人才的核心是經營人心，當企業規模擴大，員工人數增加，員工的思想統一是企業能夠產生合力的基礎。分之合經營模式雖然是將企業劃分成很多小經營單元，但是這些小單元不是各自為政，而是有著統一思想的同心力。它可以充分發揮企業管理的兩種力量：無形力量——企業文化；有形力量——自主經營，實現員工群策群力，上下同欲，并發揮每個員工的積極性和創造性。

要真正認知和實現分之合管理還需要很多工作去做，畢竟現在的管理模式較分之合還存在較大的差距。必須要讓全體的員工認識這種管理模式的好處，讓全體自動自發的進行改革和探索，逐漸排除職工的抵觸情緒。為此我部門計劃完成以下相關的工作：

一、組織本部門員工對分之合經營模式進行系統的學習，加深對分之合經營模式的了解；

根據集團公司要求，在3月31日前完成全員學習分之合管理模式文字版本和視頻內容的學習，全員貫徹分之合的管理理念，利用部門例會時間對學習的效果進行隨機的抽查提問。

二、根據分之合管理模式對本部門人員及崗位設置情況進行重新劃分，現場巡檢及資料管理區分，明確個人工作職責，后續制定相應的考核。

三、對辦公室進行整理、整頓，對現場3s落實情況進行監督； 更換辦公室后，對辦公室物品擺放進行定位，有用的物品分類放到指定位置，閑置的退回倉庫，根據實際情況將辦公室布置用圖表的形式表達出來，為實現目視化管理奠定基礎，日常巡檢中對現場區域衛生、設備等清掃情況進行監督檢查。

分之合管理模式對多數人來說是一個全新的管理模式，改變需要有一個過程，并且現階段對于分之合流程內的好多概念還很模糊，真正實現起來還有一定的難度。但我們有信心在集團公司的指導下，在化工各部門的配合下，通過部門協作和配合將分之合經營管理落實到實處，為集團公司實現分之合管理做好基礎和鋪墊。

第三篇：設計構成 學習感想

設計構成一轉眼間，設計構成的課已經結束了。平面構成，色彩構成，立體構成，三大構成已經都學完了。

在學習習近平面構成的過程中，知道了構成平面的元素是點。線。面。重復，近似，漸變，發射，突變，集結，對比是基本的構成形式。每一個都做了相應的練習，更加深刻了解了每一個形式。重復

骨骼與基本形都具有重復性質的構成形式，稱為重復構成。在這種構成中，組成骨骼的線都必須是相等比例的重復組成。骨骼線可以有方向和寬窄等變動，但必須是等比例的重復。對基本形的要求，可以在骨骼內重復排列，也可以有方向、位置的變動

近似

骨骼與基本形變化不大的構成形式，稱為近似構成。近似構成的骨骼可以是重復或是分條錯開的，但近似主要是以基本形的近似變化來體現的。

漸變

骨骼與基本形具有漸次變化性質的構成形式，稱為漸變構成。漸變構成有兩種形式，一種是骨骼漸變，通過變動骨骼的疏密比例取得漸變效果；另一種是基本形漸變，通過基本形的有規律的變動(如方向、大小和位置等變動)而取得漸變效果

發射

骨骼線和基本形呈發射狀的構成形式，稱為發射構成。這種類型的構成是骨骼線和基本形用離心式、向心式、同心式及其他幾種發射形式相疊而成的。

突變

在重復、漸變等規律性骨骼或基本形中一種特異變化的構成形式稱為突變構成，這種構成是有意識地在規律性變化中出現輕微的差異或是局部的突破，而產生幾個不規則的變異，但又大致保持某種規律。密集

密集構成是比較自由性的構成形式，包括預置形密集與無定形密集兩種。

預置形密集是依靠在畫面上預先安置的骨骼線或中心點組織基本形的密集與擴散，即以數量相當多的基本形在某些地方密集起來，而從密集地又逐漸散開來。

無定形的密集不預置點與線，而是靠畫面的均衡。即通過密集基本形與空間、虛實等產生的輕度對比進行構成。

對比

有一種較之密集構成更為自由性的構成稱為對比構成，這種構成不以骨骼線而僅依靠基本形的形狀、大小、方向、位置和色彩等的對比，以及重心、空間、有與無、虛與實的關系元素的對比，給人以強烈且鮮明的感覺。

接下來學習了立體構成。立體構成是一門研究在三維空間中如何將立體造型要素按照一定的原則組合成賦予個性的美的立體形態的學科。

整個立體構成的過程是一個分割到組合或組合到分割的過程。任何形態可以還原到點、線、面，而點、線、面又可以組合成任何形態。

立體構成的探求包括對材料形、色、質等心理效能的探求和材料強度的探求，加工工藝等物理效能的探求這樣幾個方面。

立體構成是對實際的空間和形體之間的關系進行研究和探討的過程。

半立體是以平面為基礎將其部份空間立體化，是介于平面與立體之間的形狀，即一般所稱的“浮雕”。半立體的主要特性表現在凹凸的層次感和光影的效果上，它足以使單調的平面產生各種不同的變化。

半立體是在有限的空間(淺浮雕)中充分發揮想像力，強調層次感和多種手法及技巧，用折、曲、切、接、編等技巧盡可能地創造出變化的立體形態。

練習了點線面的立構體形式，運用了泡沫，鋼絲，木頭，毛線等工具，做了立體作業。

立體構成教學是設計的專業基礎課程，它是立足于對立體造型可能性的探索，而完全不考慮造型的功能等因素．旨在討論、研究立體造型的原理、規律和構造訓練。立體構成的學習、訓練不是目的，而是提高、完善現代設計能力的重要手段。對某些立體造型設計的內容做些簡單的介紹和分析．從而進一步了解立體構成在各類設計中的運用，加強認識立體構成學習的重要性。

設計是包括立體構成在內、并考慮其它眾多要素，使之成為完整造型的活動。設計的領域非常廣泛，它可分為商業設計、工業設計、環境藝術設計等門類，而這些藝術門類還可以細分為廣告設計、書籍設計、包裝設計、廣告設計、展示設計、服裝設計、染織設計、室內外環境設計等專業門類。

立體構成與設計是有區別的。立體構成研究的內容是將涉及到各個藝術門類之間的、相互關聯的立體因素，從整個設計領域中抽取出來，專門研究它的視覺效果構成和造型特點，從而做到科學、系統、全面地掌握立體形態。

立體構成與具體的藝術門類區別很大，在整個立體構成的訓練過程中沒有具體目的的條件限制（如專為某一種產品設計造型）。因此，每一項練習就必須從立體造型的角度去研究形態的可能性和變化性。

立體構成能為設計提供廣泛的發展基礎。立體構成的構思不是完全依賴于設計師的靈感，而是把靈感和嚴密的邏輯思維結合起來，通過邏輯推理的辦法，并結合美學、工藝、材料等因素，確定最后方案。立體構成可以為設計積累大量的素材。立體構成的目的在于培養造型的感覺能力、想象能力和構成能力，在基礎訓練階段，創造出來的作品可成為今后設計的豐富素材。立體構成是包括技術、材料在內的綜合訓練，在立體的構成過程中，必須結合技術和材料來考慮造型的可能性。因此，作為設計者來講，不僅要掌握立體造型規律，而且還必須了解或掌握技術、材料等方面的知識和技能。

人們生活在各種三維的形態環境中，從日常使用的各種物品，到所居住的環境，乃至人類自身和整個宇宙，無一不是三維形態。因此，與二維空間相比，三維空間與人類更加息息相關。人們雖然生活在三維形態中，但常常習慣于從平面的角度去思考、在平面上表現造型，無形中具有平面的造型觀念和意識。因此，從平面到立體，從二維到三維必須要有立體的空間意識和觀念，掌握三維造型的基本原理和知識。

作為藝術設計基礎之一的立體構成，就是培養人的空間想象能力和意識，研究和探討在三維空間中如何用立體造型要素和語言，按照形式美的原理創造出富有個性和審美價值的立體空間形態的學科。通過對立體形態進行科學、系統的分析和研究，掌握立體造型的基礎知識和表現手法，從而創造出新的藝術形態。

立體構成由于自身的構成性，因而具有極強的理性特征，并運用分解與組合的方法予以體現。所謂分解就是將一個完整的造型對象分解為若干個基本造型要素，實際上是將形態還原到最原始的基本狀態；而組合則是直接將最基本的造型要素按照立體造型原理重新組合成新的形態的設計。

第四篇：哪些設計模式最值得學習

回想起來，這幾年在園子里發布的有關設計模式的隨筆都有一個共同的特點。那就是

Factory和Singleton居多，如果是系列的，也往往是從這兩個模式開始的。由于能夠堅持把《設計模式》中所有模式都寫完的非常少，所以基本上也很少見到有關其它模式的隨筆。這種情況也很好理解，因為《設計模式》這本書就是按照這個順序來的。最先講述的就是Abstract Factory模式，于是它排第一也無可厚非；排第二的Builder基本不太容易見到；第三的Factory Method由于也叫“Factory”所以往往和Abstract Factory放在一起，或者干脆就混淆了； 第四的Prototype也不是太容易見到；第五位的Singleton簡單易懂，易學易用。而再往后的模式，恐怕作者們就沒什么耐心學下去了……這可能就是為什么Factory和Singleton出現頻率如此之多的原因吧。

《設計模式》已經出版超過15年了，到今天已經不是什么新鮮的東西了，可以說正在由“絕招”慢慢向著“基本功”轉變著。然而，這種學習模式的方式方法卻實在令人擔憂。Abstract Factory在實際中并不常見，因為它需要你有兩套并行的繼承體系，需要對同一個抽象有多于一種的實現方式。這種復雜的系統可以說不是每個領域，每個開發人員都能遇到的。在某些特定的領域可能很常見，但是在大多數領域并不需要這么復雜的對象創建方法。這就造成了很多人“殺雞用宰牛刀”，用復雜的方式，解決不那么復雜的問題。后果是增加了不必要的復雜度，給系統維護增加了困難。

另一個模式Singleton，由于實現簡單，意圖“似乎”也很明顯。被很多人用來作為“優化”的一種方式。通過這種方式來節省內存空間，減少對象實例。但是單一實例本身就等同于全局變量，而全局變量在幾十年前就已經被證明是“反模式”了，用另一種形態的全局變量來代替另一種形態的全局變量有什么好處么？問題在與，Singleton的“意圖”并不在于優化，而是在于“妥協”。Singleton的目的在于保證對象有單一的實例，這是因為對象必須要有單一的實例，如果存在多個實例，可能會引發錯誤。也就是說，Singleton以犧牲程序的清晰

和可維護性，來達到保證程序正確的目的。這跟本就和優化八竿子打不著，這完全是一種設計上的妥協，犧牲一些好處來獲取更大的好處。如果僅僅是為了節省幾個對象實例，而非程序的正確才使用Singleton，那就是丟了西瓜揀芝麻。況且節省那幾個實例也跟本就不可能對程序的性能有太大的影響（特殊領域除外）。

人的時間是有限的，23個模式也不是都那么常用，哪些模式才是最經常用到的，才是最值得學習的呢？

第一梯隊：Iterator，Observer，Template Method，Strategy

Iterator：LINQ，foreach這不都是Iterator么。

Observer：MVC的核心，.NET中事件就是Observer。

Strategy：對同一個行為有不同實現的時候，如果考慮將行為的實現委托（不是.NET中的委托）給另一個類，那就用到了Strategy。通過這種方式，可以簡單的替換算法的實現類，來達到更換算法的目的。

class Foo

{

private IBar bar;

public Foo(IBar bar)

{

this.bar = bar;

}

public void DoSomething()

{

//some code

bar.DoWhatYouWant();

//some code

}

}

class A : IBar

{

public void DoWhatYouWant()

{

//do in A's way

}

}

class B : IBar

{

public void DoWhatYouWant()

{

//do in B's way

}

}

Template Method：一個算法的同一個步驟有不同的實現，通過繼承來實現。這種方式通過創建子類來改變算法的實現和行為。ASP.NET WebForm中Page的OnInit，OnLoad等事件，就是Template Method。

class Foo

{

public void DoSomething()

{

//some code

DoWhatYouWant();

//some code

}

protected abstract void DoWhatYouWant();

}

class A: Foo

{

protected override void DoWhatYouWant();

{

//do in A's way

}

}

class B: Foo

{

protected override void DoWhatYouWant();

{

//do in B's way

}

}

面向對象的一個重要特點就是多態，也就是對于同一個動作有不同的行為。Strategry通過委托的方式，將一個算法的不同實現委托給其它類；Template Method通過繼承的方式，讓子類實現算法的可變部分，基類則處理算法的流程和不變部分。近年來組合優于繼承的觀點已經成為主流，因此Strategy的處境頻率相對高一些，但是Template Method在解決簡單問題的時候更好用，只要注意繼承層次不要太多（<=3）就好。

第二梯隊：Adapter，Facade，Decorator

Adapter：當你需要使用第三方庫，但是又不想太依賴于它的API，以便于今后在需要時可以方便的切換到另一個庫的時候，你就需要在你的代碼和第三方API之間放置一個抽象層，也就需要用Adapter模式了。比如你想使用log4net，如果直接在代碼中到處引用log4net的API，將來有一天需要切換到另一個庫比如EntLib，你的改動量可就大了去了。如果在一開始就自己設計一個API，在代碼中使用自己的API，再用Adapter模式將log4net的API包裝到自己的API中，如果有一天想要切換到Entlib，只要為EntLib在寫一個Adapter就行了。對于IoC框架也是一樣的。不過需要注意的是，如果第三方庫的API接口非常龐大，使用Adapter就會很麻煩，因為你需要包裝太多的東西，那么使用Adapter可能就不是一個太好的主意。或許謹慎考慮確定一個不太可能會變化的第三方庫更好一些。

Facade：基本上用于簡化API，隱藏細節，在一個系統中，高層模塊調用低層模塊時，如果低層模塊API比較復雜，而高層模塊并不需要這種復雜度，那么加一個Facade，可以簡化高層模塊使用API的難度。

Decorator：為一個類的行為增加行為，比如ASP.NET MVC中的Action Filter。第三梯隊：Command，State，Composite

Command：統一接口，Undo/Redo。

State：當你的model有多種狀態，model的行為在每種狀態下并不一樣的時候，就需要用State。如果你有多個相似的Switch，那也可能意味著需要用State來代替Switch。

Composite：ASP.NET WebForm的Page和Control就是一個例子。

這些模式和分類只是憑我的感覺，并沒有任何實際的數據做支持，而我的感覺也只來源于我所接觸到的領域和代碼。希望同學們也可以提供自己接觸到的代碼中，最常見到和用到的模式。

第五篇：JAVA學習書籍- 設計模式

談到設計模式很多人多會推薦GOF 的那本，該書在Amzon上是五星級的推薦書籍。不過對于學習java 沒多久的、特別是java 初學者，我很不推薦這本書。主要是該書的例子基本都是C++的，很多細節沒有講述得足夠清楚。

我給大家推薦的第一本是閻宏博士的《Java 與模式》，它是第一本中國人自己寫的關于設計模式的書籍，寫的比較有趣，融合了很多中

華民族的文化和觀念，例子、類圖都比較多，且相對簡單！非常不錯的入門書籍――又是大塊頭哦！

其次我推薦Wiley 出版社出版的《Pattern In Java》一套三本，我才看了第一本，好像第二本不怎么樣，第三本還不錯！

第三本是中文翻譯版的關于多線程模式的（很難得的中文翻譯版）中國鐵道出版社2003 年出版的《Java 多線程設計模式》，將多線程模

式講得非常淺顯，配有大量的圖例，每章都有習題，最后有答案！我研究多線程模式就是由它開始的！

第四本，今年出版的Head First 系列的《Head First Design Pattern》，秉承Head First 系列圖書的優點，大量的類圖、豐富的實例、有趣的注解，值得購買！

其次在J2EE 方向你可以研究閱讀Addison Wesley 2002 年出版的《Patterns of Enterprise Application Architecture》，眾多大腕的作品，講企業消息集成的！Sun 提供的《J2EE PATTERNS SL500》也很好！晚了推薦那一本Amzon 4 星半的《Holub on patterns》，大師的作品，提供了，很值得研究的例子，不過對上面四本不是很熟悉的讀者，最好不要讀它！可能會讓你比較累！

我學習設計模式經過一段很曲折的路線，前前后后大約看了20 本，閻宏博士的《Java 與模式》我看了4 遍，還排除我第一次基本沒看

懂的看！記得研一時老師給我們講了GOF 的那本，作為選修課，我和它們計算機系的碩士、博士們一起，到最后一個班40－50 個人，不

超過3 個人明白，我也沒有明白任何一點（基礎差吧――主要我對C++語言一點都不了解），憑我不伏輸的性格，我認為我對java 語言理

解還可以，我就借了《Java 與模式》，結果還是基本沒看懂。很有幸的是讀研三時，聽過了上交大饒若楠老師關于Java OOP 語言的講座，我懂了組合書籍模式等三種設計模式后，對其它模式有了強烈的興趣和要征服它的愿望！工作后我買的第一本就是《Java 與模式》，第一遍花了2 個月研究了這個1000 多頁的大塊頭，后來第三遍15 天左右就可以搞定，筆記記了一大本！從此一發不可收拾。

選對書、埋頭研究。相信很快就會入門的！

學習Java 語言8 個簡單的部分，這只是我們研究Java 語言的開始！這些都懂了充其量一個java 程序員而已，后面的路很長很長！我們

可以繼續研究數據庫實現的源代碼、Servlet 服務器的源代碼、RMI、EJB、JNDI、面向方面編程、重構、ANT 工具、Eclipse 工具、Spring

工具、JBoss、JOnAS、Apache Geronimo 等J2EE 服務器！研究了這些你可能會成為一個出色的J2EE Architecture！你可以繼續研究剖

析器、編譯器、JNODE（java 寫的操作系統）