# <center>1.1什么是設計模式</center> 下面我們給出steve的故事有助于描述現實生活環境中的設計模式，我希望讀者從未聽過這個故事。 ## <center>1.1.1一個普通的示例</center> steve 在一家 大型保險公司工作，他最近的工作是一開發一個通過Web界面將客戶信息顯示給電話客服中心代表的軟件。Steve設計了一個復雜的系統，這個系統允許電話客服中心代表搜索某個客服中心代表的軟件。Stevey設計了一個復雜的系統，這個系統允許電話客服中心代表搜索某個客戶、輸入電話記錄、更新客戶保險金額信息以及處理付款。系統的安裝非常順利，幾乎沒有出現在產品環境中安裝新軟件時經常遇到的麻煩。Steve非常高興，倍感輕松，接下來似乎應當坐下來，愜意地品嘗一下咖啡了。 很快保險公司最新的投資規模達到了以前的3倍。不僅Steve被叫回為電話客服中心軟件提供新的可擴展性和增強處理，而且公司急切希望在其站點上為新招攬和客戶提供某些新的功能。Steve所在的部門也為此增加了兩名開發人員：Andy和Jason。 公司副總提出的要求是：在客戶完成成功和安全的登錄后，公司的站應當允許客戶自己進行相關的支付操作。此外，系統應當顯示客戶呼入電話客服中心的次數。最后，系統應當 顯示客戶帳戶對電話客服中心軟件進行的所有改動的審計日志。 Steve知道：簡單地更新電話客服中心軟件就能夠提供審計日志，隨后復制并改進代碼就可以使用支付處理功能。但是，新加入的編程人員需要盡快投入到新系統的開發工作中。Steve的老板希望兩人接手Steve最熟悉的項目部分。考慮到Steve是經驗最豐富的頂尖PHP編程人員，老板需要Steve盡快完成公司站點的其他部分，然后再投入到新加入編程人員對電話客服中心軟件的審計功能的修改工作中。最后，Steve還要負責為用戶登錄界面的新支付處理部分提供掛鉤程序。 Steve先前編寫的代碼不算糟糕，但是Jason似乎要花費很長時間才能理解這些代碼并完成將支付處理部分移植入公司站點的工作。因此，Jason決定采用自己的方法來編寫代碼，以便于更快地完成任務。Jason向Steve報告了自己的想法，隨即按照這個思路著手開展工作。Andy同樣也忙忙碌碌，因為他剛獲得計算機科學專業的碩士學位，所以沒有太多經驗應對時而混亂的代碼。 經過加班加點的工作，這個團隊終于成功地完成了對新代碼的更改工作。Andy認為整個開發還可以采用更好的體系結構。Steve覺得：其他編程人員如果只是復制和粘貼他原先設計的代碼 ，那么開發進度會更快；Jason和Andy只需要進行一些改進，問題就會迎刃而解。Jason則迫切想解開自己的困惑：為什么某些功能在代碼中的不同部分實現的方式不同。 隨差公司Web站的訪問量越來越多，系統的性能開始變的越來越差。因此，Steve的老板建議開發團隊花時間對代碼進行優化。 Jason發現他為支付處理操作編寫的方法與Steve編寫的方法幾乎完全相同。因此，Jason將這些方法組合寫入一個類中。Steve則開始查看他為電話客服中心站點編寫的身份證驗證代碼與他為公司站點的用戶登錄編寫的類之間的共性。Andy意識到他們創建的所有PHP頁面的頂部具有一組相同的函數調用。因此，他創建了一個引導類型類，以便將所有這些耿耿數調用放在同一個位置，進而減少了代碼的重復。 作為局外人，我們可以客觀地看到很多問題。Steve的代碼可以按照自己的方式從通用性中受益。Andy在軟件設計方法所受到的正規教育使他有是會對PHP完成任務的能力以及體系結構提出質疑。Jason無法累世易地理解Steve設計的支付系統，因此他選擇自己從頭開始創建，從而導致代碼的重復。最后，經過對軟件的分析，這個開發團隊開始在看上去混亂的代碼庫中發現了各種模式。自此，開發團隊開始轉向處理模式。 ## <center>1.1.2設計模式能夠解決相同的問題</center> 在上面的示例中，Steve團隊的錯誤實際上與設計模式概念的第一個重要部分有關。在軟件開發中，該團隊并未明確地創建模式。模式往往是通過實際環境中的實踐和應用發現的。將支付應用系統和引導類型調用合并入特定類就屬于在編程過程中標識模式的示例。 有人曾經說過，所有有音樂片斷都能找到出處。如今，創作新的音樂只是將特定的音符按照不同的順序和速度進行重新的排列。除了某些實現重大突確的特例之外，通常的軟件開發也具有類似的情況。相同的問題會不斷地重復出現，并且需要通用的解決方法。因此，對于這些相同的問題來說，設計模式是一種可重用的解決方案。 任何提及設計模式的書箱都離不開著名的“四人組（Gang of Four)":Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides,這四個人是最早介紹設計模式的書箱和作者。在自己的領域從事長期工作之后，他們開始注意到不同開發項目中出現的設計的特定模式。這4個人將這些想法匯集到一起，從而形成了最早的設計模式概念。通過將特定模式標識為用于未來開發的模板，他們能夠將設計模式表達為易于理解的參照基準，以便人們能更好地理解大型和復雜的編程概念。 設計模式涵蓋了從接口設計到體系結構的許多方面，甚至包括市場營銷和度量。本書主要關注使用面向對像編程方法構造開發語言。 > 軟件設計中的問題由下列3部分組成： 1. what:要考慮的相關業務和功能需求。 1. how:如何使用特定設計滿足上述需求。 1. workk：實際的實現，或者說如何投入應用和實踐。 設計模式正好對應該過程和how部分，因此本書闡述了如何解決這些問題以及成功解決問題所需的部分實現工作。可以將php描繪為解決問題所彩用的載體。一旦知道了軟件需要完成的功能，就能夠設計如何完成這些功能，從而通過更少的重構更容易地實現所有功能 我們已經提到，本書的重點并不是對php語言的掌握以及對期復雜性的理解，而是在于描述通用的、經過時間檢驗的一系列方法及其與php的聯系。 從前面的示例中可以看出，模式當然是從軟件開發階段開始的。不過，如果搖籃有涉及現有模式的完整資料，那么就能夠更快地計劃體系結構和做出更好的選擇。此外來自不同軟件領域的編程人員能夠識別該模式，并具只需將期改寫為特定的語言類型。應用程序應采用一組清晰的模式，這有于團隊新成員理解項目，從而避免浪費太多時間 ## 1.1.3設計模式無處不在 我們已經介紹過，Steve的團隊能夠理解期軟件中的基本模式以及創建可重用項，現在我們也能夠進行自己的軟件一切，有多少次使用自己的有類創建相同的用戶登錄和身份驗證系統？是否在希望的位置使用了db()函數？這些都是如何使用模式的示例。 在偏愛PEAR或其他架構庫中，能夠發現更詳細的和更接近于基礎模式的示例。例如，使用PEAR DB是應用設計模式（特是工廠方法的示例）。zend framework也會使用各種不同模式（如單無素模式和適配器模式）。 ## 1.14設計模式的公共部分 為了描述設計模式，“四人組”首先提出了一個文檔標準，并且在著作中將該文檔標準應用于所介紹的每種模式。“四人組”之后PHP相關書箱的甩有作者都復制了這種嚴格的格式，并且不斷地普及該文檔形式。因為我覺得這方面的相關介紹非常多，并且只是結構問題，所以本書不會再做過多描述。這里只是簡單介紹改線 個模式的文檔的四個主要部分： 1. 名稱 2. 問題與解決方案 3. 統一建模語言（Unified Modeling Language,UML）圖以及代碼示例 1.名稱 在設計模式中，名稱實際上比您最初想像的更重要。對于向項目和其他模式解釋特定模式的行業和關系來說，適當的描述性命名約定大有幫助。 在本單的示例中，我們注意到Jason向Steve提及自己準備重寫支付處理系統的一部分代碼。余糧高級編程人員，Steve也許不會認可Jason采用的言法，但是無疑會建議在重寫代碼體系機構中使用某些模式。因此，整個團隊都必須了解支付系弘的基礎概念，而Jason要負責具體的實現。 2.問題與解決方案 本單前面曾經介紹過，設計模式是為了使用通用的解決方案來解決相同的問題而出現的。這部分說明覆蓋了項目中的主要問題或各種問題，并且表明為何特定的設計模式是其中一個較好的解決方案。 讀者也許注意到，本書并沒有使用“最佳解決方案”的說法，其原因在于沒有人能夠給出這樣的結論。即命名您發現所選擇的設計模工是最適合于特定的問題，但是為了更理想地將期應用于具體的項目，您仍需要準備進行一定的改進工作。 3.UML圖 UML圖說明了設計模式的通用結構。在某些情況下，為了說明設計模式的其他實現或者以更易于理解的分段形式闡明復雜的概念，可能需要生成多個UML圖。 > 什么是UML > > 統一建模語言（Unified Modeling Language,UML）圖應當是編程工具庫中的主要組成部分。UML是對操作、對像和用例進行圖形編程的標準方式。在使用PHP構建復雜的軟件時，UML圖有助于清楚地表達您的設計。要最快地了解UML的最新信息，讀者可以訪問Wikipedia站點上的http://wikipedia.org/wiki/Unified_Modeling_Language 頁面。 讀者可能注意到，我們能夠寬松地根據通用模式圖給出用于為具體項目生成UML圖的構建塊。當然，與救命相對，方法名、類名和屬性是多樣公的，并且更加復雜。 4.代碼示例 具有實際經驗的PHP編程人員非常喜歡設計模式的最后一個主要部分：代碼示例。這些相對簡單的救命傷腦筋PHP代碼表達設計模式的根念。本書介紹基于PHP的設計模式，其優點在于不必了解采用其他語言編寫的模式示例 。側重于企業級設計模式的其他書籍都是采用由Java或C語言編寫的示例，對于使用單一語言的編程人員來說，示例效果稍有影響。 本書會不斷地重申：代碼示例只是例子，他們不能即插即用。代碼示例可能不包含錯誤日志 記錄或處理、審計或完全安全的編程技術。這并非表明我不欣賞高質量的、全安的編程（之前與我同一團隊的編程人員可以證明我是一個注重細節的人），而是代碼示例可以很好地說明我解釋的概念。