php抽象工廠
A. php新手學習路線是怎樣的
第一階段：基礎階段（基礎PHP程序員）
重點：把LNMP搞熟練（核心是安裝配置基本操作） 目標：能夠完成基本的LNMP系統安裝，簡單配置維護；能夠做基本的簡單系統的PHP開發；能夠在PHP中型系統中支持某個PHP功能模塊的開發。
時間：完成本階段的時間因人而異，有的成長快半年一年就過了，成長慢的兩三年也有。
Linux
基本命令、操作、啟動、基本服務配置（包括rpm安裝文件，各種服務配置等）；會寫簡單的shell腳本和awk/sed 腳本命令等。
Nginx
做到能夠安裝配置nginx+php，知道基本的nginx核心配置選項，知道 server/fastcgi_pass/access_log 等基礎配置，目標是能夠讓nginx+php_fpm順利工作。
Mysql
會自己搭建mysql，知道基本的mysql配置選項；知道innodb和myisam的區別，知道針對InnoDB和MyISAM兩個引擎的不同配置選項；知道基本的兩個引擎的差異和選擇上面的區別；能夠純手工編譯搭建一個MySQL資料庫並且配置好編碼等正常穩定運行；核心主旨是能夠搭建一個可運行的MySQL資料庫。
PHP
基本語法數組、字元串、資料庫、XML、Socket、GD/ImageMgk圖片處理等等；熟悉各種跟MySQL操作鏈接的api（mysql/mysqli/PDO)，知道各種編碼問題的解決；知道常規熟練使用的PHP框架（ThinkPHP、Zendframework、Yii、Yaf等）；了解基本MVC的運行機制和為什麼這么做，稍微知道不同的PHP框架之間的區別；能夠快速學習一個MVC框架。能夠知道開發工程中的文件目錄組織，有基本的良好的代碼結構和風格，能夠完成小系統的開發和中型系統中某個模塊的開發工作。
前端
如果條件時間允許，可以適當學習下 HTML/CSS/JS 等相關知識，知道什麼web標准，div+css的web/wap頁面模式，知道HTML5和HTML4的區別；了解一些基本的前端只是和JS框架（jQuery之類的）；了解一些基本的javaScript編程知識；（本項不是必須項，如果有時間，稍微了解一下是可以的，不過不建議作為重點，除非個人有強烈興趣）。
系統設計
能夠完成小型系統的基本設計，包括簡單的資料庫設計，能夠完成基本的：瀏覽器 -> Nginx+PHP -> 資料庫 架構的設計開發工作；能夠支撐每天幾十萬到數百萬流量網站的開發維護工作；
第二階段：提高階段 （中級PHP程序員）
重點：提高針對LNMP的技能，能夠更全面的對LNMP有熟練的應用。 目標：能夠隨時隨地搭建好LNMP環境，快速完成常規配置；能夠追查解決大部分遇到的開發和線上環境的問題；能夠獨立承擔中型系統的構架和開發工作；能夠在大型系統中承擔某個中型模塊的開發工作。
1. Linux
在第一階段的基礎上面，能夠流暢的使用Shell腳本來完成很多自動化的工作；awk/sed/perl 也操作的不錯，能夠完成很多文本處理和數據統計等工作；基本能夠安裝大部分非特殊的Linux程序（包括各種庫、包、第三方依賴等等，比如MongoDB/Redis/Sphinx/Luncene/SVN之類的）；了解基本的Linux服務，知道如何查看Linux的性能指標數據，知道基本的Linux下面的問題跟蹤等。
2. Nginx
在第一階段的基礎上面，了解復雜一些的Nginx配置；包括 多核配置、events、proxy_pass，sendfile/tcp_*配置，知道超時等相關配置和性能影響；知道nginx除了web server，還能夠承擔代理伺服器、反向靜態伺服器等配置；知道基本的nginx配置調優；知道如何配置許可權、編譯一個nginx擴展到nginx；知道基本的nginx運行原理（master/worker機制，epoll），知道為什麼nginx性能比apache性能好等知識。
3. MySQL/MongoDB
在第一階段的基礎上面，在MySQL開發方面，掌握很多小技巧，包括常規SQL優化（group by/order by/rand優化等）；除了能夠搭建MySQL，還能夠冷熱備份MySQL數據，還知道影響innodb/myisam性能的配置選項（比如key_buffer/query_cache/sort_buffer/innodb_buffer_pool_size/innodb_flush_log_at_trx_commit等），也知道這些選項配置成為多少值合適；另外也了解一些特殊的配置選項，比如 知道如何搭建mysql主從同步的環境，知道各個binlog_format的區別；知道MySQL的性能追查，包括slow_log/explain等，還能夠知道基本的索引建立處理等知識；原理方面了解基本的MySQL的架構（Server+存儲引擎），知道基本的InnoDB/MyISAM索引存儲結構和不同（聚簇索引，B樹）；知道基本的InnoDB事務處理機制；了解大部分MySQL異常情況的處理方案（或者知道哪兒找到處理方案）。條件允許的情況，建議了解一下NoSQL的代表MongoDB資料庫，順便對比跟MySQL的差別，同事能夠在合適的應用場景安全謹慎的使用MongoDB，知道基本的PHP與MongoDB的結合開發。
4. Redis/Memcached
在大部分中型系統裡面一定會涉及到緩存處理，所以一定要了解基本的緩存；知道Memcached和Redis的異同和應用場景，能夠獨立安裝 Redis/Memcached，了解Memcahed的一些基本特性和限制，比如最大的value值，知道PHP跟他們的使用結合；Redis了解基本工作原理和使用，了解常規的數據類型，知道什麼場景應用什麼類型，了解Redis的事務等等。原理部分，能夠大概了解Memcached的內存結構（slab機制），redis就了解常用數據類型底層實現存儲結構（SDS/鏈表/SkipList/HashTable）等等，順便了解一下Redis的事務、RDB、AOF等機制更好。
5. PHP
除了第一階段的能力，安裝配置方面能夠隨意安裝PHP和各種第三方擴展的編譯安裝配置；了解php-fpm的大部分配置選項和含義（如max_requests/max_children/request_terminate_timeout之類的影響性能的配置），知道mod_php/fastcgi的區別；在PHP方面已經能夠熟練各種基礎技術，還包括各種深入些的PHP，包括對PHP面向對象的深入理解/SPL/語法層面的特殊特性比如反射之類的；在框架方面已經閱讀過最少一個以上常規PHP MVC框架的代碼了，知道基本PHP框架內部實現機制和設計思想；在PHP開發中已經能夠熟練使用常規的設計模式來應用開發（抽象工廠/單例/觀察者/命令鏈/策略/適配器 等模式）；建議開發自己的PHP MVC框架來充分讓開發自由化，讓自己深入理解MVC模式，也讓自己能夠在業務項目開發里快速升級；熟悉PHP的各種代碼優化方法，熟悉大部分PHP安全方面問題的解決處理；熟悉基本的PHP執行的機制原理（Zend引擎/擴展基本工作機制）。
6. C/C++
開始涉獵一定的C/C++語言，能夠寫基本的C/C++代碼，對基本的C/C++語法熟悉（指針、數組操作、字元串、常規標准API）和數據結構（鏈表、樹、哈希、隊列）有一定的熟悉下；對Linux下面的C語言開發有基本的了解概念，會簡單的makefile文件編寫，能夠使用簡單的GCC/GDB的程序編譯簡單調試工作；對基本的網路編程有大概了解。（本項是為了向更高層次打下基礎）。
7. 前端
在第一階段的基礎上面，熟悉基本的HTTP協議（協議代碼200/300/400/500，基本的HTTP交互頭）；條件允許，可以在深入寫出稍微優雅的HTML+CSS+JavaScript，或者能夠大致簡單使用某些前端框架（jQuery/YUI/ExtJS/RequireJS/BootStrap之類）；如果條件允許，可以深入學習JavaScript編程，比如閉包機制、DOM處理；再深入些可以讀讀jQuery源碼做深入學習。（本項不做重點學習，除非對前端有興趣）。
8. 系統設計
能夠設計大部分中型系統的網站架構、資料庫、基本PHP框架選型；性能測試排查處理等；能夠完成類似：瀏覽器 -> CDN(Squid) -> Nginx+PHP -> 緩存 -> 資料庫 結構網站的基本設計開發維護；能夠支撐每天數百萬到千萬流量基本網站的開發維護工作；
第三階段：高級階段 （高級PHP程序員）
重點：除了基本的LNMP程序，還能夠在某個方向或領域有深入學習。（縱深維度發展） 目標：除了能夠完成基本的PHP業務開發，還能夠解決大部分深入復雜的技術問題，並且可以獨立設計完成中大型的系統設計和開發工作；自己能夠獨立hold深入某個技術方向，在這塊比較專業。（比如在MySQL、Nginx、PHP、Redis等等任一方向深入研究）
1. Linux
除了第二階段的能力，在Linux下面除了常規的操作和性能監控跟蹤，還能夠使用很多高級復雜的命令完成工作（watch/tcpmp/starce/ldd/ar等)；在shell腳本方面，已經能夠編寫比較復雜的shell腳本（超過500行）來協助完成很多包括備份、自動化處理、監控等工作的shell；對awk/sed/perl 等應用已經如火純青，能夠隨意操作控制處理文本統計分析各種復雜格式的數據；對Linux內部機制有一些了解，對內核模塊載入，啟動錯誤處理等等有個基本的處理；同時對一些其他相關的東西也了解，比如NFS、磁碟管理等等；
2. Nginx
在第二階段的基礎上面，已經能夠把Nginx操作的很熟練，能夠對Nginx進行更深入的運維工作，比如監控、性能優化，復雜問題處理等等；看個人興趣，更多方面可以考慮側重在關於Nginx工作原理部分的深入學習，主要表現在閱讀源碼開始，比如具體的master/worker工作機制，Nginx內部的事件處理，內存管理等等；同時可以學習Nginx擴展的開發，可以定製一些自己私有的擴展；同時可以對Nginx+Lua有一定程度的了解，看看是否可以結合應用出更好模式；這個階段的要求是對Nginx原理的深入理解，可以考慮成為Nginx方向的深入專業者。
3. MySQL/MongoDB
在第二階段的基礎上面，在MySQL應用方面，除了之前的基本SQL優化，還能夠在完成一些復雜操作，比如大批量數據的導入導出，線上大批量數據的更改表結構或者增刪索引欄位等等高危操作；除了安裝配置，已經能夠處理更多復雜的MySQL的問題，比如各種問題的追查，主從同步延遲問題的解決、跨機房同步數據方案、MySQL高可用架構等都有涉及了解；對MySQL應用層面，對MySQL的核心關鍵技術比較熟悉，比如事務機制（隔離級別、鎖等）、對觸發器、分區等技術有一定了解和應用；對MySQL性能方面，有包括磁碟優化（SAS遷移到SSD）、伺服器優化（內存、伺服器本身配置）、除了二階段的其他核心性能優化選項（innodb_log_buffer_size/back_log/table_open_cache/thread_cache_size/innodb_lock_wait_timeout等）、連接池軟體選擇應用，對show *（show status/show profile）類的操作語句有深入了解，能夠完成大部分的性能問題追查；MySQL備份技術的深入熟悉，包括災備還原、對Binlog的深入理解，冷熱備份，多IDC備份等；在MySQL原理方面，有更多了解，比如對MySQL的工作機制開始閱讀部分源碼，比如對主從同步（復制）技術的源碼學習，或者對某個存儲引擎（MyISAM/Innodb/TokuDB）等等的源碼學習理解，如果條件允許，可以參考CSV引擎開發自己簡單的存儲引擎來保存一些數據，增強對MySQL的理解；在這個過程，如果自己有興趣，也可以考慮往DBA方向發展。MongoDB層面，可以考慮比如說在寫少讀多的情況開始在線上應用MongoDB，或者是做一些線上的數據分析處理的操作，具體場景可以按照工作來，不過核心是要更好的深入理解RMDBS和NoSQL的不同場景下面的應用，如果條件或者興趣允許，可以開始深入學習一下MongoDB的工作機制。
4. Redis/Memcached
在第二階段的基礎上面，能夠更深入的應用和學習。因為Memcached不是特別復雜，建議可以把源碼進行閱讀，特別是內存管理部分，方便深入理解；Redis部分，可以多做一些復雜的數據結構的應用（zset來做排行榜排序操作/事務處理用來保證原子性在秒殺類場景應用之類的使用操作）；多涉及aof等同步機制的學習應用，設計一個高可用的Redis應用架構和集群；建議可以深入的學習一下Redis的源碼，把在第二階段積累的知識都可以應用上，特別可以閱讀一下包括核心事件管理、內存管理、內部核心數據結構等充分學習了解一下。如果興趣允許，可以成為一個Redis方面非常專業的使用者。
5. PHP
作為基礎核心技能，我們在第二階段的基礎上面，需要有更深入的學習和應用。從基本代碼應用上面來說，能夠解決在PHP開發中遇到95%的問題，了解大部分PHP的技巧；對大部分的PHP框架能夠迅速在一天內上手使用，並且了解各個主流PHP框架的優缺點，能夠迅速方便項目開發中做技術選型；在配置方面，除了常規第二階段會的知識，會了解一些比較偏門的配置選項（php auto_prepend_file/auto_append_file），包括擴展中的一些復雜高級配置和原理（比如memcached擴展配置中的memcache.hash_strategy、apc擴展配置中的apc.mmap_file_mask/apc.slam_defense/apc.file_update_protection之類的）；對php的工作機制比較了解，包括php-fpm工作機制（比如php-fpm在不同配置機器下面開啟進程數量計算以及原理），對zend引擎有基本熟悉（vm/gc/stream處理），閱讀過基本的PHP內核源碼（或者閱讀過相關文章），對PHP內部機制的大部分核心數據結構（基礎類型/Array/Object）實現有了解，對於核心基礎結構（zval/hashtable/gc）有深入學習了解；能夠進行基本的PHP擴展開發，了解一些擴展開發的中高級知識（minit/rinit等），熟悉php跟apache/nginx不同的通信交互方式細節（mod_php/fastcgi）；除了開發PHP擴展，可以考慮學習開發Zend擴展，從更底層去了解PHP。
6. C/C++
在第二階段基礎上面，能夠在C/C++語言方面有更深入的學習了解，能夠完成中小型C/C++系統的開發工作；除了基本第二階段的基礎C/C++語法和數據結構，也能夠學習一些特殊數據結構（b-tree/rb-tree/skiplist/lsm-tree/trie-tree等）方便在特殊工作中需求；在系統編程方面，熟悉多進程、多線程編程；多進程情況下面了解大部分多進程之間的通信方式，能夠靈活選擇通信方式（共享內存/信號量/管道等）；多線程編程能夠良好的解決鎖沖突問題，並且能夠進行多線程程序的開發調試工作；同時對網路編程比較熟悉，了解多進程模型/多線程模型/非同步網路IO模型的差別和選型，熟悉不同非同步網路IO模型的原理和差異（select/poll/epoll/iocp等），並且熟悉常見的非同步框架（ACE/ICE/libev/libevent/libuv/Boost.ASIO等）和使用，如果閑暇也可以看看一些國產自己開發的庫（比如muo）；同時能夠設計好的高並發程序架構（leader-follow/master-worker等）；了解大部分C/C++後端Server開發中的問題（內存管理、日誌列印、高並發、前後端通信協議、服務監控），知道各個後端服務RPC通信問題（struct/http/thirft/protobuf等）；能夠更熟絡的使用GCC和GDB來開發編譯調試程序，在線上程序core掉後能夠迅速追查跟蹤解決問題；通用模塊開發方面，可以積累或者開發一些通用的工具或庫（比如非同步網路框架、日誌庫、內存池、線程池等），不過開發後是否應用要謹慎，省的埋坑去追bug。
7. 前端
深入了解HTTP協議（包括各個細致協議特殊協議代碼和背後原因，比如302靜態文件緩存了，502是nginx後面php掛了之類的）；除了之前的前端方面的各種框架應用整合能力，前端方面的學習如果有興趣可以更深入，表現形式是，可以自己開發一些類似jQuery的前端框架，或者開發一個富文本編輯器之類的比較瑣碎考驗JavaScript功力。
8. 其他領域語言學習
在基礎的PHP/C/C++語言方面有基本積累，建議在當前階段可以嘗試學習不同的編程語言，看個人興趣愛好，腳本類語言可以學學 Python/Ruby 之類的，函數式編程語言可以試試 Lisp/Haskell/Scala/Erlang 之類的，靜態語言可以試試 Java/Golang，數據統計分析可以了解了解R語言，如果想換個視角做後端業務，可以試試 Node.js還有前面提到的跟Nginx結合的Nginx_Lua等。學習不同的語言主要是提升自己的視野和解決問題手段的差異，比如會了解除了進程/線程，還有輕量級協程；比如在跨機器通信場景下面，Erlang的解決方案簡單的驚人；比如在不想選擇C/C++的情況下，還有類似高效的Erlang/Golang可用等等；主要是提升視野。
9. 其他專業方向學習
在本階段裡面，會除了基本的LNMP技能之外，會考慮一些其他領域知識的學習，這些都是可以的，看個人興趣和長期的目標方向。目前情況能夠選擇的領域比較多，比如、雲計算（分布式存儲、分布式計算、虛擬機等），機器學習（數據挖掘、模式識別等，應用到統計、個性化推薦），自然語言處理（中文分詞等），搜索引擎技術、圖形圖像、語音識別等等。除了這些高大上的，也有很多偏工程方面可以學習的地方，比如高性能系統、移動開發（Android/IOS）、計算機安全、嵌入式系統、硬體等方向。
10. 系統設計
系統設計在第二階段的基礎之上，能夠應用掌握的經驗技能，設計出比較復雜的中大型系統，能夠解決大部分線上的各種復雜系統的問題，完成類似 瀏覽器 -> CDN -> 負載均衡 ->接入層 -> Nginx+PHP -> 業務緩存 -> 資料庫 -> 各路復雜後端RPC交互（存儲後端、邏輯後端、反作弊後端、外部服務） -> 更多後端 醬紫的復雜業務；能夠支撐每天數千萬到數億流量網站的正常開發維護工作。
B. 抽象工廠模式的簡介
當每個抽象產品都有多於一個的具體子類的時候，工廠角色怎麼知道實例化哪一個子類呢？比如每個抽象產品 角色都有兩個具體產品。抽象工廠模式提供兩個具體工廠角色，分別對應於這兩個具體產品角色，每一個具體工廠角色只負責某一個產品角色的實例化。每一個具體工廠類只負責創建抽象產品的某一個具體子類的實例。
每一個模式都是針對一定問題的解決方案，工廠方法模式針對的是一個產品等級結構；而抽象工廠模式針對的是多個產品等級結構。
C. 什麼是抽象工廠
工廠模式定義:提供創建對象的介面.
為何使用?
工廠模式是我們最常用的模式了,著名的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。
在實際應用中，工廠方法用得比較多一些，而且是和動態類裝入器組合在一起應用，
舉例
我們以Jive的ForumFactory為例，這個例子在前面的Singleton模式中我們討論過，現在再討論其工廠模式:
public abstract class ForumFactory {
private static Object initLock = new Object();
private static String className = "com.jivesoftware.forum.database.DbForumFactory";
private static ForumFactory factory = null;
public static ForumFactory getInstance(Authorization authorization) {
//If no valid authorization passed in, return null.
if (authorization == null) {
return null;
}
//以下使用了Singleton 單態模式
if (factory == null) {
synchronized(initLock) {
if (factory == null) {
......
try {
//動態轉載類
Class c = Class.forName(className);
factory = (ForumFactory)c.newInstance();
}
catch (Exception e) {
return null;
}
}
}
}
//Now, 返回 proxy.用來限制授權對forum的訪問
return new ForumFactoryProxy(authorization, factory,
factory.getPermissions(authorization));
}
//真正創建forum的方法由繼承forumfactory的子類去完成.
public abstract Forum createForum(String name, String description)
throws UnauthorizedException, ForumAlreadyExistsException;
....
}
因為現在的Jive是通過資料庫系統存放論壇帖子等內容數據,如果希望更改為通過文件系統實現,這個工廠方法ForumFactory就提供了提供動態介面:
private static String className = "com.jivesoftware.forum.database.DbForumFactory";
你可以使用自己開發的創建forum的方法代替com.jivesoftware.forum.database.DbForumFactory就可以.
在上面的一段代碼中一共用了三種模式,除了工廠模式外,還有Singleton單態模式,以及proxy模式,proxy模式主要用來授權用戶對forum的訪問,因為訪問forum有兩種人:一個是注冊用戶 一個是遊客guest,那麼那麼相應的許可權就不一樣,而且這個許可權是貫穿整個系統的,因此建立一個proxy,類似網關的概念,可以很好的達到這個效果.
看看Java寵物店中的CatalogDAOFactory:
public class CatalogDAOFactory {
/**
* 本方法制定一個特別的子類來實現DAO模式。
* 具體子類定義是在J2EE的部署描述器中。
*/
public static CatalogDAO getDAO() throws CatalogDAOSysException {
CatalogDAO catDao = null;
try {
InitialContext ic = new InitialContext();
//動態裝入CATALOG_DAO_CLASS
//可以定義自己的CATALOG_DAO_CLASS，從而在無需變更太多代碼
//的前提下，完成系統的巨大變更。
String className =(String) ic.lookup(JNDINames.CATALOG_DAO_CLASS);
catDao = (CatalogDAO) Class.forName(className).newInstance();
} catch (NamingException ne) {
throw new CatalogDAOSysException("
CatalogDAOFactory.getDAO: NamingException while
getting DAO type : \n" + ne.getMessage());
} catch (Exception se) {
throw new CatalogDAOSysException("
CatalogDAOFactory.getDAO: Exception while getting
DAO type : \n" + se.getMessage());
}
return catDao;
}
}
CatalogDAOFactory是典型的工廠方法，catDao是通過動態類裝入器className獲得CatalogDAOFactory具體實現子類，這個實現子類在Java寵物店是用來操作catalog資料庫，用戶可以根據資料庫的類型不同，定製自己的具體實現子類，將自己的子類名給與CATALOG_DAO_CLASS變數就可以。
由此可見，工廠方法確實為系統結構提供了非常靈活強大的動態擴展機制，只要我們更換一下具體的工廠方法，系統其他地方無需一點變換，就有可能將系統功能進行改頭換面的變化。
設計模式如何在具體項目中應用見《Java實用系統開發指南》
文章地址:
http://www.jdon.com/designpatterns/designpattern_factory.htm
http://zh.wikipedia.org/wiki/%E6%8A%BD%E8%B1%A1%E5%B7%A5%E5%8E%82%E6%A8%A1%E5%BC%8F
http://www.cnblogs.com/yuyijq/archive/2007/10/06/915185.html
D. 在抽象工廠模式中怎樣使用memcached緩存數據
一、Memcached簡介
memcached 常被用來加速應用程序的處理，在這里，我們將著重於介紹將它部署於應用程序和環境中的最佳實踐。這包括應該存儲或不應存儲哪些、如何處理數據的靈活分布以 及如何調節用來更新 memcached 和所存儲數據的方法。我們還將介紹對高可用性的解決方案的支持，比如 IBM WebSphere® eXtreme Scale。
所有的應用程序，特別是很多 web 應用程序都需要優化它們訪問客戶機和將信息返回至客戶機的速度。可是，通常，返回的都是相同的信息。從數據源（資料庫或文件系統）載入數據十分低效，若是每次想要訪問該信息時都運行相同的查詢，就尤顯低效。
雖然很多 web 伺服器都可被配置成使用緩存發回信息，但那與大多數應用程序的動態特性無法相適。而這正是 memcached 的用武之地。它提供了一個通用的內存存儲器，可保存任何東西，包括本地語言的對象，這就讓您可以存儲各種各樣的信息並可以從諸多的應用程序和環境訪問這些信息。
二、基礎知識
memcached 是一個開源項目，旨在利用多個伺服器內的多餘 RAM 來充當一個可存放經常被訪問信息的內存緩存。這里的關鍵是使用了術語緩存：memcached 為載入自他處的信息提供的是內存中的暫時存儲。
比如，考慮這樣一個典型的基於 web 的應用程序。即便是一個動態網站可能也會有一些組件或信息常量是貫穿頁面整個生命周期的。在一個博客站點內，針對單個 blog post 的類別列表不大可能在頁面查看間經常性地變更。每次都通過一個對資料庫的查詢載入此信息相對比較昂貴，特別是在數據沒有更改的情況下，就更是如此。從圖 1 可以看到一個博客站點內可被緩存的頁面分區。
圖1.一個典型的博客頁面內的可緩存元素
將這種結構放在 blog 站點的其他元素，poster 信息、注釋 — 設置 blog post 本身 — 進行推斷，可以看出為了顯示主頁的內容很可能需要發生 10-20 次資料庫查詢和格式化。 每天對數百甚至數千的的頁面查看重復此過程，那麼您的伺服器和應用程序執行的查詢要遠遠多於為了顯示頁面內容所需執行的查詢。
通過使用 memcached，可以將載入自資料庫的格式化信息存儲為一種可直接用在 Web 頁面上的格式。並且由於信息是從 RAM 而不是通過資料庫和其他處理從磁碟載入的，所以對信息的訪問幾乎是瞬時的。
再強調一下，memcached 是一個用來存儲常用信息的緩存，有了它，您便無需從緩慢的資源，比如磁碟或資料庫，載入並處理信息了。
對 memcached 的介面是通過網路連接提供的。這意味著您可以在多個客戶機間共享單個的 memcached 伺服器（或多個伺服器，如本文稍後所示的）。這個網路介面非常迅速，並且為了改善性能，伺服器會故意不支持身份驗證或安全性通信。但這不應限制部署選項。 memcached 伺服器應該存在於您網路的內部。網路介面的實用性以及可以部署多個 memcached 實例的簡便性讓您可以使用多個機器上的多餘 RAM 來提高您緩存的整體大小。
三、存儲方法
memcached 的存儲方法是一個簡單的鍵/值對，類似於很多語言內的散列或關聯數組。通過提供鍵和值來將信息存儲到 memcached 內，通過按特定的鍵請求信息來恢復信息。
信息會無限期地保留在緩存內，除非發生如下的情況：
為緩存分配的內存耗盡 — 在這種情況下，memcached 使用 LRU（最近最少使用）方法從此緩存刪除條目。最近未曾使用的條目會從此緩存中先刪除，最舊的最先訪問。
條目被明確刪除 — 總是可以從此緩存內刪除條目。
條目過期失效 — 各條目均有一個有效的期限以便針對此鍵存儲的信息在過於陳舊時可從緩存中清除這些條目。
上述這些情況可以與您應用程序的邏輯綜合使用以便確保緩存內的信息是最新的。有了這些基礎知識後，讓我們來看看在應用程序內如何能最好地利用 memcached。
四、何時使用memcached？
在使用 memcached 改進應用程序性能時，可以對一些關鍵的過程和步驟進行修改。
在載入信息時，典型的場景如圖 2 所示。
圖2.載入要顯示的信息的典型順序
一般而言，這些步驟是：
執行一個或多個查詢來從資料庫載入信息
格式化適合於顯示（或進一步處理）的信息
使用或顯示格式化了的數據
在使用 memcached 時，為配合這個緩存，可對應用程序的邏輯進行稍許修改：
盡量從緩存載入信息
如果存在，使用信息的被緩存版本
如果它不存在：
執行一個或多個查詢來從資料庫載入信息
格式化適合於顯示或進一步處理的信息
將信息存儲到緩存內
使用格式化了的數據
圖 3 是對這些步驟的總結。
圖3.在使用memcached時載入適合於顯示的信息
數據載入成為了至多三個步驟的一個過程，從緩存載入數據或從資料庫（視情況而定）載入數據並存儲在緩存內。
當這個過程首次發生時，數據將正常地從資料庫或其他數據源載入，然後再存儲到 memcached 內。當下一次訪問此信息時，它就會從 memcached 拉出，而不是從資料庫載入，節省了時間和 CPU 循環。
問題的另一個方面是要確保如果更改了要存儲在 memcached 內的信息，在更新後端信息的同時還要更新 memcached 的版本。這會讓圖 4 內所示的這個典型順序發生稍許變化，如 圖 5 所示。
圖4.在一個典型的應用程序內更新或存儲數據
圖 5 顯示了使用 memcached 後發生了變化的流程。
圖5.在使用memcached時更新或存儲數據
比如，仍以博客站點為例，在博客系統更新資料庫內的類別列表時，更新應該遵循如下順序：
更新資料庫內的類別列表
格式化信息
將信息存儲到 memcached 內
將信息返回至客戶機
memcached 內的存儲操作是原子的，所以信息的更新不會讓客戶機只獲得部分數據；它們獲得的或者是老版本，或者是新版本。
對於大多數應用程序，這兩個操作是您惟一需要注意的。在訪問他人使用的數據時，它會自動被添加到這個緩存內，而且如果對該數據進行了更改，此緩存內也會自動進行更新。
五、鍵、名稱空間和值
memcached 另一個需要重點考慮的因素是如何組織和命名存儲在緩存內的這些數據。從之前博客站點的例子中，不難看出需要使用一種一致的命名結構以便您能載入博客類別、歷史和其他信息，然後再在載入信息（並更新緩存）時或者在更新數據（同樣也要更新緩存）時使用。
使用的何種具體的命名系統特定於應用程序，但通常可以使用一種與現有應用程序類似的結構，並且這種結構很可能基於某種惟一識別符。當從資料庫拉出信息或在整理信息集時，就會發生這種情況。
以 blog post 為例，可以在一個具有鍵 category-list 的項中存儲類別列表。與此 post ID 對應的單個 post，比如 blogpost-29 相關的值都可以使用，而該項的注釋則可以存儲在 blogcomments-29內，其中 29 就是這個 blog post 的 ID。這樣一來， 您就可以將各種各樣的信息存儲在緩存內，使用不同的前綴來標識這些信息。
memcached 鍵/值存儲的簡便性（以及安全性的缺乏）意味著如果您想要在使用同一個 memcached 伺服器的同時支持多個應用程序，那麼就可以考慮使用其他格式的量詞來標識數據屬於某種特定的應用程序。比如，可以添加像 blogapp:blogpost-29 這樣的應用程序前綴。這些鍵是沒有格式的，所以可以使用任何字元串作為鍵的名稱。
在存儲值的方面，應該確保存儲在緩存內的信息適合於您的應用程序。比如，對於這個博客系統，您可能想要存儲被博客應用程序使用的對象以便格式化博客信息，而不是原始的 HTML。如果同一個基礎結構用在應用程序內的多個地方，這一點更具實用性。
大多數語言的介面，包括 Java™、Perl、PHP 等，都能串列化語言對象以便存儲在 memcached 內。這就讓您可以存儲並隨後從內存存儲恢復全部對象，而不是在您的應用程序內手動重構它們。 很多對象，或它們使用的結構，都基於某種散列或數組結構。對於跨語言的環境，比如在 JSP 環境和 JavaScript 環境間共享相同信息，可以使用一種架構中立的格式，比如 JavaScript Object Notation (JSON) 甚或 XML。
六、填充並使用memcached
作為一種開源產品以及一種最初開發用來工作於現有開源環境內的產品，memcached 受大量環境和平台支持。與 memcached 伺服器通信的介面有很多，並常常具有針對所有語言的多個實現。參見參考資料 以獲得常用的庫和工具箱。
要列出所有受支持的介面和環境不太可能，但它們均支持 memcached 協議提供的基礎 API。這些描述已經被簡化並應用在不同語言的上下文內，在這些語言中，使用不同的值可指示錯誤。主要的函數有：
get(key) — 從存儲了特定鍵的 memcached 獲得信息。 如果鍵不存在，就返回錯誤。
set(key, value [, expiry]) — 使用緩存內的標識符鍵存儲這個特定的值。如果鍵已經存在，那麼它就會被更新。期滿時間的單位為秒，並且如果值小於 30 天 (30*24*60*60)，那麼就用作相對時間，如果值大於 30 天，那麼就用作絕對時間 (epoch)。
add(key, value [, expiry]) — 如果鍵不存在就將這個鍵添加到緩存內，如果鍵已經存在就返回錯誤。如果您想要顯式地添加一個新鍵而又不會因它已經存在而更新它，那麼這個函數將十分有用。
replace(key, value [, expiry]) — 更新此特定鍵的值，如果鍵不存在就返回一個錯誤。
delete(key [, time]) — 從緩存中刪除此鍵/值對。如果您提供一個時間，那麼添加具有此鍵的一個新值就會被阻塞這個特定的時期。超時讓您可以確保此值總是可以重新讀取自您的數據中心。
incr(key [, value]) — 為特定的鍵增 1 或特定的值。只適用於數值。
decr(key [, value]) — 為特定的鍵減 1 或特定的值，只適用於數值。
flush_all — 讓緩存內的所有當前條目無效（或到期失效）。
比如，在 Perl 內，基本 set 操作可以如清單 1 所示的那樣處理。
清單 1. Perl 內的基本 set 操作
use Cache::Memcached;
my $cache = new Cache::Memcached {
'servers' => [
'localhost:11211',
],
};
$cache->set('mykey', 'myvalue');
Ruby 內的相同的基本操作如清單 2 所示。
清單 2. Ruby 內的基本 set 操作
require 'memcache'
memc = MemCache::new '192.168.0.100:11211'
memc["mykey"] = "myvalue"
在兩個例子中可以看到相同的基本結構：設置 memcached 伺服器，然後分配或設置值。其他的介面也可用，包括適合於 Java 技術的那些介面，讓您可以在 WebSphere 應用程序內使用 memcached。memcached 介面類允許將 Java 對象直接序列化到 memcached 以便於存儲和載入復雜的結構。當在像 WebSphere 這樣的環境內進行部署時，有兩個事情非常重要：服務的彈性（在 memcached 不可用時如何做）以及如何提高緩存存儲量來改進在使用多個應用程序伺服器或在使用像 WebSphere eXtreme Scale 這樣的環境時的性能。我們接下來就來看看這兩個問題。
七、彈性和可用性
有關 memcached 最常見的一個問題是：「若緩存不可用了，會發生什麼情況呢？」正如之前章節中明示的，緩存內的信息不應該成為信息的的惟一資源。必須要能夠從其他位置載入存儲在緩存內的數據。
雖然，無法從緩存訪問信息將會減緩應用程序的性能，但它不應該阻止應用程序的運轉。可能會發生這樣幾個場景：
如果 memcached 服務宕掉，應用程序應該回退到從原始數據源載入信息並對信息進行顯示所需的格式化。此應用程序還應繼續嘗試在 memcached 內載入和存儲信息。
一旦 memcached 伺服器恢復可用，應用程序就應該自動嘗試存儲數據。沒有必要強制重載已緩存了的數據，可以使用標準的訪問來用信息載入和填充緩存。最終，緩存將會被最常用的數據重新填充。
再次重申，memcached 是信息的緩存但並非惟一的數據源。memcached 伺服器不可用不應該是應用程序的終結，雖然這意味著在 memcached 伺服器恢復正常之前性能會有所降低。實際上，memcached 伺服器相對簡單，並且雖然不是絕對無故障的，但它的簡單性的結果就是它很少會出錯。
八、分配緩存
memcached 伺服器只是網路上針對一些鍵存儲值的一個緩存。如果有多台機器，那麼很自然地會想要在所有多餘機器上設置一個 memcached 的實例來提供一個超大的聯網 RAM 緩存存儲。
有了這個想法後，還有一種想當然是需要使用某種分配或復制機制來在機器之間復制鍵/值對。這種方式的問題是如果這么做反而會減少可用的 RAM 緩存，而不是增加。如圖 6 所示，可以看出這里有三個應用程序伺服器，每個伺服器都可以訪問一個 memcached 實例。
圖6.多重memcached實例的不正確使用
盡管每個 memcached 實例都是 1 GB 的大小（產生 3 GB 的 RAM 緩存），但如果每個應用程序伺服器只有其自己的緩存（或者在 memcached 之間存在著數據的復制），那麼整個安裝也仍只能有 1 GB 的緩存在每個實例間復制。
由於 memcached 通過一個網路介面提供信息，因此單個的客戶機可以從它所能訪問的任何一個 memcached 實例訪問數據。如果數據沒有跨每個實例被復制，那麼最終在每個應用程序伺服器上，就可以有 3 GB 的 RAM 緩存可用，如圖 7 所示。
圖7.多重memcached實例的正確使用
這個方法的問題是選擇哪個伺服器來儲存鍵/值對，以及當想要重新獲得一個值時，如何決定要與哪個 memcached 伺服器對話。問題的解決方案就是忽略復雜的東西，比如查找表，或是寄望 memcached 伺服器來為您處理這個過程。而 memcached 客戶機則必須要力求簡單。
memcached 客戶機不必決定此信息，它只需對在存儲信息時指定的鍵使用一個簡單的散列演算法。當想要從一列 memcached 伺服器存儲或獲取信息時，memcached 客戶機就會用一個一致的散列演算法從這個鍵獲取一個數值。舉個例子，鍵 mykey 被轉換成數值 23875 。是保存還是獲取信息無關緊要，這個鍵將總是被用作惟一標識符來從 memcached 伺服器載入，因此在本例中，「mykey」 散列轉化後對應的值總是 23875。
如果有兩個伺服器，那麼 memcached 客戶機將對這個數值進行一個簡單的運算（例如，系數）來決定它應將此值存儲在第一個還是第二個配置了的 memcached 實例上。
當存儲一個值時，客戶機會從這個鍵確定出散列值以及它原來存儲在哪個伺服器上。當獲取一個值時，客戶機會從這個鍵確定出相同的散列值並會選擇相同的伺服器來獲取信息。
如果在每個應用程序伺服器上使用的是相同的伺服器列表（並且順序相同），那麼當需要保存或檢索同一個鍵時，每個應用程序伺服器都將選擇同一個 伺服器。現在，在這個例子中，有 3GB 的 memcached 空間可以共享，而不是同一個 1 GB 的空間的復制，這就帶來了更多的可用緩存，並很有可能會提高有多個用戶情況下的應用程序的性能。
九、如何能不使用memcached？
盡管 memcached 很簡單，但 memcached 實例有時候還是會被不正確地使用。
memcached不是一個資料庫
最常見的 memcached 誤用就是把它用作一個數據存儲，而不是一個緩存。memcached 的首要目的就是加快數據的響應時間，否則數據從其他數據源構建或恢復需要很長時間。一個典型的例子就是從一個資料庫中恢復信息，特別是在信息顯示給用戶前 需要對信息進行格式化或處理的時候。Memcached 被設計用來將信息存儲在內存中以避免每次在數據需要恢復時重復執行相同的任務。
切不可將 memcached 用作運行應用程序所需信息的惟一信息源；數據應總是可以從其他信息源獲取。此外，要記住 memcached 只是一個鍵/值的存儲。不能在數據上執行查詢，或者對內容進行迭代來提取信息。應該使用它來存儲數據塊或對象以備批量使用。
不要緩存資料庫行或文件
雖然可以使用 memcached 存儲載入自資料庫的數據行，但這實際上是查詢緩存，並且大多數資料庫都提供各自的查詢緩存的機制。其他的對象，比如文件系統的圖像或文件的情況與此相同。很多應用程序和 web 伺服器針對此類工作已經有了一些很好的解決方案。
如果在載入和格式化後，使用它來存儲全部信息塊，就可以從 memcached 獲得更多的實用工具和性能上的改善。仍以我們的博客站點為例，存儲信息的最佳點是在將博客類別格式化為對象，甚至是在格式化成 HTML 後。博客頁面的構造可通過從 memcached 載入各個組件（比如 blog post、category list、post history 等）並將完成的 HTML 寫回至客戶機實現。
memcached並不安全
為了確保最佳性能，memcached 並未提供任何形式的安全性，沒有身份驗證，也沒有加密。這意味著對 memcached 伺服器的訪問應該這么處理：一是通過將它們放到應用程序部署環境相同的私有側，二是如果安全性是必須的，那麼就使用 UNIX® socket 並只允許當前主機上的應用程序訪問此 memcached 伺服器。
這多少犧牲了一些靈活性和彈性，以及跨網路上的多台機器共享 RAM 緩存的能力，但這是在目前的情況下確保 memcached 數據安全性的惟一一種解決方案。
十、不要限制自己
除了不應該使用 memcached 實例的情況外，memcached 的靈活性不應忽視。由於 memcached 與應用程序處於相同的架構水平，所以很容易集成並連接到它。並且更改應用程序以便利用 memcached 也並不復雜。此外，由於 memcached 只是一個緩存，所以在出現問題時它不會停止應用程序的執行。如果使用正確的話，它所做的是減輕其餘伺服器基礎設施的負載（減少對資料庫和數據源的讀操 作），這意味著無需更多的硬體就可以支持更多的客戶機。
但請記住，它僅僅是個緩存！
結束語
在本文中，我們了解了 memcached 以及如何最佳地使用它。我們看到了信息如何存儲、如何選擇合理的鍵以及如何選擇要存儲的信息。我們還討論了所有 memcached 用戶都要遇到的一些關鍵的部署問題，包括多伺服器的使用、當 memcached 實例消亡時該怎麼做，以及（也許最為重要的）在哪些情況下不能使用 memcached。
作為一種開源的應用程序並且是目的簡單而直白的應用程序，memcached 的功能和實用性均來自於這種簡單性。通過為信息提供巨大的 RAM 存儲空間、讓它在網路上可用，然後再讓它可通過各種不同的介面和語言訪問到，memcached 可被集成到多種多樣的安裝和環境中。
E. 抽象工廠怎麼理解
抽象工廠模式（英語：Abstract Factory）是一種常見的設計模式。此模式為一個產品家族提供了統一的創建介面。當需要這個產品家族的某一系列的時候，可以從抽象工廠中選出相對系的系列來創建一個具體的工廠類別。
假設我們有兩種產品介面 Button 和 Border ，每一種產品都支持多種系列，比如 Mac 系列和 Windows 系列。這樣每個系列的產品分別是 MacButton, WinButton, MacBorder, WinBorder 。為了可以在運行時刻創建一個系列的產品族，我們可以為每個系列的產品族建立一個工廠 MacFactory 和 WinFactory 。每個工廠都有兩個方法 CreateButton 和 CreateBorder 並返回對應的產品，可以將這兩個方法抽象成一個介面 AbstractFactory 。這樣在運行時刻我們可以選擇創建需要的產品系列。
F. 怎樣用php實現編輯完美私服的角色數據
最近學習PHP5介面的過程中遇到了困難 ，書中說是實現多重繼承的一種方式，但我依然不知道具體該如何實現。在網上查PHP介面的資料很少，就查了java的，其實基本上都差不多。看完包裝機《澄清Java（介面與繼承）》這篇文章才恍然大悟，原來包裝機我一開始理解就有誤，所謂的多重繼承是指介面繼承類，而不是類繼承介面。
文章中提到了OO的抽象，正如文章中的那句話——"抽象就是抽去像的部分"，很形象，以前想到抽象總是認為很難理解，抽象嘛，哈哈，現在就很容易理解了，這也正是介面和抽象類所要做的事情。
文章中還有很多觀點也讓我受益匪淺，羅列如下：
OO的精髓，我以為，是對對象的抽象。
介面的作用，一言以蔽之，就是標志類的類別（type of class）。把不同類型的類歸於不同的介面，可以更好的管理他們。
繼承的意義也在於抽象，而不是代碼重用。
看完這篇文章，現在基本上理解介面、抽象類、繼承該如何應用了。
原文如下：
澄清Java（介面與繼承） 計算機學院研二的兄弟與我討論Java，一見面，幾個問題全是關於介面，介面有什麼用？為什麼要用介面？什麼時候該使用介面？很慶幸他們不是問我 Java如何連接SQL Server，或者是如何開發J2EE應用，這類問題有殺傷力，避之則吉。今年計算機學院本科有個畢業設計課題是做J2ME，選這個題目的學生在5月末都還在苦著臉研究java.util.*這個包，這個這個……唉。
大多數人認為，介面的意義在於頂替多重繼承。眾所周知Java沒有c++那樣多重繼承的機制，但是卻能夠實作多個介面。其實這樣做是很牽強的，介面和繼承是完全不同的東西，介面沒有能力代替多重繼承，也沒有這個義務。介面的作用，一言以蔽之，就是標志類的類別（type of class）。把不同類型的類歸於不同的介面，可以更好的管理他們。OO的精髓，我以為，是對對象的抽象，最能體現這一點的就是介面。為什麼我們討論設計模式都只針對具備了抽象能力的語言（比如c++、java、c#等），就是因為設計模式所研究的，實際上就是如何合理的去抽象。（cowboy的名言是「抽象就是抽去像的部分」，看似調侃，實乃至理）。
設計模式中最基礎的是工廠模式（Factory），在我最近的一個很簡單的應用中，我想盡量的讓我的程序能夠在多個資料庫間移植，當然，這涉及很多問題，單是如何兼容不同DBMS的SQL就讓人頭痛。我們不妨先把問題簡單化，只考慮如何連接不同的資料庫。
假設我有很多個類，分別是Mysql.java、SQLServer.java、Oracle.java、 DB2.java，他們分別連接不同的資料庫，統一返回一個Connection對象，並且都有一個close方法，用於關閉連接。只需要針對你的 DBMS，選擇不同的類，就可以用了，但是我的用戶他會使用什麼資料庫？我不知道，我希望的是盡量少的修改代碼，就能滿足他的需要。我可以抽象如下介面：
package org.bromon.test;
public interface DB
{
java.sql.Connection openDB(String url,String user,String password);
void close();
}
這個介面只定義兩個方法，沒有任何有實際意義的代碼，具體的代碼由實作這個介面的類來給出，比如Mysql.java：
Package org.bromon.test;
import java.sql.*;
public class Mysql implements DB
{
private String url=」jdbc:mysql:localhost:3306/test」;
private String user=」root」;
private String password=」」;
private Connection conn;
public Connection openDB(url,user,password)
{
//連接資料庫的代碼
}
public void close()
{
//關閉資料庫
}
}
類似的當然還有Oracle.java等等，介面DB給這些類歸了個類，在應用程序中我們這樣定義對象：
org.bromon.test.DB myDB;
使用myDB來操作資料庫，就可以不用管實際上我所使用的是哪個類，這就是所謂的「開-閉」原則。但是問題在於介面是不能實例化的，myDB= new DB()，這樣的代碼是絕對錯誤的，我們只能myDB=new Mysql()或者myDB=new Oracle()。麻煩了，我還是需要指定具體實例化的是哪個類，用了介面跟沒用一樣。所以我們需要一個工廠：
package org.bromon.test;
public class DBFactory
{
public static DB Connection getConn()
{
Return(new Mysql());
}
}
所以實例化的代碼變成：myDB=DBFactory.getConn()；
這就是23種模式中最基礎的普通工廠 (Factory)，工廠類負責具體實例化哪個類，而其他的程序邏輯都是針對DB這個介面進行操作，這就是「針對介面編程」。責任都被推卸給工廠類了，當然你也可以繼續定義工廠介面，繼續把責任上拋，這就演變成抽象工廠(Abstract Factory)。
整個過程中介面不負責任何具體操作，其他的程序要連接資料庫的話，只需要構造一個DB對象就OK，而不管工廠類如何變化。這就是介面的意義----抽象。
繼承的概念不用多說，很好理解。為什麼要繼承呢？因為你想重用代碼？這絕對不是理由，繼承的意義也在於抽象，而不是代碼重用。如果對象A有一個 run()方法，對象B也想有這個方法，所以有人就Class B extends A。這是不經大腦的做法。如果在B中實例化一個A，調用A的Run()方法，是不是可以達到同樣的目的？如下：
Class B
{
A a=new A();
a.run();
}
這就是利用類的聚合來重用代碼，是委派模式的雛形，是GoF一貫倡導的做法。
那麼繼承的意義何在？其實這是歷史原因造成的，最開始的OO語言只有繼承，沒有介面，所以只能以繼承來實現抽象，請一定注意，繼承的本意在於抽象，而非代碼重用（雖然繼承也有這個作用），這是很多Java爛書最嚴重的錯誤之一，它們所造成的陰影，我至今還沒有完全擺脫，壞書害人啊，尤其是入門類的，流毒太大。什麼時候應該使用繼承？只在抽象類中使用，其他情況下盡量不使用。抽象類也是不能實例化的，它僅僅提供一個模版而已，這就很能說明問題。
軟體開發的萬惡之源，一是重復代碼而不是重用代碼，二是爛用繼承，尤以c++程序員為甚。Java中取締多重繼承，目的就是制止爛用繼承，實是非常明智的做法，不過很多人都不理解。Java能夠更好的體現設計，這是讓我入迷的原因之一
G. 工廠模式,簡單工廠模式,抽象工廠模式三者有什麼區別
工廠模式、簡單工廠模式、抽象工廠模式三者的區別：
1、創建對象不同。創建對象時，「工廠模式」使用Factory模式替代使用new創建對象；「簡單工廠模式」使用fw模式建立對象；「抽象工廠模式」則使用迭代模式創建對象。
(7)php抽象工廠擴展閱讀
編程使用「工廠模式」的優缺點：
1、優點：
方便擴展演算法，比如增加一個開根號的功能，我們只要繼續繼承運算類就行了，同時客戶端也就是使用者不知道具體的實現細節，只要給出相關標示符，工廠函數就馬上給他創建一個他想要的實體就行了。減少了使用者和功能開發者之間的耦合度。
2、缺點：
在進行擴展的時候，我們要更改工廠函數裡面的那個分支語句Switch，這樣便破壞了OCP，而且當有多級結構繼承的時候，簡單工廠就會因為只能對應平行一層記得繼承，不得不使得好多類繼承同一個介面，然後得到A*B這么多的工廠實體可能，工廠函數很難維護。
H. PHP中抽象類和抽象方法概念與用法分析
本文實例講述了PHP中抽象類和抽象方法。分享給大家供大家參考，具體如下：
一、抽象關鍵字
：abstract
抽象就是無法確切的說明，但又有一定的概念或者名稱，在PHP中聲明一個抽象類或者方法我們需要使用adstract關鍵字。
二、抽象方法和抽象類的定義
一個類中至少有一個方法是抽象的，我們稱之為抽象類。所以如果定義抽象類首先定義抽象方法。
abstract
class
class1{
abstract
function
fun1();
……
}
1、類中至少有一個抽象方法
2、抽象方法不允許有{
}
3、抽象方法前面必須要加abstract
三、抽象類和方法使用規則
抽象類的幾個特點：
1、不能被實例化，只能被繼承
2、繼承的派生類當中要把所有抽象方法重載才能實例化
實例：
<?php
abstract
class
cl1{
abstract
function
fun1();
abstract
function
fun2();
}
class
cl2
extends
cl1{
function
fun1(){
echo
"第一個";
}
function
fun2(){
echo
"第二個";
}
}
$c=new
cl2();
echo
$c->fun2();
?>
更多關於PHP相關內容感興趣的讀者可查看本站專題：《php文件操作總結》、《PHP運算與運算符用法總結》、《PHP網路編程技巧總結》、《PHP基本語法入門教程》、《php操作office文檔技巧總結(包括word,excel,access,ppt)》、《php日期與時間用法總結》、《php面向對象程序設計入門教程》、《php字元串(string)用法總結》、《php+mysql資料庫操作入門教程》及《php常見資料庫操作技巧匯總》
希望本文所述對大家PHP程序設計有所幫助。
I. 工廠模式的抽象工廠
工廠模式中有: 工廠方法(Factory Method) 抽象工廠(Abstract Factory).
這兩個模式區別在於需要創建對象的復雜程度上。如果我們創建對象的方法變得復雜了,如上面工廠方法中是創建一個對象Sample,如果我們還有新的產品介面Sample2.
這里假設：Sample有兩個實體類SampleA和SampleB，而Sample2也有兩個實體類Sample2A和Sample2B
那麼，我們就將上例中Factory變成抽象類,將共同部分封裝在抽象類中,不同部分使用子類實現，下面就是將上例中的Factory拓展成抽象工廠: publicabstractclassFactory{publicabstractSamplecreator();publicabstractSample2creator(Stringname);}{publicSamplecreator(){.........returnnewSampleA}publicSample2creator(Stringname){.........returnnewSample2A}}{publicSamplecreator(){......returnnewSampleB}publicSample2creator(Stringname){......returnnewSample2B}}從上面看到兩個工廠各自生產出一套Sample和Sample2,也許你會疑問，為什麼我不可以使用兩個工廠方法來分別生產Sample和Sample2?
抽象工廠還有另外一個關鍵要點，是因為 SimpleFactory內，生產Sample和生產Sample2的方法之間有一定聯系，所以才要將這兩個方法捆綁在一個類中，這個工廠類有其本身特徵，也許製造過程是統一的，比如：製造工藝比較簡單，所以名稱叫SimpleFactory。
在實際應用中，工廠方法用得比較多一些，而且是和動態類裝入器組合在一起應用，
舉例
我們以Jive的ForumFactory為例，這個例子在前面的Singleton模式中我們討論過，再討論其工廠模式: {privatestaticObjectinitLock=newObject();privatestaticStringclassName="com.jivesoftware.forum.database.DbForumFactory";=null;(Authorizationauthorization){//,returnnull.if(authorization==null){returnnull;}//以下使用了Singleton單態模式if(factory==null){synchronized(initLock){if(factory==null){......try{//動態轉載類Classc=Class.forName(className);factory=(ForumFactory)c.newInstance();}catch(Exceptione){returnnull;}}}}//Now,返回proxy.用來限制授權對forum的訪問returnnewForumFactoryProxy(authorization,factory,factory.getPermissions(authorization));}//真正創建forum的方法由繼承forumfactory的子類去完成.(Stringname,Stringdescription)throwsUnauthorizedException,ForumAlreadyExistsException;....}因為Jive是通過資料庫系統存放論壇帖子等內容數據,如果希望更改為通過文件系統實現,這個工廠方法ForumFactory就提供了提供動態介面:
private static String className = "com.jivesoftware.forum.database.DbForumFactory";
你可以使用自己開發的創建forum的方法代替com.jivesoftware.forum.database.DbForumFactory就可以.
在上面的一段代碼中一共用了三種模式,除了工廠模式外,還有Singleton單態模式,以及proxy模式,proxy模式主要用來授權用戶對forum的訪問,因為訪問forum有兩種人:一個是注冊用戶 一個是遊客guest,那麼那麼相應的許可權就不一樣,而且這個許可權是貫穿整個系統的,因此建立一個proxy,類似網關的概念,可以很好的達到這個效果.
看看Java寵物店中的CatalogDAOFactory: publicclassCatalogDAOFactory{/***本方法制定一個特別的子類來實現DAO模式。*具體子類定義是在J2EE的部署描述器中。*/publicstaticCatalogDAOgetDAO()throwsCatalogDAOSysException{CatalogDAOcatDao=null;try{InitialContextic=newInitialContext();//動態裝入CATALOG_DAO_CLASS//可以定義自己的CATALOG_DAO_CLASS，從而在無需變更太多代碼//的前提下，完成系統的巨大變更。StringclassName=(String)ic.lookup(JNDINames.CATALOG_DAO_CLASS);catDao=(CatalogDAO)Class.forName(className).newInstance();}catch(NamingExceptionne){("CatalogDAOFactory.getDAO::
"+ne.getMessage());}catch(Exceptionse){("CatalogDAOFactory.getDAO:ExceptionwhilegettingDAOtype:
"+se.getMessage());}returncatDao;}}CatalogDAOFactory是典型的工廠方法，catDao是通過動態類裝入器className獲得CatalogDAOFactory具體實現子類，這個實現子類在Java寵物店是用來操作catalog資料庫，用戶可以根據資料庫的類型不同，定製自己的具體實現子類，將自己的子類名給與CATALOG_DAO_CLASS變數就可以。
由此可見，工廠方法確實為系統結構提供了非常靈活強大的動態擴展機制，只要我們更換一下具體的工廠方法，系統其他地方無需一點變換，就有可能將系統功能進行改頭換面的變化。
設計模式如何在具體項目中應用見《Java實用系統開發指南》
J. php設計模式工廠模式有什麼作用
工廠模式分為三種：簡單工廠、工廠方法、抽象工廠 ,三種工廠的區別是，抽象工廠由多條產品線，而工廠方法只有一條產品線，是抽象工廠的簡化。而工廠方法和簡單工廠相對，大家初看起來好像工廠方法增加了許多代碼但是實現的功能和簡單工廠一樣。但本質是，簡單工廠並未嚴格遵循設計模式的開閉原則，當需要增加新產品時也需要修改工廠代碼。但是工廠方法則嚴格遵守開閉原則，模式只負責抽象工廠介面，具體工廠交給客戶去擴展。在分工時，核心工程師負責抽象工廠和抽象產品的定義，業務工程師負責具體工廠和具體產品的實現。只要抽象層設計的好，框架就是非常穩定的。