从Android举例说说设计模式#

AlertDialog、Notification源码中使用了Bulider（建造者）模式完成参数的初始化：#

在AlertDialog的Builder模式中并没有看到Direcotr角色的出现，其实在很多场景中，Android并没有完全按照GOF的经典设计模式来实现，而是做了一些修改，使得这个模式更易于使用。这个的AlertDialog.Builder同时扮演了上下文中提到的builder、ConcreteBuilder、Director的角色，简化了Builder模式的设计。当模块比较稳定，不存在一些变化时，可以在经典模式实现的基础上做出一些精简，而不是照搬GOF上的经典实现，更不要生搬硬套，使程序失去架构之美。

定义：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。即将配置从目标类中隔离出来，避免过多的setter方法。

优点：

• 1、良好的封装性，使用建造者模式可以使客户端不必知道产品内部组成的细节。
• 2、建造者独立，容易扩展。

缺点：

• 会产生多余的Builder对象以及Director对象，消耗内存。

Okhttp内部使用了责任链模式来完成每个Interceptor拦截器的调用：#

定义：使多个对象都有机会处理请求，从而避免了请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。

ViewGroup事件传递的递归调用就类似一条责任链，一旦其寻找到责任者，那么将由责任者持有并消费掉该次事件，具体体现在View的onTouchEvent方法中返回值的设置，如果onTouchEvent返回false，那么意味着当前View不会是该次事件的责任人，将不会对其持有；如果为true则相反，此时View会持有该事件并不再向下传递。

• 优点：

将请求者和处理者关系解耦，提供代码的灵活性。

• 缺点：

对链中请求处理者的遍历中，如果处理者太多，那么遍历必定会影响性能，特别是在一些递归调用中，要慎重。

RxJava的观察者模式：#

定义：定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。

ListView/RecyclerView的Adapter的notifyDataSetChanged方法、广播、事件总线机制。

观察者模式主要的作用就是对象解耦，将观察者与被观察者完全隔离，只依赖于Observer和Observable抽象。

优点：

• 观察者和被观察者之间是抽象耦合，应对业务变化。
• 增强系统灵活性、可扩展性。

缺点：

• 在Java中消息的通知默认是顺序执行，一个观察者卡顿，会影响整体的执行效率，在这种情况下，一般考虑采用异步的方式。

AIDL代理模式：#

定义：为其他对象提供一种代理以控制对这个对象的访问。

静态代理：代码运行前代理类的class编译文件就已经存在。

动态代理：通过反射动态地生成代理者的对象。代理谁将会在执行阶段决定。将原来代理类所做的工作由InvocationHandler来处理。

使用场景：

• 当无法或不想直接访问某个对象或访问某个对象存在困难时可以通过一个代理对象来间接访问，为了保证客户端使用的透明性，委托对象与代理对象需要实现相同的接口。

缺点：

• 对类的增加。

ListView/RecyclerView/GridView的适配器模式：#

适配器模式把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。

使用场景：

• 接口不兼容。
• 想要建立一个可以重复使用的类。
• 需要一个统一的输出接口，而输入端的类型不可预知。

优点：

• 更好的复用性：复用现有的功能。
• 更好的扩展性：扩展现有的功能。

缺点：

• 过多地使用适配器，会让系统非常零乱，不易于整体把握。例如，明明看到调用的是A接口，其实内部被适配成了B接口的实现，一个系统如果出现太多这种情况，无异于一场灾难。

Context/ContextImpl外观模式：#

要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行，门面模式提供一个高层次的接口，使得子系统更易于使用。

使用场景：

• 为一个复杂子系统提供一个简单接口。

优点：

• 对客户程序隐藏子系统细节，因而减少了客户对于子系统的耦合，能够拥抱变化。
• 外观类对子系统的接口封装，使得系统更易用使用。

缺点：

• 外观类接口膨胀。
• 外观类没有遵循开闭原则，当业务出现变更时，可能需要直接修改外观类。