java工廠方法

『壹』 java中常用的設計模式有哪些請詳細說明一下工廠模式。

1.單例模式（有的書上說叫單態模式其實都一樣）
該模式主要目的是使內存中保持1個對象
2.工廠模式
該模式主要功能是統一提供實例對象的引用。看下面的例子：
public class Factory{
public ClassesDao getClassesDao(){
ClassesDao cd = new ClassesDaoImpl();
return cd;
}
}
interface ClassesDao{
public String getClassesName();
}
class ClassesDaoImpl implements ClassesDao {
public String getClassesName(){
System.out.println("A班");
}
}
class test
{
public static void main(String[] args){
Factory f = new Factory();
f.getClassesDao().getClassesName();
}
}
這個是最簡單的例子了，就是通過工廠方法通過介面獲取對象的引用
3.建造模式
該模式其實就是說，一個對象的組成可能有很多其他的對象一起組成的，比如說，一個對象的實現非常復雜，有很多的屬性，而這些屬性又是其他對象的引用，可能這些對象的引用又包括很多的對象引用。封裝這些復雜性，就可以使用建造模式。
4.門面模式
這個模式個人感覺像是Service層的一個翻版。比如Dao我們定義了很多持久化方法，我們通過Service層將Dao的原子方法組成業務邏輯，再通過方法向上層提供服務。門面模式道理其實是一樣的。
5.策略模式
這個模式是將行為的抽象，即當有幾個類有相似的方法，將其中通用的部分都提取出來，從而使擴展更容易。

『貳』 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的BorderFactory類定義的工廠方法有哪些

static Border createBevelBorder(int type)
創建一個指定類型的斜面邊框，將組件當前背景色的較亮的色度用於高亮顯示，較暗的色度用於陰影。
static Border createBevelBorder(int type,
Color highlight, Color shadow)
使用指定高亮顯示和陰影顯示方式來創建一個指定類型的斜面邊框。
static Border createBevelBorder(int type,
Color highlightOuter, Color highlightInner,
Color shadowOuter,
Color shadowInner)
創建一個指定類型的斜面邊框，使用內部和外部高亮顯示區域及陰影區域的指定顏色。
static CompoundBorder createCompoundBorder()
創建一個具有 null 內部邊緣和 null 外部邊緣的合成邊框。
static CompoundBorder createCompoundBorder(Border outsideBorder, Border insideBorder)
創建一個合成邊框，指定了用於外部和內部邊緣的 border 對象。
static Border createEmptyBorder()
創建一個不佔用空間的空邊框。
static Border createEmptyBorder(int top,
int left, int bottom, int right)
創建一個佔用空間但沒有繪制的空邊框，指定了頂線、底線、左邊框線和右邊框線的寬度。
static Border createEtchedBorder()
創建一個具有「浮雕化」外觀效果的邊框，將組件的當前背景色用於高亮顯示和陰影顯示。
static Border createEtchedBorder(Color highlight, Color shadow)
使用指定的高亮顯示顏色和陰影顏色創建一個具有「浮雕化」外觀效果的邊框。
static Border createEtchedBorder(int type)
創建一個具有「浮雕化」外觀效果的邊框，將組件的當前背景色用於高亮顯示和陰影顯示。
static Border createEtchedBorder(int type,
Color highlight, Color shadow)
使用指定的高亮顯示顏色和陰影顏色創建一個具有「浮雕化」外觀效果的邊框。
static Border createLineBorder(Color color)
創建一個具有指定顏色的線邊框。
static Border createLineBorder(Color color,
int thickness)
創建一個具有指定顏色和寬度的線邊框。
static Border createLoweredBevelBorder()
創建一個具有凹入斜面邊緣的邊框，將組件當前背景色的較亮的色度用於高亮顯示，較暗的色度用於陰影。
static MatteBorder createMatteBorder(int top,
int left, int bottom, int right, Color color)
使用純色創建一個類似襯邊的邊框。
static MatteBorder createMatteBorder(int top,
int left, int bottom, int right, Icon tileIcon)
創建一個由多層指定圖標組成的、類似襯邊的邊框。
static Border createRaisedBevelBorder()
創建一個具有凸出斜面邊緣的邊框，將組件當前背景色的較亮的色度用於高亮顯示，較暗的色度用於陰影。
static TitledBorder createTitledBorder(Border border)
創建一個空標題的新標題邊框，使其具有指定的邊框對象、默認的文本位置（位於頂線上）、默認的調整
(leading)，以及默認的字體和文本顏色（由當前外觀確定）。
static TitledBorder createTitledBorder(Border border, String title)
向現有邊框添加一個標題，使其具有默認的位置（位於頂線上）、默認的調整
(leading)，以及默認的字體和文本顏色（由當前外觀確定）。
static TitledBorder createTitledBorder(Border border, String title,
int titleJustification, int titlePosition)
向現有邊框添加一個標題，使其具有指定的位置和默認字體和文本顏色（由當前外觀確定）。
static TitledBorder createTitledBorder(Border border, String title,
int titleJustification, int titlePosition, Font titleFont)
向現有邊框添加一個標題，使其具有指定的位置和默認的文本顏色（由當前外觀確定）。
static TitledBorder createTitledBorder(Border border, String title,
int titleJustification, int titlePosition, Font titleFont, Color titleColor)
向現有邊框添加一個標題，使其具有指定的位置、字體和顏色。
static TitledBorder createTitledBorder(String title)
創建一個新標題邊框，使其具有指定的標題、默認的邊框類型（由當前外觀確定）、默認的文本位置（位於頂線上）、默認的調整
(leading)，以及默認的字體和文本顏色（由當前外觀確定）。

『肆』 java 抽象工廠和工廠方法模式的區別

工廠方法模式：一個抽象產品類，可以派生出多個具體產品類。
一個抽象工廠類，可以派生出多個具體工廠類。
每個具體工廠類只能創建一個具體產品類的實例。
抽象工廠模式：多個抽象產品類，每個抽象產品類可以派生出多個具體產品類。
一個抽象工廠類，可以派生出多個具體工廠類。
每個具體工廠類可以創建多個具體產品類的實例。

『伍』 Java程序設計中工廠設計模式思想是怎樣的

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

『陸』 java 設計模式（工廠方法）

面向抽象（抽象類或介面）編程。
IWorkFactory studentWorkFactory = new StudentWorkFactory(); 注意：類型是介面類型，即抽象工廠，抽象工廠生產的是抽象產品，而new的則是具體工廠，是由子類實現的，具體工廠生產具體產品。面向抽象的好處：1.在設計抽象的時候不用管具體的實現，只要定義介面知道它用來干什麼就行，這樣，我只需要知道抽象介面就能繼續下面的開發設計工作了，而不用事先設計具體的實現內容；2. 可以擴展多個子類實現抽象介面，更利於系統後期的擴展，而對原系統不造成任何影響，即：開-閉原則。

TeacherWork tt = new TeacherWork(); 不用說就是面向具體實現類編程，缺點就是擴展性不好，對系統後期維護擴展影響較大。

舉個簡單的例子：
假如在系統的A.java中代碼中使用了TeacherWork 類型對象，是滿足了目前軟體的需求，但是，如果有一天需求變化了需要一個StudentWork 類型對象，該怎麼辦？只能修改A.java類來滿足這樣的修改需求。這樣就影響了原來系統結構穩定性，需要重新調試和測試，而這帶來的維護成本是非常大的，有時可能還會帶來系統錯誤，而影響系統運行。
如果在A.java類中應用Work介面類型就不會存在這種問題，A.java不需要任何修改，只需要修改注入到A中的Work介面的具體實現類即可。

面向抽象編程的好處就在於對系統維護和擴展上，即在不影響原系統穩定運行的基礎上增加新的擴展行為，即要符合「開-閉」原則。可能會因此而失去一定的效率問題，但是對於後期的維護成本來說，這個可以忽略不計。 推薦你一本好書：《軟體秘笈-設計模式那點事》其中講解的設計模式很到位，還有每個模式的靜態類圖和JDK中設計模式的具體分析講解，讀了收獲一定很大。祝你成功！

『柒』 什麼是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工廠模式可分為三種：
1.靜態工廠模式
2.工廠方法模式
3.抽象工廠模式
一、靜態工廠模式：用靜態的方法實現，其創建的對象具有一定的特性
舉例如下：
Vehicle類：
public abstract class Vehicle
{
private String name;

public Vehicle (){
super();
}
public Vehicle (String name){
super();
this.name=name;
}
public abstract void run();
public String getName(){
return name;
}
public void setName(String name){
this.name=name;
}
}

Bus類：
public class Bus extends Vehicle
{
private String name;

public Bus(){}
public Bus(String name){
super(name);
}
@Override
public abstract void run(){
System.out.println("Bus is running");
}
}

Car類：
public class Car extends Vehicle
{
private String name;

public Car(){}
public Car(String name){
super(name);
}
@Override
public abstract void run(){
System.out.println("Car is running");
}
}

靜態工廠類：
（靜態工廠創建一個對象，
靜態工廠創建的對象一般都有一個共同的特性，
繼承自某一個類，
或者引用一個介面）

public class StaticFactory{
public static Object getInstance(String className){
Object instance=null;
try{
Class c=Class.forName(className);
instance=c.newInstance();
}catch(Exception e){}
return instance;
}

public static Object getInstance(String className,Object ...args){
Class c=null;
try{
c=Class.forName(className);
}catch(Exception e){}
Constructor[] cons=c.getConstructors();
Object instance=null;
for(Constructor con:cons){
Class<?>[] cs=con.getParmeterTypes();
if(cs.length>0){
boolean isConstructor=true;
for(int i=0;i<cs.length;i++){
Class t=cs[i];
if(!t.isInstance(args[i])){
isConstructor=false;
}
}
if(isConstructor){
try{
instance=con.newInstance(args);
break;
}catch(Exception e){}
}else{
continue;
}
}
}
return instance;
}
}

二、工廠方法模式：主要是對各類東西分類生產，但分類生產的對象仍然具有某一特性。
如果說靜態工廠是一個綜合的交通工具建造工廠，
那麼工廠方法模式就是具體分工，分成Bus與Car的工廠，
各自生產各自的產品，但是造出來的還是交通工具。

交通工具製造介面：
public interface VehicleMake{
/**製造交通工具**/
public Vehicle make();
}

Bus製造類：
public class BusMake implements VehicleMake{
@Override
public Vehicle make(){
Vehicle bus=new Bus();
System.out.println("Bus工廠製造了一輛Bus");
return bus;
}
}

Car製造類：
public class CarMake implements VehicleMake{
@Override
public Vehicle make(){
Vehicle car=new Car();
System.out.println("Car工廠製造了一輛Car");
return car;
}
}

三、抽象工廠模式：抽象工廠生產的對象可能是沒有共同特性的。比如，一個製造工廠BusMake不僅能製造Bus還能生產輪胎wheel等配件，Bus是交通工具，wheel是配件（代碼中有部分類沒具體寫出來只給了類名）

總工廠（抽象工廠總介面）：
public interface WheelVehicleMake extends VehicleMake{
/**製造輪胎**/
public Wheel makeWheel();
}

輪子BusMake：
public class WheelBusMake implements WheelVehicleMake{
@Override
public Vehicle make(){
Vehicle bus=new Bus();
System.out.println("WheelBusMake生產了一輛Bus");
return bus;
}
@Override
public Wheel makeWheel(){
Wheel busWheel=new BusWheel();
System.out.println("WheelBusMake生產了一個Bus輪子");
return busWheel;
}
}

輪子CarMake：
public class WheelCarMake implements WheelVehicleMake{
@Override
public Vehicle make(){
Vehicle car=new Car();
System.out.println("WheelCarMake生產了一輛Car");
return car;
}
@Override
public Wheel makeWheel(){
Wheel carWheel=new CarWheel();
System.out.println("WheelCarMake生產了一個Car輪子");
return carWheel;
}
}

『玖』 java中 工廠方法的使用意圖是什麼

lass和interface是Java語言中對於抽象類定義進行支持的兩種機制，正是由於這兩種機制的存在，才賦予了Java強大的面向對象能力。abstract class和interface之間在對於抽象類定義的支持方面具有很大的相似性，甚至可以相互替換，因此很多開發者在進行抽象類定義時對於abstract class和interface的選擇顯得比較隨意。
其實，兩者之間還是有很大的區別的，對於它們的選擇甚至反映出對於問題領域本質的理解、對於設計意圖的理解是否正確、合理。本文將對它們之間的區別進行一番剖析，試圖給開發者提供一個在二者之間進行選擇的依據。
一、理解抽象類
abstract class和interface在Java語言中都是用來進行抽象類（本文中的抽象類並非從abstract class翻譯而來，它表示的是一個抽象體，而abstract class為Java語言中用於定義抽象類的一種方法，請讀者注意區分）定義的，那麼什麼是抽象類，使用抽象類能為我們帶來什麼好處呢？
在面向對象的概念中，我們知道所有的對象都是通過類來描繪的，但是反過來卻不是這樣。並不是所有的類都是用來描繪對象的，如果一個類中沒有包含足夠的信息來描繪一個具體的對象，這樣的類就是抽象類。抽象類往往用來表徵我們在對問題領域進行分析、設計中得出的抽象概念，是對一系列看上去不同，但是本質上相同的具體概念的抽象。
比如：如果我們進行一個圖形編輯軟體的開發，就會發現問題領域存在著圓、三角形這樣一些具體概念，它們是不同的，但是它們又都屬於形狀這樣一個概念，形狀這個概念在問題領域是不存在的，它就是一個抽象概念。正是因為抽象的概念在問題領域沒有對應的具體概念，所以用以表徵抽象概念的抽象類是不能夠實例化的。
在面向對象領域，抽象類主要用來進行類型隱藏。我們可以構造出一個固定的一組行為的抽象描述，但是這組行為卻能夠有任意個可能的具體實現方式。這個抽象描述就是抽象類，而這一組任意個可能的具體實現則表現為所有可能的派生類。模塊可以操作一個抽象體。由於模塊依賴於一個固定的抽象體，因此它可以是不允許修改的；同時，通過從這個抽象體派生，也可擴展此模塊的行為功能。熟悉OCP的讀者一定知道，為了能夠實現面向對象設計的一個最核心的原則OCP(Open-Closed Principle)，抽象類是其中的關鍵所在。
二、從語法定義層面看abstract class和interface
在語法層面，Java語言對於abstract class和interface給出了不同的定義方式，下面以定義一個名為Demo的抽象類為例來說明這種不同。使用abstract class的方式定義Demo抽象類的方式如下：

abstract class Demo ｛
abstract void method1();
abstract void method2();
…
｝

使用interface的方式定義Demo抽象類的方式如下：

interface Demo {
void method1();
void method2();
…
}

在abstract class方式中，Demo可以有自己的數據成員，也可以有非abstarct的成員方法，而在interface方式的實現中，Demo只能夠有靜態的不能被修改的數據成員（也就是必須是static final的，不過在interface中一般不定義數據成員），所有的成員方法都是abstract的。從某種意義上說，interface是一種特殊形式的abstract class。
從編程的角度來看，abstract class和interface都可以用來實現"design by contract"的思想。但是在具體的使用上面還是有一些區別的。
首先，abstract class在Java語言中表示的是一種繼承關系，一個類只能使用一次繼承關系。但是，一個類卻可以實現多個interface。也許，這是Java語言的設計者在考慮Java對於多重繼承的支持方面的一種折中考慮吧。
其次，在abstract class的定義中，我們可以賦予方法的默認行為。但是在interface的定義中，方法卻不能擁有默認行為，為了繞過這個限制，必須使用委託，但是這會 增加一些復雜性，有時會造成很大的麻煩。
在抽象類中不能定義默認行為還存在另一個比較嚴重的問題，那就是可能會造成維護上的麻煩。因為如果後來想修改類的界面（一般通過abstract class或者interface來表示）以適應新的情況（比如，添加新的方法或者給已用的方法中添加新的參數）時，就會非常的麻煩，可能要花費很多的時間（對於派生類很多的情況，尤為如此）。但是如果界面是通過abstract class來實現的，那麼可能就只需要修改定義在abstract class中的默認行為就可以了。
同樣，如果不能在抽象類中定義默認行為，就會導致同樣的方法實現出現在該抽象類的每一個派生類中，違反了"one rule，one place"原則，造成代碼重復，同樣不利於以後的維護。因此，在abstract class和interface間進行選擇時要非常的小心。
三、從設計理念層面看abstract class和interface
上面主要從語法定義和編程的角度論述了abstract class和interface的區別，這些層面的區別是比較低層次的、非本質的。本文將從另一個層面：abstract class和interface所反映出的設計理念，來分析一下二者的區別。作者認為，從這個層面進行分析才能理解二者概念的本質所在。
前面已經提到過，abstarct class在Java語言中體現了一種繼承關系，要想使得繼承關系合理，父類和派生類之間必須存在"is a"關系，即父類和派生類在概念本質上應該是相同的。對於interface 來說則不然，並不要求interface的實現者和interface定義在概念本質上是一致的，僅僅是實現了interface定義的契約而已。為了使論述便於理解，下面將通過一個簡單的實例進行說明。
考慮這樣一個例子，假設在我們的問題領域中有一個關於Door的抽象概念，該Door具有執行兩個動作open和close，此時我們可以通過abstract class或者interface來定義一個表示該抽象概念的類型，定義方式分別如下所示：

使用abstract class方式定義Door：

abstract class Door {
abstract void open();
abstract void close()；
}

使用interface方式定義Door：

interface Door {
void open();
void close();
}

其他具體的Door類型可以extends使用abstract class方式定義的Door或者implements使用interface方式定義的Door。看起來好像使用abstract class和interface沒有大的區別。
如果現在要求Door還要具有報警的功能。我們該如何設計針對該例子的類結構呢（在本例中，主要是為了展示abstract class和interface反映在設計理念上的區別，其他方面無關的問題都做了簡化或者忽略）下面將羅列出可能的解決方案，並從設計理念層面對這些不同的方案進行分析。
解決方案一：
簡單的在Door的定義中增加一個alarm方法，如下：

abstract class Door {
abstract void open();
abstract void close()；
abstract void alarm();
}

或者

interface Door {
void open();
void close();
void alarm();
}

那麼具有報警功能的AlarmDoor的定義方式如下：

class AlarmDoor extends Door {
void open()
void close()
void alarm()
}

或者

class AlarmDoor implements Door ｛
void open()
void close()
void alarm()
｝

這種方法違反了面向對象設計中的一個核心原則ISP（Interface Segregation Priciple），在Door的定義中把Door概念本身固有的行為方法和另外一個概念"報警器"的行為方法混在了一起。這樣引起的一個問題是那些僅僅依賴於Door這個概念的模塊會因為"報警器"這個概念的改變（比如：修改alarm方法的參數）而改變，反之依然。
解決方案二：
既然open、close和alarm屬於兩個不同的概念，根據ISP原則應該把它們分別定義在代表這兩個概念的抽象類中。定義方式有：這兩個概念都使用abstract class方式定義；兩個概念都使用interface方式定義；一個概念使用abstract class方式定義，另一個概念使用interface方式定義。
顯然，由於Java語言不支持多重繼承，所以兩個概念都使用abstract class方式定義是不可行的。後面兩種方式都是可行的，但是對於它們的選擇卻反映出對於問題領域中的概念本質的理解、對於設計意圖的反映是否正確、合理。我們一一來分析、說明。
如果兩個概念都使用interface方式來定義，那麼就反映出兩個問題：
1、我們可能沒有理解清楚問題領域，AlarmDoor在概念本質上到底是Door還是報警器？
2、如果我們對於問題領域的理解沒有問題，比如：我們通過對於問題領域的分析發現AlarmDoor在概念本質上和Door是一致的，那麼我們在實現時就沒有能夠正確的揭示我們的設計意圖，因為在這兩個概念的定義上（均使用interface方式定義）反映不出上述含義。
如果我們對於問題領域的理解是：AlarmDoor在概念本質上是Door，同時它有具有報警的功能。我們該如何來設計、實現來明確的反映出我們的意思呢？前面已經說過，abstract class在Java語言中表示一種繼承關系，而繼承關系在本質上是"is a"關系。所以對於Door這個概念，我們應該使用abstarct class方式來定義。另外，AlarmDoor又具有報警功能，說明它又能夠完成報警概念中定義的行為，所以報警概念可以通過interface方式定義。如下所示：

abstract class Door {
abstract void open();
abstract void close()；
}
interface Alarm {
void alarm();
}
class AlarmDoor extends Door implements Alarm {
void open()
void close()
void alarm()
}

這種實現方式基本上能夠明確的反映出我們對於問題領域的理解，正確的揭示我們的設計意圖。其實abstract class表示的是"is a"關系，interface表示的是"like a"關系，大家在選擇時可以作為一個依據，當然這是建立在對問題領域的理解上的，比如：如果我們認為AlarmDoor在概念本質上是報警器，同時又具有Door的功能，那麼上述的定義方式就要反過來了。
abstract class和interface是Java語言中的兩種定義抽象類的方式，它們之間有很大的相似性。但是對於它們的選擇卻又往往反映出對於問題領域中的概念本質的理解、對於設計意圖的反映是否正確、合理，因為它們表現了概念間的不同的關系（雖然都能夠實現需求的功能）。這其實也是語言的一種的慣用法，希望讀者朋友能夠細細體會