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设计中抽象工厂的动机是什么”这篇文章的所有内容，感谢各位的阅读！相信大家阅读完这篇文章都有很大的收获，小编每天都会为大家更新不同的知识，如果还想学习更多的知识，请关注亿速云行业资讯频道。