【正文】 ? 工廠方法模式包含四個角色：抽象產(chǎn)品是定義產(chǎn)品的接口，是工廠方法模式所創(chuàng)建對象的超類型，即產(chǎn)品對象的共同父類或接口；具體產(chǎn)品實(shí)現(xiàn)了抽象產(chǎn)品接口，某種類型的具體產(chǎn)品由專門的具體工廠創(chuàng)建，它們之間往往一一對應(yīng)；抽象工廠中聲明了工廠方法，用于返回一個產(chǎn)品，它是工廠方法模式的核心，任何在模式中創(chuàng)建對象的工廠類都必須實(shí)現(xiàn)該接口；具體工廠是抽象工廠類的子類，實(shí)現(xiàn)了抽象工廠中定義的工廠方法，并可由客戶調(diào)用，返回一個具體產(chǎn)品類的實(shí)例。 //使用連接創(chuàng)建一個需要發(fā)送的消息類型的實(shí)例 QueueSender qSend=(q)。FileL og Fac tory+ createLog ()...: LogLogFactory+ createLog ()...: LogFileL og+ writeL og ()...: voidLog+ writeL og ()...: voidData ba seL og Fac tory+ createLog ()...: Log......r e t u r n n e w D a t a b a s e L o g ( ) 。 //獲取包含類名的文本節(jié)點(diǎn) NodeList nl = (className)。 } } 具體工廠類 工廠方法模式 ? 模式分析 ? 客戶類代碼片段： ? 為了提高系統(tǒng)的可擴(kuò)展性和靈活性， 在定義工廠和產(chǎn)品時都必須使用抽象層 ，如果需要更換產(chǎn)品類，只需要更換對應(yīng)的工廠即可，其他代碼不需要進(jìn)行任何修改。 工廠方法模式 ?模式動機(jī) ? 考慮這樣一個系統(tǒng)，按鈕工廠類可以返回一個具體的按鈕實(shí)例，如圓形按鈕、矩形按鈕、菱形按鈕等。 在工廠方法模式中，核心的工廠類不再負(fù)責(zé)所有產(chǎn)品的創(chuàng)建，而是將具體創(chuàng)建工作交給子類去做。 //創(chuàng)建一個字符串類型的對象 Class c = (“String”)。 //getBean()的返回類型為 Object，此處需要進(jìn)行強(qiáng)制類型轉(zhuǎn)換 payMethod =()。 工廠方法模式 ? 模式適用環(huán)境 ? 在以下情況下可以使用工廠方法模式： ? 一個類不知道它所需要的對象的類 ：在工廠方法模式中，客戶端不需要知道具體產(chǎn)品類的類名，只需要知道所對應(yīng)的工廠即可，具體的產(chǎn)品對象由具體工廠類創(chuàng)建；客戶端需要知道創(chuàng)建具體產(chǎn)品的工廠類。 ? 產(chǎn)品對象的重復(fù)使用 ：工廠對象將已經(jīng)創(chuàng)建過的產(chǎn)品保存到一個集合（如數(shù)組、 List等）中，然后根據(jù)客戶對產(chǎn)品的請求，對集合進(jìn)行查詢。 END Thanks! 。 ResultSet rs=(select * from UserInfo)。 工廠方法模式 ?模式優(yōu)缺點(diǎn) ?工廠方法模式的缺點(diǎn) ? 在添加新產(chǎn)品時， 需要編寫新的具體產(chǎn)品類，而且還要提供與之對應(yīng)的具體工廠類，系統(tǒng)中類的個數(shù)將成對增加，在一定程度上增加了系統(tǒng)的復(fù)雜度 ，有更多的類需要編譯和運(yùn)行，會給系統(tǒng)帶來一些額外的開銷。 AbstractPay payMethod。 ?xml version=? config classNameCashPayFactory/className /config 工廠方法模式 ? 模式分析 ? Java反射 (Java Reflection)： ? 是指 在程序運(yùn)行時獲取已知名稱的類或已有對象的相關(guān)信息的一種機(jī)制 ，包括類的方法、屬性、超類等信息，還包括實(shí)例的創(chuàng)建和實(shí)例類型的判斷等。 cr e a t e ConcreteProd uctProductConcreteF actory+ factoryMethod ()...: Pr