ANDROID 中设计模式的采用.doc

ANDROID 中设计模式的采用-行为模式1 职责链模式 职责链模式的意图为:使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。职责链模式的结构图如下： 在ANDROID的输入管理系统中提交输入事件到视图时使用了职责链模式,其类图所示:类图中的ViewRootImpl类的内部类EarlyPostImeInputStage、NativePostImeInputStage、ViewPostImeInputStage、SyntheticInputStage构成一个输入事件责任处理链，用来分阶段处理输入事件，如果本阶段对事件没有处理，则传递到下一个对象进行处理，直至事件被处理。2、命令模式命令模式的意图为：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。命令模式的结构图如下：在ANDROID系统中命令模式用的也比较多，如在事件输入系统中，在InputDispatcher对象转发事件过程中就采用了命令模式：把每一个输入事件封装为类型为NotifyArgs的对象，不同的事件对应NotifyArgs类的不同子类，如按键事件对应NotifyKeyArgs类，触摸事件对应NotifyMotionArgs类，而NotifyArgs命令的接收对象为InputDispatcher，因此通过事件命令的执行把事件本身转发给InputDispatcher对象，实现事件的提交。相关模式类图如下：3 解释器模式 解释器模式的意图为：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。解释器模式的结构图如下： 在android系统中，包管理服务对应用包的解析使用了解释器模式。 包管理服务采用PackageParser类来负责应用包的解析，PackageParser类使用了解释器模式对一个应用包进行解释，对于应用包中的每种语法结构都创建了对应的类，来分别搜集应用包中的相应信息。类结构图如下：图中除了Resources及XmlPullParser两个类外其余的类都是PackageParser类的内部类，应用包中的每个语法结构对应的类都派生自componet类且属于componet类的内部成员，Package类（一个包一个Package对象）是一个聚合类，用来把解析出来的一个应用包中的componet信息聚合到Package类中进行统一管理，PackageParser类将解析出的每个componet信息添加到Package中。4 、迭代器模式 迭代器模式的意图为：提供一种方法顺序访问一个聚合对象中各个元素,而又不需暴露该对象的内部表示。迭代器模式的结构图如下：迭代器模式是个普遍使用的模式，JAVA的集合类库（列表，集合,映射、字典,有序集,字符串等）都以不同的形式提供了迭代器，用来对集合类中的元素进行遍历。5、中介者模式 中介者模式的意图为：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。中介者模式的结构图如下：在ANDROID系统中keyguard的功能实现采用了中介者模式，用来中介keyguard相关的请求，包括查询keyguard的状态，影响keyguard应当显示和复位的电源管理事件，以及当keyguard显示时对窗口管理的通知事件和来自keyguard视图本身的关于keyguard是否成功unlocked的事件等。相关UML类图如下：其中KeyguardViewMediator作为中介者角色，与电源管理、用户管理、报警管理、声音管理、状态条管理、KeyguardViewManager、KeyguardDisplayManager、KeyguardUpdateMonitor等服务或对象交互， 读取相关状态，执行和触发keyguard事件相关的功能等 ，而KeyguardViewManager、KeyguardHostView、KeyguardUpdateMonitor类通过相关回调向KeyguardViewMediator传送Keyguard视图本身和keyguard有关状态更新方面的事件， 另外KeyguardService服务也是通过KeyguardViewMediator查询keyguard的状态 并通过IKeyguardService接口对外提供keyguard的状态信息。6 备忘录模式备忘录模式的意图为：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。备忘录模式的结构图如下： 在ANDROID系统中有不少采用备忘录模式的例子，如ACTIVITY活动状态的保存和恢复就是采用备忘录模式的一个例子。 在一个活动暂停或停止时调用活动的onSaveInstanceState(Bundle outState)函数把ACTIVITY的当前状态保存到Bundle对象中，活动恢复或重新启动时调用活动的onRestoreInstanceState(Bundle savedInstanceState)函数恢复到原先状态。7、观察者模式 观察者模式的意图为：定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。观察者模式的结构图如下：观察者模式也称发布订阅者模式，可以实现目标和多个观察者间的松散耦合，并支持广播通信，是最常用的设计模式之一。 在ANDROID系统中观察者模式也是普遍采用，观察者模式提供了ANDROD架构连接件的基础，在系统提供的广播组件及内容提供者组件、通知服务中以及视图控件和底层事件监听、UI事件输入等许多方面普遍采用。 观察者模式也是MVC模式的实现基础，M VC中的M o d e l类担任目标的角色,而Vi e w担任观察者的角色。8、状态模式 状态模式的意图为：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。状态模式的结构图如下： 状态模式在ANDROID系统中用的也比较多，尤其在数据连接、WIFI、蓝牙等网络连接和状态管理方面。 如在WIFI管理方面，就提供了WifiStateMachine、P2pStateMachine、WifiController、WifiApConfigStore、WifiWatchdogStateMachine五个状态机来管理WIFI相关功能的不同状态。每个状态机对象在状态模式中起到Context作用，用来汇聚相关状态，启动状态执行等。 ANDROID系统中每个状态机管理的状态都派生自State类，State类是IState接口的实现。 WifiApConfigStore管理的状态图如下：9、策略模式 策略模式的意图为：定义一系列的算法,把它们一个个封装起来,并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。策略模式的结构图如下：策略模式也是经常使用的模式，在ANDROID系统的几乎每个子系统中都有策略模式使用的影子,如窗口管理服务中提供窗口管理相关策略的WindowManagerPolicy接口对象；输入管理系统中提供输入事件读取和提交策略的InputReaderPolicyInterface和PointerControllerPolicyInterface接口对象,以及输入事件映射算法等；声音相关服务中提供声音输入和输出配置和激活策略的AudioPolicyInterface接口对象；网络管理相关服务中提供网络统计匹配策略的NetworkPolicy对象等。10、模板方法模式 模板方法模式的意图为：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Te m p l a t e M et h o d使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。模板方法模式的结构图如下：模板方法模式和观察者模式一样也是最常用的设计模式之一，模板方法非常基本，几乎可以在任何一个抽象类中找到。工厂方法也是采用模板模式创建对象的特例。 在ANDROID系统中模板方法模式更是作为整个系统框架的基础和核心，为应用程序组件运行（包括ACTIVITY、SERVICE、Broadcastreceiver）提供了大的运行骨架，应用程序只需在应用组件的派生类中重新实现钩子函数(模板方法)，即可以实现应用程序的客制化功能，这样既可以实现多样化的应用,又能够使应用程序开发遵循同样的框架API。11、访问者模式 访问者模式的意图为：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。访问者模式的结构图如下： 访问者模式在ANDROID系统中也有使用，如输入管理服务中在调用getKeyboardLayout(String keyboardLayoutDescriptor)函数来获得键盘布局时，就使用了访问者模式。getKeyboardLayout函数调用visitKeyboardLayout(StringkeyboardLayoutDescriptor,KeyboardLayoutVisitor visitor)函数通过包管理服务来查询每个包，在应用包中发现keyboard-layout元素时， 就调用访问者的visitKeyboardLayout函数来根据发现的keyboard-layout元素创建一个KeyboardLayout键盘布局对象。ANDROID 中设计模式的采用-结构型模式 结构型模式中的适配器模式、外观模式、装饰模式、代理模式都属于包装模式，都是对另外的类或对象的包装，只是各自的意图不同。 适配器模式通过对另外的类或对象的包装，将其接口转换为用户期望的接口，达到接口适配的目的。 外观模式是对包装的一组类或对象提供一个高层接口，意图是简化接口，使系统更加容易使用。 装饰模式的意图是在不改变包装对象接口的情况下为其增加另外的功能或职责。 代理模式的意图是通过对包装对象的包装以便控制对包装对象的访问。 适配器模式、外观模式对客户提供的接口与其包装类的接口有所不同，也就是这两种模式对客户来说改变了包装类的访问接口。而装饰模式、代理模式对外不改变所包装类的接口，对客户提供的接口与包装类的接口相同。1、适配器模式 适配器模式包括两种：类适配器模式和对象适配器模式，一种使用了继承方式，一种使用了对象组合方式，相关的UML类图如下：Android系统中适配器模式大量采用，由于ANDROID采用的是JAVA语言，而JAVA语言不支持多继承，因此在系统中采用的适配器模式主要是第二种，用来把包装对象的接口转换为需要的接口。 在Android系统中最常用的采用适配器模式的类为继承于BaseAdapter的类，如ArrayAdapter、CursorAdapter等，用来在底层数据和AdapterView视图之间提供适配，把对底层数据的读取接口转换为视图需要的接口。类图如下：继承于AdapterView的视图(Client)通过Adapter(Target)的接口函数获得视图需要的数据，如Adapter接口函数getItem(int position)从底层数据集获得位置position的数据项，getCount()函数获得数据集中的数据项的个数。 Adapter的具体类完成与不同底层数据类型读取接口的适配，如CursorAdapter类通过Cursor对象读取底层数据库中的数据，ArrayAdapter用来读取任意类型列表数组中的数据，HistoryAdapter用来读取类型为HistoryEntry的向量中的数据。其它采用适配器模式的还有显示服务中DisplayAdapter类以及打印服务中的PrintDocumentAdapter类。DisplayAdapter用来适配不同类型的显示设备，用来侦测和发现系统连接的不同类型的设备。PrintDocumentAdapter用来适配不同的打印输出目标设备，如打印机或者文件，用来在这些设备输出打印内容。2 、外观模式外观模式的类图如下：在Android系统中使用的外观模式的地方比较多，可以说每个系统服务都对客户提供了一个访问该系统服务的管理门户类，用来方便访问对应的系统服务，如窗口管理服务对应的WindowManager，输入管理服务对应的InputManager，活动管理服务对应的ActivityManager等等。 另外ContentResolver、Log、Context、ServiceManager也可以看作门户模式的采用。 ContentResolver用来为应用提供访问数据模式的公共接口，Log为应用提供使用log输出系统的公共接口，Context为应用提供访问整个系统的接口。ServiceManager提供访问其它系统服务的入口。3、装饰模式 装饰模式的类图如下： 在Android系统中也有不少使用装饰模式的例子。如ContextThemeWrapper类及其派生类Activity和Service。UML类图如下： ContextWrapper是对ContextImpl类的包装,Service类和Activity类都是ContextWrapper的派生类,Service类直接派生自ContextWrapper，Activity间接派生自ContextWrapper的子类ContextThemeWrapper，Service类和Activity类分别在ContextWrapper和ContextThemeWrapper类的接口基础上添加和实现了各自的生命周期回调接口（钩子），Activity类还提供了与其相关的窗口和视图显示相关的功能。ContextThemeWrappe的功能是在ContextWrapper基础上添加了对主题（Theme）的支持及在通过getSystemService接口返回服务管理对象时对于LAYOUT_INFLATER_SERVICE服务做了特殊处理，采用原形模式返回一个LayoutInflater对象的克隆对象。4 、代理模式 代理模式的类图如下：在Android系统中代理模式也是普遍采用，每一个系统服务和本地服务都对应一个远端代理类，用来实现跨进程的访问系统服务或本地服务。每一个系统服务为一个Stub对象，而客户端通过一个Proxy对象访问对应的Stub对象。如管理管理服务对应的类图如下： WindowManagerGlobal作为客户通过继承于接口IWindowManager的一个代理对象IWindowManager.Stub.Proxy跨进程访问系统服务WindowManagerService。5 、桥接模式 桥接模式的意图为：将抽象部分与它的实现部分分离，使它们都可以独立地变化。这里的抽象和实现指的不是类的抽象和实现，而可以理解为功能抽象（或界面）和功能实现。任何具有实现关系的两个独立演化派生的类之间都可以构成桥接模式，桥接模式主要用在需要跨越多个平台的图形和窗口系统上。如所有介绍桥接模式的书中几乎都是以不同特性的窗口与窗口功能的实现，不同的视图（或图形）与视图（或图形）的绘制作为采用桥接模式的例子。如下为桥接模式的类图结构： 同样在ANDROID系统中不同的视图构成的视图树与完成视图的绘制功能的类之间，以及窗口类与窗口的功能实现类之间也可以认为采用的是桥接模式。相关类图如下：图中不同的视图如Button、ImageView、TextView构成了一个抽象派生层次视图树，在视图树中View是所有视图的根视图，View的绘制通过三个不同的能独立演化的类来实现：Canvas（提供绘制表面）、HardwareLayer（提供输出显示层）、DisplayList（代表一个绘制操作）。 如下为ANDROID系统中窗口与窗口实现类之间的类图。Window、PhoneWindow构成窗口的抽象部分，Window是抽象部分的抽象接口，Window目前只提供了一个具体类PhoneWindow，Window的实现部分相关的类也构成了一个派生类图，WindowManager为窗口实现部分的基类，WindowManagerImpl为WindowManager的具体类，WindowManagerImpl通过WindowManagerGlobal并通过IWindowManager接口与窗口管理服务WindowManagerService交互，由窗口管理服务完成实际的窗口管理功能。 桥接与适配器两个模式非常类似，只是使用场合和观察角度不同。 在GOF所著的设计模式经典著作中对桥接模式与适配器模式的区别描述为：B r i d g e模式的结构与对象适配器类似，两个模式的不同之处主要在于它们各自的用途和出发点：B r i d g e目的是将接口部分和实现部分分离和桥接，从而对它们可以较为容易也相对独立的加以改变和演化，B r i d g e模式能够为用户提供一个稳定的抽象和其实现接口。而A d a p t e r模式通过改变一个已有对象的接口，用来解决两个已有接口之间的不匹配，帮助实现不兼容的类之间协同工作，A d a p t e r模式不考虑这些接口是怎样实现的，也不对其重新设计，也不考虑它们各自可能会如何演化。因此A d a p t e r通常在系统设计完成后使用，而B r i d g e模式必须事先知道一个抽象将有多个实现部分，因此在系统开始时就被使用。 因此从上面的描述可以看出：对一个采用桥接或适配器模式的已经完成的代码，从不同的观察角度可以看作桥接模式，也可以看作适配器模式。6 、组合模式 组合模式的意图为：将对象组合成树形结构以表示“部分-整体”的层次结构。C o m p o s i t e使得用户对单个对象和组合对象的使用具有一致性。如下为类图结构：采用组合模式的标准例子为图形、视图、菜单和窗口等，集合类（如数组）、文件目录也可以看作采用了组合模式。如下为ANDROID系统中采用组合模式的组合视图类图：7、享元模式享元模式的意图为运用共享技术有效地支持大量细粒度的对象，类图结构如下：享元模式也是普遍采用的模式。在ANDROID系统中，每个应用组件都可以使用系统提供的众多服务管理对象，如WallpaperManager、AccessibilityManager、CaptioningManager、AccountManager等等。因此为了在一个组件内共享这些对象，在应用组件的Context的实现ContextImpl中，在ContextImpl类第一次加载引用时为每个管理对象都创建了一个ServiceFetcher对象（采用静态代码块），并根据服务名字把新创建的ServiceFetcher对象放到MAP集合中，每个ServiceFetcher对象在登记到MAP集合中时都分配了一个索引。 应用组件在调用Context.getSystemService来获得系统服务管理对象时，首先根据服务名字从MAP集合中获得对应的ServiceFetcher对象，然后调用ServiceFetcher对象的getService函数获得ServiceFetcher对象创建的服务管理对象。 在ServiceFetcher对象的getService函数中首先从Context维护的Cache数组列表中根据ServiceFetcher对象的索引查找是否已经包含有ServiceFetcher对象创建的服务管理对象，如果在Cache中存在服务管理对象，则直接返回Cache中保存的服务管理对象，否则调用ServiceFetcher的createService函数创建一个服务管理对象，并根据其索引放置到Cache中，以便下次使用。ANDROID 中设计模式的采用-创建型模式 所谓模式就是在某一情景下解决某个问题的固定解决方案。 所有的创建型模式都是用作对象的创建或实例化的解决方案。1简单工厂模式创建对象的最简单方法是使用new来创建一个对象，如果只创建一种固定不变的对象,可以使用new来创建这个对象。如果要根据不同场景创建不同类型的对象，就可能需要采用不同的方法，就出现了不同的模式的采用和总结。如ANDROID的媒体框架中为了实现对不同媒体源的播放，就需要实现多种播放器对象，并可能需要根据支持的媒体类型的增加，不断添加播放器对象。htmlview plaincopy1. spp;2. switch(playerType)3. caseSONIVOX_PLAYER:4. ALOGV(createMidiFile);5. p=newMidiFile();6. break;7. caseSTAGEFRIGHT_PLAYER:8. ALOGV(createStagefrightPlayer);9. p=newStagefrightPlayer;10. break;11. caseNU_PLAYER:12. ALOGV(createNuPlayer);13. p=newNuPlayerDriver;14. break;15. caseTEST_PLAYER:16. ALOGV(CreateTestPlayerstub);17. p=newTestPlayerStub();18. break;19. caseAAH_RX_PLAYER:20. ALOGV(createAHRXPlayer);21. p=createAAH_RXPlayer();22. break;23. caseAAH_TX_PLAYER:24. ALOGV(createAHTXPlayer);25. p=createAAH_TXPlayer();26. break;27. #ifdefBUILD_WITH_MST28. caseMST_PLAYER:29. ALOGV(createMstPlayer);30. p=newMstPlayer;31. break;32. #endif33. default:34. ALOGE(Unknownplayertype:%d,playerType);35. returnNULL;36. 上面代码可能随着播放支持的媒体类型的添加需要不断修改，因此为了满足“开闭设计原则”（对修改封闭，对扩展开放），就要采用不同的模式实现媒体播放器对象的创建功能。一种简单的方法是把上面的代码放到一个创建播放器的函数中，这也是ANDROID4.2以前的版本采用的模式，也称为简单工厂之静态工厂模式。就如下面所示：htmlview plaincopy1. staticspcreatePlayer(player_typeplayerType,void*cookie,2. notify_callback_fnotifyFunc)3. 4. spp;5. switch(playerType)6. caseSONIVOX_PLAYER:7. ALOGV(createMidiFile);8. p=newMidiFile();9. break;10. caseSTAGEFRIGHT_PLAYER:11. ALOGV(createStagefrightPlayer);12. p=newStagefrightPlayer;13. break;14. caseNU_PLAYER:15. ALOGV(createNuPlayer);16. p=newNuPlayerDriver;17. break;18. caseTEST_PLAYER:19. ALOGV(CreateTestPlayerstub);20. p=newTestPlayerStub();21. break;22. caseAAH_RX_PLAYER:23. ALOGV(createAHRXPlayer);24. p=createAAH_RXPlayer();25. break;26. caseAAH_TX_PLAYER:27. ALOGV(createAHTXPlayer);28. p=createAAH_TXPlayer();29. break;30. #ifdefBUILD_WITH_MST31. caseMST_PLAYER:32. ALOGV(createMstPlayer);33. p=newMstPlayer;34. break;35. #endif36. default:37. ALOGE(Unknownplayertype:%d,playerType);38. returnNULL;39. 40. spp;41. switch(playerType)42. caseSONIVOX_PLAYER:43. ALOGV(createMidiFile);44. p=newMidiFile();45. break;46. caseSTAGEFRIGHT_PLAYER:47. ALOGV(createStagefrightPlayer);48. p=newStagefrightPlayer;49. break;50. caseNU_PLAYER:51. ALOGV(createNuPlayer);52. p=newNuPlayerDriver;53. break;54. caseTEST_PLAYER:55. ALOGV(CreateTestPlayerstub);56. p=newTestPlayerStub();57. break;58. caseAAH_RX_PLAYER:59. ALOGV(createAHRXPlayer);60. p=createAAH_RXPlayer();61. break;62. caseAAH_TX_PLAYER:63. ALOGV(createAHTXPlayer);64. p=createAAH_TXPlayer();65. break;66. #ifdefBUILD_WITH_MST67. caseMST_PLAYER:68. ALOGV(createMstPlayer);69. p=newMstPlayer;70. break;71. #endif72. default:73. ALOGE(Unknownplayertype:%d,playerType);74. returnNULL;75. 当然也可以把上面的创建播放器对象的代码放到一个工厂类中。ANDROID系统中的PhoneFactory类就是一个简单工厂类的采用，该类提供了makeDefaultPhones、getGsmPhone、getCdmaPhone、getDefaultPhone、makeSipPhone等工厂函数来创建和获得不同类型的Phone对象。以上的简单工厂模式虽然可以在一处修改代码，但还是不满足“开闭设计原则”，也不满足针对接口编程的设计原则，因此在功能扩展时还是需要修改相关代码。PhoneFactory工厂类还存在一个问题: 为了创建不同类型的Phone对象需要调用PhoneFactory工厂类的不同的工厂函数，虽然它们创建的Phone对象都是Phone的子类。为了解决上面的简单工厂模式的问题，就需要采用另外的两个工厂模式：工厂方法和抽象工厂,一个采用了类继承的方式,一个采用了对象组合的方式。2工厂模式之工厂方法工厂方法模式通过在要创建对象的共同父类中定义一个公共抽象接口来返回具体类创建的对象，该接口返回的具体对象实际在具体类的实现公共抽象接口的创建函数中创建。意图：在抽象类定义一个用于创建对象的接口，让具体类创建具体的对象。工厂方法的UML结构类图为：在ANDROID系统的媒体路由框架中的MediaRouteProvider类就是工厂方法模式的采用。抽象类MediaRouteProvider中提供了一个创建RouteController对象的公共接口onCreateRouteController，用来返回一个MediaRouteProvider.RouteController对象，MediaRouteProvider.RouteController的具体对象实际由MediaRouteProvider的具体派生类在其onCreateRouteController函数中负责创建，如MediaRouteProvider的派生类RegisteredMediaRouteProvider在其onCreateRouteController函数中创建了一个具体类型为RegisteredMediaRouteProvider.Controller的MediaRouteProvider.RouteController对象，MediaRouteProvider的间接派生类SystemMediaRouteProvider.LegacyImpl和SystemMediaRouteProvider.JellybeanImpl在各自的onCreateRouteController函数中分别创建了派生于MediaRouteProvider.RouteController的两个具体对象：SystemMediaRouteProvider.DefaultRouteController和SystemMediaRouteProvider.SystemRouteController。3工厂模式之抽象工厂抽象工厂模式是通过实现一个派生于抽象工厂的具体工厂来负责创建具体的产品或产品系列。抽象工厂模式可以通过实现不同的具体工厂来创建不同的产品或系列，也可以通过具体工厂的不同方法来创建不同的产品。而用户只与抽象工厂打交道，而不关心哪个工厂创建了具体产品。抽象工厂模式的意图是提供一个创建一系列相关或依赖的对象的接口，用户可以通过该接口创建一系列相关的对象。在最新版本的ANDROID系统中的媒体框架中上面的媒体播放器的创建就采用了抽象工厂模式。类图如下：其中MediaPlayerFactory为MediaPlayerFactory:IFactory的客户，MediaPlayerFactory通过其包含的抽象工厂MediaPlayerFactory:IFactory的抽象接口createPlayer来创建不同的播放器，每种具体的播放器由每一个具体的工厂来负责创建，如StagefrightPlayer播放器由StagefrightPlayerFactory工厂创建，NuPlayerFactory工厂创建NuPlayerDriver播放器，SonivoxPlayerFactory工厂创建MidiFile播放器，TestPlayerFactory工厂创建用于测试的播放器TestPlayerStub。在MediaPlayerFactory类中每种具体的播放器工厂需要采用MediaPlayerFactory的registerFactory_l或registerFactory函数登记到MediaPlayerFactory类中，以便MediaPlayerFactory类在其工厂方法中能够根据不同的播放类型获得具体的播放工厂来创建具体类型的播放器。抽象工厂与工厂方法模式的关键区别是：抽象工厂需要创建派生自抽象工厂的具体的工厂，通过具体工厂对象的实例方法来创建具体的产品,工厂对象的责任就是创建具体的产品；而工厂方法模式是提供一个框架，产品的创建是通过要创建产品的子类中的一个工厂方法来完成,创建产品只是子类的诸多责任中的一项任务。4生成器有时对象的创建需要采用分步骤来完成，这时就可以采用生成器模式，UML类图如下：在ANDROID系统中也存在大量的生成器模式的采用。如AlertDialog、Uri、Notification等对象的创建。如下是AlertDialog对象的创建例子。htmlview plaincopy1. AlertDialogdialog=newAlertDialog.Builder(mContext)2. .setTitle(r.getString(R.string.wifi_p2p_invitation_sent_title)3. .setView(textEntryView)4. .setPositiveButton(r.getString(R.string.ok),null)5. .creat