web設計中抽象工廠的動機是什么

今天小編給大家分享一下web設計中抽象工廠的動機是什么的相關知識點，內容詳細，邏輯清晰，相信大部分人都還太了解這方面的知識，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來了解一下吧。

抽象工廠模式的動機

考慮一個支持多種視感（ l o o k - a n d - f e e l）標準的用戶界面工具包，例如 M o t i f和Presentation Manager。不同的視感風格為諸如滾動條、窗口和按鈕等用戶界面“窗口組件”定義不同的外觀和行為。為保證視感風格標準間的可移植性，一個應用不應該為一個特定的視感外觀硬編碼它的窗口組件。在整個應用中實例化特定視感風格的窗口組件類將使得以后很難改變視感風格。

《設計模式》成書很早，所以書中會出現許多過去的軟件和技術，例如上文Moti和Presentation Manager。這里建議大家不必過分在意這些名詞，能夠理解作者意圖即可。上面的文字中忽略例如的部分也不會有任何問題，只要能找到類似的場景就好，例如Linux操作系統的主題就是一個不錯的例子。除了表示方式不同之外，動作方式也會有所不同。可以想象：如果將所有和主題相關的代碼都寫在一個類里，代碼勢必會變得很復雜，最后的結果就是得無法維護和擴展。

為解決這一問題我們可以定義一個抽象的 Wi d g e t F a c t o r y類，這個類聲明了一個用來創建每一類基本窗口組件的接口。每一類窗口組件都有一個抽象類，而具體子類則實現了窗口組件的特定視感風格。對于每一個抽象窗口組件類， Wi d g e t F a c t o r y接口都有一個返回新窗口組件對象的操作。客戶調用這些操作以獲得窗口組件實例，但客戶并不知道他們正在使用的是哪些具體類。這樣客戶就不依賴于一般的視感風格，如下頁圖所示。

每一種視感標準都對應于一個具體的 Wi d g e t F a c t o r y子類。每一子類實現那些用于創建合適視感風格的窗口組件的操作。例如， M o t i f Wi d g e t F a c t o r y的C r e a t e S c r o l l B a r操作實例化并返回一個M o t i f滾動條，而相應的P M Wi d g e t F a c t o r y操作返回一個Presentation Manager的滾動條。客戶僅通過Wi d g e t F a c t o r y接口創建窗口組件，他們并不知道哪些類實現了特定視感風格的窗口組件。換言之，客戶僅與抽象類定義的接口交互，而不使用特定的具體類的接口。

面向對象中解決這類一問題的方法只有一個，就是利用多態，首先建立各種窗口組建的抽象類，然后在每種主題中為相應的組建準備具象類。上圖中的Windows和ScrollBar就是窗口組建的抽象類，而PMWindow,MotiWindow,PMSrollBar，MotiScrollBar就是對應的具象類。

對于窗口組建的利用者Client來說，并不需要知道各個窗口組建的具象類，只有知道組件是某種Window或者某種ScrollBar即可。但是還有一個問題：Client在使用組件時雖然可以不知道組件具象類信息，但構建組件的時候無論如何也沒有辦法繼續裝糊涂。

解決這個問題想法就是將構建窗口組件的部分封裝的到一個類中。名字可以叫WidgetFacroty，它根據主題信息生成對應的窗口組件，壞事交給別人做。這就是簡單工廠模式。簡單工程模式依然不夠完美：因為當增加主題的時候，仍然需要對工廠類進行一定的修改。

終于到了主角出場的時候了。

這里繼續請出面向對象的絕招：多態。我們可以準備一個工廠的抽象類，然后為每種主題準備具象類。每種具象工廠類負責生成對應主題的窗口組件。在需要更換主題時，更換具象工廠類即可。

Wi d g e t F a c t o r y也增強了具體窗口組件類之間依賴關系。一個 M o t i f的滾動條應該與M o t i f按鈕、M o t i f正文編輯器一起使用，這一約束條件作為使用 M o t i f Wi d g e t F a c t o r y的結果被自動加上。

Client得到窗口組件的方式只有通過指定的具象工廠類一種方式，這樣就從結果上決定了哪些具象窗口組建類一起協同工作。

以上就是“web設計中抽象工廠的動機是什么”這篇文章的所有內容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，小編每天都會為大家更新不同的知識，如果還想學習更多的知識，請關注億速云行業資訊頻道。