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

　　设计模式在开发中占很重要的地位 ；在 大型项目 中使用好 设计模式 往往会取得 事半功倍 的 效果 ；下面就介绍下几种 在开发中常用到的设计模式 装饰者模式(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%免费 ， 最后大家如果觉得手册内容有用的话，可以点赞分享一下哦~