java工廠類

① java程序設計中工廠設計模式思想是怎樣的

工廠模式主要用一下幾種形態：
1：簡單工廠（Simple Factory）。
2：工廠方法（Factory Method）。
3：抽象工廠（Abstract Factory）。
簡單工廠並不簡單，它是整個模式的核心，一旦他出了問題，整個模式都將受影響而不能工作，為了降低風險和為日後的維護、擴展做准備，我們需要對它進行重構，引入工廠方法。工廠方法為工廠類定義了介面，用多態來削弱了工廠類的職能。
工廠方法和簡單工廠的主要區別是，簡單工廠是把創建產品的職能都放在一個類裡面，而工廠方法則把不同的產品放在實現了工廠介面的不同工廠類裡面，這樣就算其中一個工廠類出了問題，其他工廠類也能正常工作，互相不受影響，以後增加新產品，也只需要新增一個實現工廠介面工廠類，就能達到，不用修改已有的代碼。但工廠方法也有他局限的地方，那就是當面對的產品有復雜的等級結構的時候
抽象工廠的意圖在於創建一系列互相關聯或互相依賴的對象。

② java工廠類怎麼實現

工廠方法模式分為三種：

1、普通工廠模式，就是建立一個工廠類，對實現了同一介面的一些類進行實例的創建

2、多個工廠方法模式，是對普通工廠方法模式的改進，在普通工廠方法模式中，如果傳遞的字元串出錯，則不能正確創建對象，而多個工廠方法模式是提供多個工廠方法，分別創建對象。

3、靜態工廠方法模式，將上面的多個工廠方法模式里的方法置為靜態的，不需要創建實例，直接調用即可。

具體代碼請參考：java設計模式 第三大節

如果對您有幫助，請及時採納謝謝

③ 誰能介紹一下JAVA平台開發中最長用的幾種設計模式~最好是通俗一些的並且有實例的~500分酬謝

例子很另類，不過還比較好懂

工廠模式， 工廠方法模式，單例模式， 外觀（Facade）模式， 觀察者（Observer）模式，橋接（Bridge）模式都是比較常用的，不同的項目有不同的設計方向，可以參考的設計模式也不盡相同，沒有定數，只是上面這幾個模式用的比較多一些。

其他的模式我找了一下，都列出來了。

======================
Java常用的設計模式
創建型模式

1、FACTORY—追MM少不了請吃飯了，麥當勞的雞翅和肯德基的雞翅都是MM愛吃的東西，雖然口味有所不同，但不管你帶MM去麥當勞或肯德基，只管向服務員說「來四個雞翅」就行了。麥當勞和肯德基就是生產雞翅的Factory

工廠模式：客戶類和工廠類分開。消費者任何時候需要某種產品，只需向工廠請求即可。消費者無須修改就可以接納新產品。缺點是當產品修改時，工廠類也要做相應的修改。如：如何創建及如何向客戶端提供。

2、BUILDER—MM最愛聽的就是「我愛你」這句話了，見到不同地方的MM,要能夠用她們的方言跟她說這句話哦，我有一個多種語言翻譯機，上面每種語言都有一個按鍵，見到MM我只要按對應的鍵，它就能夠用相應的語言說出「我愛你」這句話了，國外的MM也可以輕松搞掂，這就是我的「我愛你」builder。（這一定比美軍在伊拉克用的翻譯機好賣）

建造模式：將產品的內部表象和產品的生成過程分割開來，從而使一個建造過程生成具有不同的內部表象的產品對象。建造模式使得產品內部表象可以獨立的變化，客戶不必知道產品內部組成的細節。建造模式可以強制實行一種分步驟進行的建造過程。

3、FACTORY METHOD—請MM去麥當勞吃漢堡，不同的MM有不同的口味，要每個都記住是一件煩人的事情，我一般採用Factory Method模式，帶著MM到服務員那兒，說「要一個漢堡」，具體要什麼樣的漢堡呢，讓MM直接跟服務員說就行了。

工廠方法模式：核心工廠類不再負責所有產品的創建，而是將具體創建的工作交給子類去做，成為一個抽象工廠角色，僅負責給出具體工廠類必須實現的介面，而不接觸哪一個產品類應當被實例化這種細節。

4、PROTOTYPE—跟MM用QQ聊天，一定要說些深情的話語了，我搜集了好多肉麻的情話，需要時只要出來放到QQ裡面就行了，這就是我的情話prototype了。（100塊錢一份，你要不要）

原始模型模式：通過給出一個原型對象來指明所要創建的對象的類型，然後用復制這個原型對象的方法創建出更多同類型的對象。原始模型模式允許動態的增加或減少產品類，產品類不需要非得有任何事先確定的等級結構，原始模型模式適用於任何的等級結構。缺點是每一個類都必須配備一個克隆方法。

5、SINGLETON—俺有6個漂亮的老婆，她們的老公都是我，我就是我們家裡的老公Sigleton，她們只要說道「老公」，都是指的同一個人，那就是我(剛才做了個夢啦，哪有這么好的事)

單例模式：單例模式確保某一個類只有一個實例，而且自行實例化並向整個系統提供這個實例單例模式。單例模式只應在有真正的「單一實例」的需求時才可使用。

結構型模式

6、ADAPTER—在朋友聚會上碰到了一個美女Sarah，從香港來的，可我不會說粵語，她不會說普通話，只好求助於我的朋友kent了，他作為我和Sarah之間的Adapter，讓我和Sarah可以相互交談了(也不知道他會不會耍我)

適配器（變壓器）模式：把一個類的介面變換成客戶端所期待的另一種介面，從而使原本因介面原因不匹配而無法一起工作的兩個類能夠一起工作。適配類可以根據參數返還一個合適的實例給客戶端。

7、BRIDGE—早上碰到MM，要說早上好，晚上碰到MM，要說晚上好；碰到MM穿了件新衣服，要說你的衣服好漂亮哦，碰到MM新做的發型，要說你的頭發好漂亮哦。不要問我「早上碰到MM新做了個發型怎麼說」這種問題，自己用BRIDGE組合一下不就行了

橋梁模式：將抽象化與實現化脫耦，使得二者可以獨立的變化，也就是說將他們之間的強關聯變成弱關聯，也就是指在一個軟體系統的抽象化和實現化之間使用組合/聚合關系而不是繼承關系，從而使兩者可以獨立的變化。

8、COMPOSITE—Mary今天過生日。「我過生日，你要送我一件禮物。」「嗯，好吧，去商店，你自己挑。」「這件T恤挺漂亮，買，這條裙子好看，買，這個包也不錯，買。」「喂，買了三件了呀，我只答應送一件禮物的哦。」「什麼呀，T恤加裙子加包包，正好配成一套呀，小姐，麻煩你包起來。」「……」，MM都會用Composite模式了，你會了沒有？

合成模式：合成模式將對象組織到樹結構中，可以用來描述整體與部分的關系。合成模式就是一個處理對象的樹結構的模式。合成模式把部分與整體的關系用樹結構表示出來。合成模式使得客戶端把一個個單獨的成分對象和由他們復合而成的合成對象同等看待。

9、DECORATOR—Mary過完輪到Sarly過生日，還是不要叫她自己挑了，不然這個月伙食費肯定玩完，拿出我去年在華山頂上照的照片，在背面寫上「最好的的禮物，就是愛你的Fita」，再到街上禮品店買了個像框（賣禮品的MM也很漂亮哦），再找隔壁搞美術設計的Mike設計了一個漂亮的盒子裝起來……，我們都是Decorator，最終都在修飾我這個人呀，怎麼樣，看懂了嗎？

裝飾模式：裝飾模式以對客戶端透明的方式擴展對象的功能，是繼承關系的一個替代方案，提供比繼承更多的靈活性。動態給一個對象增加功能，這些功能可以再動態的撤消。增加由一些基本功能的排列組合而產生的非常大量的功能。

10、FACADE—我有一個專業的Nikon相機，我就喜歡自己手動調光圈、快門，這樣照出來的照片才專業，但MM可不懂這些，教了半天也不會。幸好相機有Facade設計模式，把相機調整到自動檔，只要對准目標按快門就行了，一切由相機自動調整，這樣MM也可以用這個相機給我拍張照片了。

門面模式：外部與一個子系統的通信必須通過一個統一的門面對象進行。門面模式提供一個高層次的介面，使得子系統更易於使用。每一個子系統只有一個門面類，而且此門面類只有一個實例，也就是說它是一個單例模式。但整個系統可以有多個門面類。

11、FLYWEIGHT—每天跟MM發簡訊，手指都累死了，最近買了個新手機，可以把一些常用的句子存在手機里，要用的時候，直接拿出來，在前面加上MM的名字就可以發送了，再不用一個字一個字敲了。共享的句子就是Flyweight，MM的名字就是提取出來的外部特徵，根據上下文情況使用。

享元模式：FLYWEIGHT在拳擊比賽中指最輕量級。享元模式以共享的方式高效的支持大量的細粒度對象。享元模式能做到共享的關鍵是區分內蘊狀態和外蘊狀態。內蘊狀態存儲在享元內部，不會隨環境的改變而有所不同。外蘊狀態是隨環境的改變而改變的。外蘊狀態不能影響內蘊狀態，它們是相互獨立的。將可以共享的狀態和不可以共享的狀態從常規類中區分開來，將不可以共享的狀態從類里剔除出去。客戶端不可以直接創建被共享的對象，而應當使用一個工廠對象負責創建被共享的對象。享元模式大幅度的降低內存中對象的數量。

12、PROXY—跟MM在網上聊天，一開頭總是「hi,你好」,「你從哪兒來呀？」「你多大了？」「身高多少呀？」這些話，真煩人，寫個程序做為我的Proxy吧，凡是接收到這些話都設置好了自動的回答，接收到其他的話時再通知我回答，怎麼樣，酷吧。

代理模式：代理模式給某一個對象提供一個代理對象，並由代理對象控制對源對象的引用。代理就是一個人或一個機構代表另一個人或者一個機構採取行動。某些情況下，客戶不想或者不能夠直接引用一個對象，代理對象可以在客戶和目標對象直接起到中介的作用。客戶端分辨不出代理主題對象與真實主題對象。代理模式可以並不知道真正的被代理對象，而僅僅持有一個被代理對象的介面，這時候代理對象不能夠創建被代理對象，被代理對象必須有系統的其他角色代為創建並傳入。

行為模式

13、CHAIN OF RESPONSIBLEITY—晚上去上英語課，為了好開溜坐到了最後一排，哇，前面坐了好幾個漂亮的MM哎，找張紙條，寫上「Hi,可以做我的女朋友嗎？如果不願意請向前傳」，紙條就一個接一個的傳上去了，糟糕，傳到第一排的MM把紙條傳給老師了，聽說是個老處女呀，快跑!

責任鏈模式：在責任鏈模式中，很多對象由每一個對象對其下家的引用而接

起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求。客戶並不知道鏈上的哪一個對象最終處理這個請求，系統可以在不影響客戶端的情況下動態的重新組織鏈和分配責任。處理者有兩個選擇：承擔責任或者把責任推給下家。一個請求可以最終不被任何接收端對象所接受。

14、COMMAND—俺有一個MM家裡管得特別嚴，沒法見面，只好藉助於她弟弟在我們倆之間傳送信息，她對我有什麼指示，就寫一張紙條讓她弟弟帶給我。這不，她弟弟又傳送過來一個COMMAND，為了感謝他，我請他吃了碗雜醬面，哪知道他說：「我同時給我姐姐三個男朋友送COMMAND，就數你最小氣，才請我吃面。」，:-(

命令模式：命令模式把一個請求或者操作封裝到一個對象中。命令模式把發出命令的責任和執行命令的責任分割開，委派給不同的對象。命令模式允許請求的一方和發送的一方獨立開來，使得請求的一方不必知道接收請求的一方的介面，更不必知道請求是怎麼被接收，以及操作是否執行，何時被執行以及是怎麼被執行的。系統支持命令的撤消。

15、INTERPRETER—俺有一個《泡MM真經》，上面有各種泡MM的攻略，比如說去吃西餐的步驟、去看電影的方法等等，跟MM約會時，只要做一個Interpreter，照著上面的腳本執行就可以了。

解釋器模式：給定一個語言後，解釋器模式可以定義出其文法的一種表示，並同時提供一個解釋器。客戶端可以使用這個解釋器來解釋這個語言中的句子。解釋器模式將描述怎樣在有了一個簡單的文法後，使用模式設計解釋這些語句。在解釋器模式裡面提到的語言是指任何解釋器對象能夠解釋的任何組合。在解釋器模式中需要定義一個代表文法的命令類的等級結構，也就是一系列的組合規則。每一個命令對象都有一個解釋方法，代表對命令對象的解釋。命令對象的等級結構中的對象的任何排列組合都是一個語言。

16、ITERATOR—我愛上了Mary，不顧一切的向她求婚。

Mary：「想要我跟你結婚，得答應我的條件」

我：「什麼條件我都答應，你說吧」

Mary：「我看上了那個一克拉的鑽石」

我：「我買，我買，還有嗎？」

Mary：「我看上了湖邊的那棟別墅」

我：「我買，我買，還有嗎？」

Mary：「你的小弟弟必須要有50cm長」

我腦袋嗡的一聲，坐在椅子上，一咬牙：「我剪，我剪，還有嗎？」

……

迭代子模式：迭代子模式可以順序訪問一個聚集中的元素而不必暴露聚集的內部表象。多個對象聚在一起形成的總體稱之為聚集，聚集對象是能夠包容一組對象的容器對象。迭代子模式將迭代邏輯封裝到一個獨立的子對象中，從而與聚集本身隔開。迭代子模式簡化了聚集的界面。每一個聚集對象都可以有一個或一個以上的迭代子對象，每一個迭代子的迭代狀態可以是彼此獨立的。迭代演算法可以獨立於聚集角色變化。

17、MEDIATOR—四個MM打麻將，相互之間誰應該給誰多少錢算不清楚了，幸虧當時我在旁邊，按照各自的籌碼數算錢，賺了錢的從我這里拿，賠了錢的也付給我，一切就OK啦，俺得到了四個MM的電話。

調停者模式：調停者模式包裝了一系列對象相互作用的方式，使得這些對象不必相互明顯作用。從而使他們可以鬆散偶合。當某些對象之間的作用發生改變時，不會立即影響其他的一些對象之間的作用。保證這些作用可以彼此獨立的變化。調停者模式將多對多的相互作用轉化為一對多的相互作用。調停者模式將對象的行為和協作抽象化，把對象在小尺度的行為上與其他對象的相互作用分開處理。

18、MEMENTO—同時跟幾個MM聊天時，一定要記清楚剛才跟MM說了些什麼話，不然MM發現了會不高興的哦，幸虧我有個備忘錄，剛才與哪個MM說了什麼話我都拷貝一份放到備忘錄裡面保存，這樣可以隨時察看以前的記錄啦。

備忘錄模式：備忘錄對象是一個用來存儲另外一個對象內部狀態的快照的對象。備忘錄模式的用意是在不破壞封裝的條件下，將一個對象的狀態捉住，並外部化，存儲起來，從而可以在將來合適的時候把這個對象還原到存儲起來的狀態。

19、OBSERVER—想知道咱們公司最新MM情報嗎？加入公司的MM情報郵件組就行了，tom負責搜集情報，他發現的新情報不用一個一個通知我們，直接發布給郵件組，我們作為訂閱者（觀察者）就可以及時收到情報啦

觀察者模式：觀察者模式定義了一種一隊多的依賴關系，讓多個觀察者對象同時監聽某一個主題對象。這個主題對象在狀態上發生變化時，會通知所有觀察者對象，使他們能夠自動更新自己。

20、STATE—跟MM交往時，一定要注意她的狀態哦，在不同的狀態時她的行為會有不同，比如你約她今天晚上去看電影，對你沒興趣的MM就會說「有事情啦」，對你不討厭但還沒喜歡上的MM就會說「好啊，不過可以帶上我同事么？」，已經喜歡上你的MM就會說「幾點鍾？看完電影再去泡吧怎麼樣？」，當然你看電影過程中表現良好的話，也可以把MM的狀態從不討厭不喜歡變成喜歡哦。

狀態模式：狀態模式允許一個對象在其內部狀態改變的時候改變行為。這個對象看上去象是改變了它的類一樣。狀態模式把所研究的對象的行為包裝在不同的狀態對象里，每一個狀態對象都屬於一個抽象狀態類的一個子類。狀態模式的意圖是讓一個對象在其內部狀態改變的時候，其行為也隨之改變。狀態模式需要對每一個系統可能取得的狀態創立一個狀態類的子類。當系統的狀態變化時，系統便改變所選的子類。

21、STRATEGY—跟不同類型的MM約會，要用不同的策略，有的請電影比較好，有的則去吃小吃效果不錯，有的去海邊浪漫最合適，單目的都是為了得到MM的芳心，我的追MM錦囊中有好多Strategy哦。

策略模式：策略模式針對一組演算法，將每一個演算法封裝到具有共同介面的獨立的類中，從而使得它們可以相互替換。策略模式使得演算法可以在不影響到客戶端的情況下發生變化。策略模式把行為和環境分開。環境類負責維持和查詢行為類，各種演算法在具體的策略類中提供。由於演算法和環境獨立開來，演算法的增減，修改都不會影響到環境和客戶端。

22、TEMPLATE METHOD——看過《如何說服女生上床》這部經典文章嗎？女生從認識到上床的不變的步驟分為巧遇、打破僵局、展開追求、接吻、前戲、動手、愛撫、進去八大步驟(Template method)，但每個步驟針對不同的情況，都有不一樣的做法，這就要看你隨機應變啦(具體實現)；

模板方法模式：模板方法模式准備一個抽象類，將部分邏輯以具體方法以及具體構造子的形式實現，然後聲明一些抽象方法來迫使子類實現剩餘的邏輯。不同的子類可以以不同的方式實現這些抽象方法，從而對剩餘的邏輯有不同的實現。先制定一個頂級邏輯框架，而將邏輯的細節留給具體的子類去實現。

23、VISITOR—情人節到了，要給每個MM送一束鮮花和一張卡片，可是每個MM送的花都要針對她個人的特點，每張卡片也要根據個人的特點來挑，我一個人哪搞得清楚，還是找花店老闆和禮品店老闆做一下Visitor，讓花店老闆根據MM的特點選一束花，讓禮品店老闆也根據每個人特點選一張卡，這樣就輕松多了；

訪問者模式：訪問者模式的目的是封裝一些施加於某種數據結構元素之上的操作。一旦這些操作需要修改的話，接受這個操作的數據結構可以保持不變。訪問者模式適用於數據結構相對未定的系統，它把數據結構和作用於結構上的操作之間的耦合解脫開，使得操作集合可以相對自由的演化。訪問者模式使得增加新的操作變的很容易，就是增加一個新的訪問者類。訪問者模式將有關的行為集中到一個訪問者對象中，而不是分散到一個個的節點類中。當使用訪問者模式時，要將盡可能多的對象瀏覽邏輯放在訪問者類中，而不是放到它的子類中。訪問者模式可以跨過幾個類的等級結構訪問屬於不同的等級結構的成員類。

④ java簡單工廠模式是什麼

就是專門寫一個類，他有一個方法根據傳入的參數不同，返回不同的對象。
比如有一台自動售貨機AutoSeller， 然後它賣很多飲料Drink, 有茶Tea， 有可樂Cola, 當你去買的時候，你可能是通過按不同的按鈕，但對AutoSeller的實現來說，他可能都是同樣的方法，只是根據不同的參數（按鈕），返回給你不同的對象（Tea或Cola）。
public interface Drink {
enum Type {TEA, COLA};
}
public Tea implements Drink {
}
public Cola implements Drink {
}
public class AutoSeller {//工廠
public static Drink getDrink(Drink.Type type) {
switch(type) {
case TEA:
return new Tea();
case COLA:
return new Cola();
default:break;
}
}
}

如上， 在你選擇飲料按下按鈕里， 自動售貨機的代碼可能只要執行AutoSeller.getDrink(type)就可以返回你想要的飲料了。
之所以要把Drink定義成介面，一般來講，用這種架構的話， Drink裡面會聲明一些介面方法， 這些方法是Tea和Cola都需要的， 但Drink不用關心方法的具體實現， 具體實現只要由Tea和Cola去完成。
而你通過AutoSeller.getDrink(type)去拿到一個Drink對象後，可以用這個對象直接去調Drink中聲明的方法。

⑤ java中 什麼是工廠

工廠是一種設計模式！
為何使用?
工廠模式是我們最常用的模式了,著名的Jive論壇 ,就大量使用了工廠模式，工廠模式在Java程序系統可以說是隨處可見。

為什麼工廠模式是如此常用？因為工廠模式就相當於創建實例對象的new，我們經常要根據類Class生成實例對象，如A a=new A() 工廠模式也是用來創建實例對象的，所以以後new時就要多個心眼，是否可以考慮實用工廠模式，雖然這樣做，可能多做一些工作，但會給你系統帶來更大的可擴展性和盡量少的修改量。

我們以類Sample為例， 如果我們要創建Sample的實例對象:

Sample sample=new Sample();

可是，實際情況是，通常我們都要在創建sample實例時做點初始化的工作,比如賦值 查詢資料庫等。

首先，我們想到的是，可以使用Sample的構造函數，這樣生成實例就寫成:

Sample sample=new Sample(參數);

但是，如果創建sample實例時所做的初始化工作不是象賦值這樣簡單的事，可能是很長一段代碼，如果也寫入構造函數中，那你的代碼很難看了（就需要Refactor重整）。

為什麼說代碼很難看，初學者可能沒有這種感覺，我們分析如下，初始化工作如果是很長一段代碼，說明要做的工作很多，將很多工作裝入一個方法中，相當於將很多雞蛋放在一個籃子里，是很危險的，這也是有背於Java 面向對象的原則，面向對象的封裝(Encapsulation)和分派(Delegation)告訴我們，盡量將長的代碼分派「切割」成每段，將每段再 「封裝」起來(減少段和段之間偶合聯系性)，這樣，就會將風險分散，以後如果需要修改，只要更改每段，不會再發生牽一動百的事情。

在本例中，首先，我們需要將創建實例的工作與使用實例的工作分開, 也就是說，讓創建實例所需要的大量初始化工作從Sample的構造函數中分離出去。

這時我們就需要Factory工廠模式來生成對象了，不能再用上面簡單new Sample(參數)。還有,如果Sample有個繼承如MySample, 按照面向介面編程,我們需要將Sample抽象成一個介面.現在Sample是介面,有兩個子類MySample 和HisSample .我們要實例化他們時,如下:

Sample mysample=new MySample();
Sample hissample=new HisSample();

隨著項目的深入,Sample可能還會"生出很多兒子出來", 那麼我們要對這些兒子一個個實例化,更糟糕的是,可能還要對以前的代碼進行修改:加入後來生出兒子的實例.這在傳統程序中是無法避免的.

但如果你一開始就有意識使用了工廠模式,這些麻煩就沒有了.

工廠方法
你會建立一個專門生產Sample實例的工廠:

public class Factory{

public static Sample creator(int which){

//getClass 產生Sample 一般可使用動態類裝載裝入類。
if (which==1)
return new SampleA();
else if (which==2)
return new SampleB();

}

}

那麼在你的程序中,如果要實例化Sample時.就使用

Sample sampleA=Factory.creator(1);

這樣,在整個就不涉及到 Sample的具體子類,達到封裝效果,也就減少錯誤修改的機會,這個原理可以用很通俗的話來比喻:就是具體事情做得越多,越容易范錯誤.這每個做過具體工作的人都深有體會,相反,官做得越高,說出的話越抽象越籠統,范錯誤可能性就越少.好象我們從編程序中也能悟出人生道理?呵呵.

使用工廠方法 要注意幾個角色，首先你要定義產品介面，如上面的Sample,產品介面下有Sample介面的實現類,如SampleA,其次要有一個factory類，用來生成產品Sample，如下圖，最右邊是生產的對象Sample：

進一步稍微復雜一點，就是在工廠類上進行拓展，工廠類也有繼承它的實現類concreteFactory了。

抽象工廠
工廠模式中有: 工廠方法(Factory Method) 抽象工廠(Abstract Factory).

這兩個模式區別在於需要創建對象的復雜程度上。如果我們創建對象的方法變得復雜了,如上面工廠方法中是創建一個對象Sample,如果我們還有新的產品介面Sample2.

這里假設：Sample有兩個concrete類SampleA和SamleB，而Sample2也有兩個concrete類Sample2A和SampleB2

那麼，我們就將上例中Factory變成抽象類,將共同部分封裝在抽象類中,不同部分使用子類實現，下面就是將上例中的Factory拓展成抽象工廠:

public abstract class Factory{

public abstract Sample creator();

public abstract Sample2 creator(String name);

}

public class SimpleFactory extends Factory{

public Sample creator(){
.........
return new SampleA
}

public Sample2 creator(String name){
.........
return new Sample2A
}

}

public class BombFactory extends Factory{

public Sample creator(){
......
return new SampleB
}

public Sample2 creator(String name){
......
return new Sample2B
}

}

從上面看到兩個工廠各自生產出一套Sample和Sample2,也許你會疑問，為什麼我不可以使用兩個工廠方法來分別生產Sample和Sample2?

抽象工廠還有另外一個關鍵要點，是因為 SimpleFactory內，生產Sample和生產Sample2的方法之間有一定聯系，所以才要將這兩個方法捆綁在一個類中，這個工廠類有其本身特徵，也許製造過程是統一的，比如：製造工藝比較簡單，所以名稱叫SimpleFactory。

在實際應用中，工廠方法用得比較多一些，而且是和動態類裝入器組合在一起應用。

⑥ 什麼是Java的工廠模式

factory模式不需要建立什麼包，完全得靠你對factory模式的理解，工廠模式基本上應該是體現了一個多態的概念，用戶只關心結果，而不需要關心其具體過程...
工廠模式有三個參與者，抽象產品(Proct)、工廠(Creator)和具體產品(ConcreteProct)。客戶只會看到工廠和抽象產品。

public interface Proct{
public String getName();
}

public class ConcreteProct implements Proct{
public String getName(){
return "產品1";
}
}

public class Creator{
public static Proct create1(){
return new ConcreteProct();
}
}

工廠模式的作用在於將創建具體產品的方法由工廠類控制，客戶只需要知道產品的抽象類型

⑦ 求java工廠模式的一個簡單代碼例子，盡量簡單

這個應該比較簡單一點。

某系統日誌記錄器要求支持多種日誌記錄方式，如文件記錄、資料庫記錄等，且用戶可以根據要求動態選擇日誌記錄方式。現使用工廠方法模式設計該系統,並寫出相應Java代碼。

interface Log{

public void writeLog();

}

class FileLog implements Log{

public void writeLog(){

System.out.println("文件記錄");

}

}

class DatabaseLog implements Log{

public void writeLog(){

System.out.println("資料庫記錄");

}

}

interface LogFactory{

public Log createLog();

}

class FileLogFactory implements LogFactory{

public Log createLog(){

return new FileLog();

}

}

class DatabaseLogFactory implements LogFactory{

public Log createLog(){

return new DatabaseLog();

}

}

public class Client{

public static void main(String[] args) {

try{

Log log;

LogFactory factory;

//這里可以改成使用DOM和Java反射機制讀取XML文件，獲取工廠類名

factory=new DatabaseLogFactory ();

log=factory.createLog();

log.writeLog();

}

catch(Exception e){

System.out.println(e.getMessage());

}

}

}

⑧ 澶у︾敓紱忛煶Java甯歌佽捐℃ā寮忔葷粨

Java甯歌佽捐℃ā寮忓揩鏉ョ湅鐪

1銆佸壋寤哄瀷-宸ュ巶鏂規硶妯″紡:

(1)綆鍗曞伐鍘傛ā寮:

寤虹珛涓涓宸ュ巶綾伙紝騫跺畾涔変竴涓鎺ュ彛瀵瑰疄鐜頒簡鍚屼竴鎺ュ彛鐨勪駭鍝佺被榪涜屽壋寤恆

(2)宸ュ巶鏂規硶妯″紡:

宸ュ巶鏂規硶妯″紡鏄瀵圭畝鍗曞伐鍘傛ā寮忕殑鏀硅繘錛岀畝鍗曞伐鍘傜殑緙洪櫡鍦ㄥ共涓嶇﹀悎鈥滃紑闂鍘熷垯鈥

(3)闈欐佸伐鍘傛柟娉曟ā寮:

闈欐佸伐鍘傛ā寮忔槸灝嗗伐鍘傛柟娉曟ā寮忛噷鐨勬柟娉曠疆涓洪潤鎬佺殑錛屼笉闇瑕佸壋寤哄疄渚嬶紝鐩存帴璋冪敤鍗沖彲銆

2銆佸壋寤哄瀷-鎶借薄宸ュ巶妯″紡:

鎶借薄宸ュ巶妯″紡涓昏佺敤浜庡壋寤虹浉鍏沖硅薄鐨勫舵棌銆傚綋涓涓浜у搧鏃忎腑闇瑕佽璁捐″湪涓璧峰伐浣滄椂錛岄氳繃鎶借薄宸ュ巶妯″紡錛岃兘澶熶繚璇佸㈡埛絝濮嬬粓鍙浣跨敤鍚屼竴涓浜у搧鏃忎腑鐨勫硅薄:騫朵笖閫氳繃闅旂誨叿浣撶被鐨勭敓鎴愶紝浣垮緱瀹㈡埛絝涓嶉渶瑕佹槑紜鎸囧畾鍏蜂綋鐢熸垚綾;鎵鏈夌殑鍏蜂綋宸ュ巶閮藉疄鐜頒簡鎶借薄宸ュ巶涓瀹氫箟鐨勫叕鍏辨帴鍙ｏ紝鍥犳ゅ彧闇瑕佹敼鍙樺叿浣撳伐鍘傜殑瀹炰緥錛屽氨鍙浠ュ湪鏌愮嶇▼搴︿笂鏀瑰彉鏁翠釜杞浠剁郴緇熺殑琛屼負銆

浣嗚ユā寮忕殑緙虹偣鍦ㄤ簬娣誨姞鏂扮殑琛屼負鏃舵瘮杈冮夯鐑︼紝濡傛灉闇瑕佹坊鍔犱竴涓鏂頒駭鍝佹棌瀵硅薄鏃訛紝闇瑕佹洿鏀規帴鍙ｅ強鍏朵笅鎵鏈夊瓙綾伙紝榪欏繀鐒朵細甯︽潵寰堝ぇ鐨勯夯鐑︺

3銆佸壋寤哄瀷-寤洪犺呮ā寮:

寤洪犺呮ā寮忓皢澶嶆潅浜у搧鐨勫壋寤烘ラゅ垎瑙ｅ湪鍦ㄤ笉鍚岀殑鏂規硶涓浣垮緱鍒涘緩榪囩▼鏇村姞娓呮櫚錛屼粠鑰屾洿綺劇『鎺у埗澶嶆潅瀵硅薄鐨勪駭鐢熻繃紼;閫氳繃闅旂誨嶆潅瀵硅薄鐨勬瀯寤轟笌浣跨敤錛屼篃灝辨槸灝嗕駭鍝佺殑鍒涘緩涓庝駭鍝佹湰韜鍒嗙誨紑鏉ワ紝浣垮緱鍚屾牱鐨勬瀯寤鴻繃紼嬪彲浠ュ壋寤轟笉鍚岀殑瀵硅薄;騫朵笖姣忎釜鍏蜂綋寤洪犺呴兘鐩鎬簰鐙絝嬶紝鍥犳ゅ彲浠ュ緢鏂逛究鍦版浛鎹㈠叿浣撳緩閫犺呮垨澧炲姞鏂扮殑鍏蜂綋寤洪犺咃紝鐢ㄦ埛浣跨敤涓嶅悓鐨勫叿浣撳緩閫犺呭嵆鍙寰楀埌涓嶅悓鐨勪駭鍝佸硅薄銆

4銆佸壋寤哄瀷-鍗曚緥妯″紡

鍗曚緥妯″紡鍙浠ョ『淇濈郴緇熶腑鏌愪釜綾誨彧鏈変竴涓瀹炰緥錛岃ョ被鑷琛屽疄渚嬪寲騫跺悜鏁翠釜緋葷粺鎻愪緵榪欎釜瀹炰緥鐨勫叕鍏辮塊棶鐐癸紝闄や簡璇ュ叕鍏辮塊棶鐐癸紝涓嶈兘閫氳繃鍏朵粬閫斿緞璁塊棶璇ュ疄渚嬨傚崟渚嬫ā寮忕殑浼樼偣鍦ㄤ簬:緋葷粺涓鍙瀛樺湪涓涓鍏辯敤鐨勫疄渚嬪硅薄錛屾棤闇棰戠箒鍒涘緩鍜岄攢姣佸硅薄錛岃妭綰︿簡緋葷粺璧勬簮錛屾彁楂樼郴緇熺殑鎬ц兘鍙浠ヤ弗鏍兼帶鍒跺㈡埛鎬庝箞鏍蜂互鍙婁綍鏃惰塊棶鍗曚緥瀵硅薄銆傚崟渚嬫ā寮忕殑鍐欐硶鏈夊ソ鍑犵嶏紝涓昏佹湁涓夌:鎳掓眽寮忓崟渚嬨侀タ奼夊紡鍗曚緥銆佺櫥璁板紡鍗曚緥銆

5銆佸壋寤哄瀷-鍘熷瀷妯″紡:

鍦 Java 涓錛屽師鍨嬫ā寮忕殑鏍稿績鏄灝辨槸鍘熷瀷綾 Prototype,Prototype綾婚渶瑕佸叿澶囦互涓嬩袱涓鏉′歡:瀹炵幇 Cloneable 鎺ュ彛:

閲嶅啓 Object 綾諱腑鐨 clone() 鏂規硶錛岀敤浜庤繑鍥炲硅薄鐨勬嫹璐;Object 綾諱腑鐨 clone() 鏂規硶榛樿ゆ槸嫻呮嫹璐濓紝濡傛灉鎯寵佹繁鎷瘋礉瀵硅薄錛屽垯闇瑕佸湪 clone() 鏂規硶涓鑷瀹氫箟鑷宸辯殑澶嶅埗閫昏緫銆傛祬澶嶅埗:灝嗕竴涓瀵硅薄澶嶅埗鍚庯紝鍩烘湰鏁版嵁綾誨瀷鐨勫彉閲忎細閲嶆柊鍒涘緩錛岃屽紩鐢ㄧ被鍨嬫寚鍚戠殑榪樻槸鍘熷硅薄鎵鎸囧悜鐨勫唴瀛樺湴鍧銆傛繁澶嶅埗:灝嗕竴涓瀵硅薄澶嶅埗鍚庯紝涓嶈烘槸鍩烘湰鏁版嵁綾誨瀷榪樻湁寮曠敤綾誨瀷錛岄兘鏄閲嶆柊鍒涘緩鐨勩

浣跨敤鍘熷瀷妯″紡榪涜屽壋寤哄硅薄涓嶄粎綆鍖栧硅薄鐨勫壋寤烘ラわ紝榪樻瘮new 鏂瑰紡鍒涘緩瀵硅薄鐨勬ц兘瑕佸ソ鐨勫氾紝鍥犱負 Object 綾葷殑clone() 鏂規硶鏄涓涓鏈鍦版柟娉曪紝鐩存帴鎿嶄綔鍐呭瓨涓鐨勪簩榪涘埗嫻佺壒鍒鏄澶嶅埗澶у硅薄鏃訛紝鎬ц兘鐨勫樊鍒闈炲父鏄庢樉

6.緇撴瀯鍨-閫傞厤鍣ㄦā寮

閫傞厤鍣ㄦā寮忎富瑕佺敤浜庡皢涓涓綾繪垨鑰呮帴鍙ｈ漿鍖栨垚瀹㈡埛絝甯屾湜鐨勬牸寮忥紝浣垮緱鍘熸湰涓嶅吋瀹圭殑綾誨彲浠ュ湪涓璧峰伐浣滐紝灝嗙洰鏍囩被鍜岄傞厤鑰呯被瑙ｈ;鍚屾椂涔熺﹀悎鈥滃紑闂鍘熷垯鈥濓紝鍙浠ュ湪涓嶄慨鏀瑰師浠ｇ爜鐨勫熀紜涓婂炲姞鏂扮殑閫傞厤鍣ㄧ被;灝嗗叿浣撶殑瀹炵幇灝佽呭湪閫傞厤鑰呯被涓錛屽逛簬瀹㈡埛絝綾繪潵璇存槸閫忔槑鐨勶紝鑰屼笖鎻愰珮浜嗛傞厤鑰呯殑澶嶇敤鎬э紝浣嗘槸緙虹偣鍦ㄤ簬鏇存崲閫傞厤鍣ㄧ殑瀹炵幇榪囩▼姣旇緝澶嶆潅銆

鎵浠ワ紝閫傞厤鍣ㄦā寮忔瘮杈冮傚悎浠ヤ笅鍦烘櫙:

(1)緋葷粺闇瑕佷嬌鐢ㄧ幇鏈夌殑綾伙紝鑰岃繖浜涚被鐨勬帴鍙ｄ笉絎﹀悎緋葷粺鐨勬帴

(2)浣跨敤絎涓夋柟緇勪歡錛岀粍浠舵帴鍙ｅ畾涔夊拰鑷宸卞畾涔夌殑涓嶅悓錛屼笉甯屾湜淇鏀硅嚜宸辯殑鎺ュ彛錛屼絾鏄瑕佷嬌鐢ㄧ涓夋柟緇勪歡鎺ュ彛鐨勫姛鑳姐

7銆佺粨鏋勫瀷-瑁呴グ鍣ㄦā寮:

瑁呴グ鍣ㄦā寮忓彲浠ュ姩鎬佺粰瀵硅薄娣誨姞涓浜涢濆栫殑鑱岃矗浠庤屽疄鐜板姛鑳界殑鎷撳睍錛屽湪榪愯屾椂閫夋嫨涓嶅悓鐨勮呴グ鍣錛屼粠鑰屽疄鐜頒笉鍚岀殑琛屼負;姣斾嬌鐢ㄧ戶鎵挎洿鍔犵伒媧伙紝閫氳繃瀵逛笉鍚岀殑瑁呴グ綾昏繘琛屾帓鍒楃粍鍚堬紝鍒涢犲嚭寰堝氫笉鍚岃屼負錛屽緱鍒板姛鑳芥洿涓哄己澶х殑瀵硅薄;絎﹀悎鈥滃紑闂鍘熷垯鈥濓紝琚瑁呴グ綾諱笌瑁呴グ綾葷嫭絝嬪彉鍖栵紝鐢ㄦ埛鍙浠ユ牴鎹闇瑕佸炲姞鏂扮殑瑁呴グ綾誨拰琚瑁呴グ綾伙紝鍦ㄤ嬌鐢ㄦ椂鍐嶅瑰叾榪涜岀粍鍚堬紝鍘熸湁浠ｇ爜鏃犻』鏀瑰彉銆

浣嗘槸瑁呴グ鍣ㄦā寮忎篃瀛樺湪緙虹偣錛岄栧厛浼氫駭鐢熷緢澶氱殑灝忓硅薄澧炲姞浜嗙郴緇熺殑澶嶆潅鎬э紝絎浜屾槸鎺掗敊姣旇緝鍥伴毦錛屽逛簬澶氭¤呴グ鐨勫硅薄錛岃皟璇曟椂瀵繪壘閿欒鍙鑳介渶瑕侀愮駭鎺掓煡錛岃緝涓虹儲鐞愩

8銆佺粨鏋勫瀷-浠ｇ悊妯″紡:

浠ｇ悊妯″紡鐨勮捐″姩鏈烘槸閫氳繃浠ｇ悊瀵硅薄鏉ヨ塊棶鐪熷疄瀵硅薄錛岄氳繃寤虹珛涓涓瀵硅薄浠ｇ悊綾伙紝鐢變唬鐞嗗硅薄鎺у埗鍘熷硅薄鐨勫紩鐢錛屼粠鑰屽疄鐜板圭湡瀹炲硅薄鐨勬搷浣溿傚湪浠ｇ悊妯″紡涓錛屼唬鐞嗗硅薄涓昏佽搗鍒頒竴涓涓浠嬬殑浣滅敤錛岀敤浜庡崗璋冧笌榪炴帴璋冪敤鑰(鍗沖㈡埛絝)鍜岃璋冪敤鑰(鍗崇洰鏍囧硅薄)錛屽湪涓瀹氱▼搴︿笂闄嶄綆浜嗙郴緇熺殑鑰﹀悎搴︼紝鍚屾椂涔熶繚鎶や簡鐩鏍囧硅薄銆備絾緙虹偣鏄鍦ㄨ皟鐢ㄨ呬笌琚璋冪敤鑰呬箣闂村炲姞浜嗕唬鐞嗗硅薄錛屽彲鑳戒細閫犳垚璇鋒眰鐨勫勭悊閫熷害鍙樻參銆

9銆佺粨鏋勫瀷-妗ユ帴妯″紡:

妗ユ帴妯″紡灝嗙郴緇熺殑鎶借薄閮ㄥ垎涓庡疄鐜伴儴鍒嗗垎紱昏В鑰︼紝浣誇粬浠鍙浠ョ嫭絝嬬殑鍙樺寲銆備負浜嗚揪鍒拌╂娊璞￠儴鍒嗗拰瀹炵幇閮ㄥ垎鐙絝嬪彉鍖栫殑鐩鐨勶紝妗ユ帴妯″紡浣跨敤緇勫悎鍏崇郴鏉ヤ唬鏇跨戶鎵垮叧緋伙紝鎶借薄閮ㄥ垎鎷ユ湁瀹炵幇閮ㄥ垎鐨勬帴鍙ｅ硅薄錛屼粠鑰岃兘澶熼氳繃榪欎釜鎺ュ彛瀵硅薄鏉ヨ皟鐢ㄥ叿浣撳疄鐜伴儴鍒嗙殑鍔熻兘銆備篃灝辨槸璇達紝妗ユ帴妯″紡涓鐨勬ˉ鎺ユ槸涓涓鍗曟柟鍚戠殑鍏崇郴錛屽彧鑳藉熸娊璞￠儴鍒嗗幓浣跨敤濂栫幇閮ㄥ垎鐨勫硅薄錛岃屼笉鑳藉弽榪囨潵銆

妗ユ帴妯″紡絎﹀悎鈥滃紑闂鍘熷垯鈥濓紝鎻愰珮浜嗙郴緇熺殑鍙鎷撳睍鎬э紝鍦ㄤ袱涓鍙樺寲緇村害涓浠繪剰鎵╁睍涓涓緇村害錛岄兘涓嶉渶瑕佷慨鏀瑰師鏉ョ殑緋葷粺:騫朵笖瀹炵幇緇嗚妭瀵瑰㈡埛涓嶉忔槑錛屽彲浠ラ殣鈃忓疄鐜扮粏鑺傘備絾鏄鐢變簬鑱氬悎鍏崇郴寤虹珛鍦ㄦ娊璞″眰錛岃佹眰寮鍙戣呴拡瀵規娊璞¤繘琛岀紪紼嬶紝榪欏炲姞緋葷粺鐨勭悊瑙ｅ拰璁捐￠毦搴︺

10銆佺粨鏋勫瀷-澶栬傛ā寮:

瑙傛ā寮忛氳繃瀵瑰㈡埛絝鎻愪緵涓涓緇熶竴鐨勬帴鍙ｏ紝鐢ㄤ簬璁塊棶瀛愮郴緇熶腑鐨勪竴緹ゆ帴鍙ｃ備嬌鐢ㄥ栬傛ā寮忔湁浠ヤ笅鍑犵偣濂藉:

(1)鏇村姞鏄撶敤:浣垮緱瀛愮郴緇熸洿鍔犳槗鐢錛屽㈡埛絝涓嶅啀闇瑕佷簡瑙ｅ瓙緋葷粺鍐呴儴鐨勫疄鐜幫紝涔熶笉闇瑕佽窡浼楀氬瓙緋葷粺鍐呴儴鐨勬ā鍧楄繘琛屼氦浜掞紝鍙闇瑕佽窡澶栬傜被浜や簰灝卞彲浠ヤ簡;

(2)鏉炬暎鑰﹀悎:灝嗗㈡埛絝涓庡瓙緋葷粺瑙ｈ︼紝璁╁瓙緋葷粺鍐呴儴鐨勬ā鍧楄兘鏇村規槗鎵╁睍鍜岀淮鎶ゃ

(3)鏇村ソ鐨勫垝鍒嗚塊棶灞傛: 閫氳繃鍚堢悊浣跨敤 Facade錛屽彲浠ユ洿濂藉湴鍒掑垎璁塊棶鐨勫眰嬈★紝鏈変簺鏂規硶鏄瀵圭郴緇熷栫殑錛屾湁浜涙柟娉曟槸緋葷粺鍐呴儴浣跨敤鐨勩傛妸闇瑕佹毚闇茬粰澶栭儴鐨勫姛鑳介泦涓鍒伴棬闈涓錛岃繖鏍鋒棦鏂逛究瀹㈡埛絝浣跨敤錛屼篃寰堝ソ鍦伴殣鈃忎簡鍐呴儴鐨勭粏鑺傘

11銆佺粨鏋勫瀷-緇勫悎妯″紡:

緇勫悎妯″紡灝嗗彾瀛愬硅薄鍜屽瑰櫒瀵硅薄榪涜岄掑綊緇勫悎錛屽艦鎴愭爲褰㈢粨鏋勪互琛ㄧず鈥滈儴鍒-鏁翠綋鈥濈殑灞傛＄粨鏋勶紝浣垮緱鐢ㄦ埛瀵瑰崟涓瀵硅薄鍜岀粍鍚堝硅薄鐨勪嬌鐢ㄥ叿鏈変竴鑷存э紝鑳藉熷儚澶勭悊鍙跺瓙瀵硅薄涓鏍鋒潵澶勭悊緇勫悎瀵硅薄錛屾棤闇榪涜屽尯鍒嗭紝浠庤屼嬌鐢ㄦ埛紼嬪簭鑳藉熶笌澶嶆潅鍏冪礌鐨勫唴閮ㄧ粨鏋勮繘琛岃В鑰︺

緇勫悎妯″紡鏈鍏抽敭鐨勫湴鏂規槸鍙跺瓙瀵硅薄鍜岀粍鍚堝硅薄瀹炵幇浜嗙浉鍚岀殑鎶借薄鏋勫緩綾伙紝瀹冩棦鍙琛ㄧず鍙跺瓙瀵硅薄錛屼篃鍙琛ㄧず瀹瑰櫒瀵硅薄錛屽㈡埛浠呬粎闇瑕侀拡瀵硅繖涓鎶借薄鏋勫緩綾昏繘琛岀紪紼嬶紝榪欏氨鏄緇勫悎妯″紡鑳藉熷皢鍙跺瓙鑺傜偣鍜屽硅薄鑺傜偣榪涜屼竴鑷村勭悊鐨勫師鍥犮

12銆佺粨鏋勫瀷-浜鍏冩ā寮:

浜鍏冩ā寮忛氳繃鍏變韓鎶鏈鏈夋晥鍦版敮鎸佺粏綺掑害銆佺姸鎬佸彉鍖栧皬鐨勫硅薄澶嶇敤錛屽綋緋葷粺涓瀛樺湪鏈夊氫釜鐩稿悓鐨勫硅薄錛岄偅涔堝彧鍏變韓涓浠戒笉蹇呮瘡涓閮藉幓瀹炰緥鍖栦竴涓瀵硅薄錛屾瀬澶у湴鍑忓皯緋葷粺涓瀵硅薄鐨勬暟閲忥紝浠庤岃妭鐪佽祫婧愩

浜鍏冩ā寮忕殑鏍稿績鏄浜鍏冨伐鍘傜被錛屼韓鍏冨伐鍘傜被緇存姢浜嗕竴涓瀵硅薄瀛樺偍奼狅紝褰撳㈡埛絝闇瑕佸硅薄鏃訛紝棣栧厛浠庝韓鍏冩睜涓鑾峰彇錛屽傛灉浜鍏冩睜涓瀛樺湪瀵硅薄瀹炰緥鍒欑洿鎺ヨ繑鍥烇紝濡傛灉浜鍏冩睜涓涓嶅瓨鍦錛屽垯鍒涘緩涓涓鏂扮殑浜鍏冨硅薄瀹炰緥榪斿洖緇欑敤鎴鳳紝騫跺湪浜鍏冩睜涓淇濆瓨璇ユ柊澧炲硅薄錛岃繖鐐規湁浜涘崟渚嬬殑鎰忔濄

宸ュ巶綾婚氬父浼氫嬌鐢ㄩ泦鍚堢被鍨嬫潵淇濆瓨瀵硅薄錛屽 HashMap銆丠ashtable銆乂ector 絳夌瓑錛屽湪 Java 涓錛屾暟鎹搴撹繛鎺ユ睜銆佺嚎紼嬫睜絳夐兘鏄鐢ㄤ韓鍏冩ā寮忕殑搴旂敤銆