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

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

装饰者模式(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{

@Override

publicvoidtravel(){

System.out.println("walk");

}

}publicclassPlaneStrategyimplementsStrategy{

@Override

publicvoidtravel(){

System.out.println("plane");

}

}publicclassSubwayStrategyimplementsStrategy{

@Override

publicvoidtravel(){

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 相关的技术知识

内容展示如下：

架构设计必入技能详解

由于篇幅原因，资料就不完全展示了，以上的资料保证100%免费，最后大家如果觉得手册内容有用的话，可以点赞分享一下哦~