还在埋头敲代码？不妨学学设计模式，必能让你工作事半功倍

设计模式在开发中占很重要的地位；在大型项目中使用好设计模式往往会取得事半功倍的效果；下面就介绍下几种在开发中常用到的设计模式

装饰者模式(Decorator Pattern)

装饰者模式是在不必改变原类文件和使用继承的情况下，动态地扩展一个对象的功能；它是通过创建一个包装对象，也就是装饰来包裹真实的对象

特点

装饰对象和真实对象有相同的接口；这样客户端对象就能以和真实对象相同的方式和装饰对象交互
装饰对象包含一个真实对象的引用(reference)
装饰对象接受所有来自客户端的请求；它把这些请求转发给真实的对象。
装饰对象可以在转发这些请求以前或以后增加一些附加功能；这样就确保了在运行时，不用修改给定对象的结构就可以在外部增加附加的功能；在面向对象的设计中，通常是通过继承来实现对给定类的功能扩展

何时使用

需要扩展一个类的功能，或给一个类添加附加职责
需要动态的给一个对象添加功能，这些功能可以再动态的撤销
需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变的不现实
当不能采用生成子类的方法进行扩充时；一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类

优点

Decorator 模式与继承关系的目的都是要扩展对象的功能，但是 Decorator 可以提供比继承更多的灵活性
通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合

缺点

这种比继承更加灵活机动的特性，也同时意味着更加多的复杂性
装饰模式会导致设计中出现许多小类，如果过度使用，会使程序变得很复杂
装饰模式是针对抽象组件(Component)类型编程；但是，如果你要针对具体组件编程时，就应该重新思考你的应用架构，以及装饰者是否合适；当然也可以改变 Component 接口，增加新的公开的行为，实现 “半透明” 的装饰者模式；在实际项目中要做出最佳选择

单例模式

单例模式是我们在开发种经常使用到的一种设计模式；单例模式创建的类在当前进程种只有一个实例，并有一个访问它的全局入口

优点

内存中只有一个对象实例，节省了内存空间
避免了频繁创建实例带来的性能消耗
提供了一种全局访问入口，例如读取配置信息

缺点

一般静态类不提供接口实现、抽象方法等功能，扩展能力差，修改的话只能在这个单例类里面进行
由于静态模式使用了 static 全局变量，所以涉及生命周期的引用，这样很容易引起内存泄露，例如： 传入了一个Activity类，这个时候我们需要传入的是跟static生命周期一样长的Application Context，否则就不要使用单例模式，例如Dialog对话就不要使用单例模式。

适用场景

对象需要保存一些状态信息
避免多重读写操作；例如： 多个实例读取了同一资源文件，后续涉及对这个资源文件写入同步的操作

单例模式实现

//单例模式的实现很多中，这里展示一种最常用的实现。代码如下：
public class SingletonDemo {private static volatile SingletonDemo sInstance = null;private SingletonDemo(){}public static SingletonDemo getInstance(){if(sInstance == null){synchronized (SingletonDemo.class){if(sInstance == null){sInstance = new SingletonDemo();}}}return sInstance;}public void  printSomething(){System.out.println("this is a singleton");}
}

这种写法的好处有以下几点：

构造函数 private，不能直接 new 对象，保证通过 getInstance 方法来创建
由于不能直接 new 对象，所以 getInstance 方法必须是一个 static 方法；而静态方法不能访问非静态成员变量，所以这个实例变量也必须是 static 的
双重检查锁，使用volatile关键字，重排序被禁止，所有的写操作都将发生在读操作之前；适合于一写多读的场景(即一个线程进行写操作，多个线程进行读操作)

//使用静态内部类的方式实现
public class Singleton{private Singleton(){}public static Singleton getInstance(){return SingletonHolder.sInstance;}private static class SingletonHolder{//该类之所以是static是因为sInstance是静态的，如果不设为静态会报错private static final Singleton sInstance=new Singleton();//重点在于确定是哪个类的单例}public void printSomething(){System.out.println("this is a singleton");}
}

策略模式

定义： 策略模式定义了一系列算法，并将每一个算法封装起来，而且使他们可以相互替换，策略模式让算法独立于使用的客户而独立改变

最常见的就是关于出行旅游的策略模式，出行方式有很多种，自行车，汽车，飞机，火车等，如果不使用任何模式，代码是这样子的

publicclassTravelStrategy{enumStrategy{WALK,PLANE,SUBWAY}privateStrategystrategy;publicTravelStrategy(Strategystrategy){this.strategy=strategy;}publicvoidtravel(){if(strategy==Strategy.WALK){print("walk");}elseif(strategy==Strategy.PLANE){print("plane");}elseif(strategy==Strategy.SUBWAY){print("subway");}}publicvoidprint(Stringstr){System.out.println("出行旅游的方式为："+str);}publicstaticvoidmain(String[]args){TravelStrategywalk=newTravelStrategy(Strategy.WALK);walk.travel();TravelStrategyplane=newTravelStrategy(Strategy.PLANE);plane.travel();TravelStrategysubway=newTravelStrategy(Strategy.SUBWAY);subway.travel();}

很明显，如果需要增加出行方式就需要在增加新的 else if 语句，那么如何用策略模式来解决这个问题

首先，定义一个策略的接口

publicinterfaceStrategy{voidtravel();}

然后根据不同的出行方法来实现该接口

publicclassWalkStrategyimplementsStrategy{@Overridepublicvoidtravel(){System.out.println("walk");}}publicclassPlaneStrategyimplementsStrategy{@Overridepublicvoidtravel(){System.out.println("plane");}}publicclassSubwayStrategyimplementsStrategy{@Overridepublicvoidtravel(){System.out.println("subway");}

此外还需要一个包装策略的类，来调用策略中的接口

publicclassTravelContext{Strategystrategy;publicStrategygetStrategy(){returnstrategy;}publicvoidsetStrategy(Strategystrategy){this.strategy=strategy;}publicvoidtravel(){if(strategy!=null){strategy.travel();}}

测试一下代码：

publicclassMain{publicstaticvoidmain(String[]args){TravelContexttravelContext=newTravelContext();travelContext.setStrategy(newPlaneStrategy());travelContext.travel();travelContext.setStrategy(newWalkStrategy());travelContext.travel();travelContext.setStrategy(newSubwayStrategy());travelContext.travel();}}

以后如果再增加什么别的出行方式，就再继承策略接口即可，完全不需要修改现有的类

策略模式的优点

定义一系列算法： 策略模式的功能就是定义一系列算法，实现让这些算法可以相互替换；所以会为这一系列算法定义公共的接口，以约束一系列算法要实现的功能；如果这一系列算法具有公共功能，可以把策略接口实现成为抽象类，把这些公共功能实现到父类里面
避免多重条件语句： 根据前面的示例会发现，策略模式的一系列策略算法是平等的，可以互换的，写在一起就是通过 if-else 结构来组织，如果此时具体的算法实现里面又有条件语句，就构成了多重条件语句，使用策略模式能避免这样的多重条件语句
更好的扩展性： 在策略模式中扩展新的策略实现非常容易，只要增加新的策略实现类，然后在选择使用策略的地方选择使用这个新的策略实现就好了

策略模式的缺点

客户必须了解每种策略的不同： 比如让客户端来选择具体使用哪一个策略，这就可能会让客户需要了解所有的策略，还要了解各种策略的功能和不同，这样才能做出正确的选择，而且这样也暴露了策略的具体实现
增加了对象数目： 由于策略模式把每个具体的策略实现都单独封装成为类，如果备选的策略很多的话，那么对象的数目就会很可观
只适合扁平的算法结构： 策略模式的一系列算法地位是平等的，是可以相互替换的，事实上构成了一个扁平的算法结构，也就是在一个策略接口下，有多个平等的策略算法，就相当于兄弟算法；而且在运行时刻只有一个算法被使用，这就限制了算法使用的层级，使用的时候不能嵌套使用

小结

以上就是对 Android 开发中常用的装饰者模式、单例模式、策略模式的认识；有需要了解更多设计模式的小伙伴，可以私信发送 “进阶” 即可 免费领取一份 Android 全套进阶技术知识学习文档+大厂面试真题及答案解析 PDF 文档，助你更快的掌握 Android 相关的技术知识