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

　　设计模式在开发中占很重要的地位；在大型项目中使用好设计模式往往会取得事半功倍的效果；下面就介绍下几种在开发中常用到的设计模式装饰者模式（DecoratorPattern）
　　装饰者模式是在不必改变原类文件和使用继承的情况下，动态地扩展一个对象的功能；它是通过创建一个包装对象，也就是装饰来包裹真实的对象特点装饰对象和真实对象有相同的接口；这样客户端对象就能以和真实对象相同的方式和装饰对象交互装饰对象包含一个真实对象的引用（reference）装饰对象接受所有来自客户端的请求；它把这些请求转发给真实的对象。装饰对象可以在转发这些请求以前或以后增加一些附加功能；这样就确保了在运行时，不用修改给定对象的结构就可以在外部增加附加的功能；在面向对象的设计中，通常是通过继承来实现对给定类的功能扩展何时使用需要扩展一个类的功能，或给一个类添加附加职责需要动态的给一个对象添加功能，这些功能可以再动态的撤销需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变的不现实当不能采用生成子类的方法进行扩充时；一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类优点Decorator模式与继承关系的目的都是要扩展对象的功能，但是Decorator可以提供比继承更多的灵活性通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合缺点这种比继承更加灵活机动的特性，也同时意味着更加多的复杂性装饰模式会导致设计中出现许多小类，如果过度使用，会使程序变得很复杂装饰模式是针对抽象组件（Component）类型编程；但是，如果你要针对具体组件编程时，就应该重新思考你的应用架构，以及装饰者是否合适；当然也可以改变Component接口，增加新的公开的行为，实现半透明的装饰者模式；在实际项目中要做出最佳选择单例模式
　　单例模式是我们在开发种经常使用到的一种设计模式；单例模式创建的类在当前进程种只有一个实例，并有一个访问它的全局入口优点内存中只有一个对象实例，节省了内存空间避免了频繁创建实例带来的性能消耗提供了一种全局访问入口，例如读取配置信息缺点一般静态类不提供接口实现、抽象方法等功能，扩展能力差，修改的话只能在这个单例类里面进行由于静态模式使用了static全局变量，所以涉及生命周期的引用，这样很容易引起内存泄露，例如：传入了一个Activity类，这个时候我们需要传入的是跟static生命周期一样长的ApplicationContext，否则就不要使用单例模式，例如Dialog对话就不要使用单例模式。适用场景对象需要保存一些状态信息避免多重读写操作；例如：多个实例读取了同一资源文件，后续涉及对这个资源文件写入同步的操作单例模式实现单例模式的实现很多中，这里展示一种最常用的实现。代码如下：publicclassSingletonDemo｛privatestaticvolatileSingletonDemosInstancenull；privateSingletonDemo（）｛｝publicstaticSingletonDemogetInstance（）｛if（sInstancenull）｛synchronized（SingletonDemo。class）｛if（sInstancenull）｛sInstancenewSingletonDemo（）；｝｝｝returnsInstance；｝publicvoidprintSomething（）｛System。out。println（thisisasingleton）；｝｝
　　这种写法的好处有以下几点：构造函数private，不能直接new对象，保证通过getInstance方法来创建由于不能直接new对象，所以getInstance方法必须是一个static方法；而静态方法不能访问非静态成员变量，所以这个实例变量也必须是static的双重检查锁，使用volatile关键字，重排序被禁止，所有的写操作都将发生在读操作之前；适合于一写多读的场景（即一个线程进行写操作，多个线程进行读操作）使用静态内部类的方式实现publicclassSingleton｛privateSingleton（）｛｝publicstaticSingletongetInstance（）｛returnSingletonHolder。sInstance；｝privatestaticclassSingletonHolder｛该类之所以是static是因为sInstance是静态的，如果不设为静态会报错privatestaticfinalSingletonsInstancenewSingleton（）；重点在于确定是哪个类的单例｝publicvoidprintSomething（）｛System。out。println（thisisasingleton）；｝｝策略模式
　　定义：策略模式定义了一系列算法，并将每一个算法封装起来，而且使他们可以相互替换，策略模式让算法独立于使用的客户而独立改变
　　最常见的就是关于出行旅游的策略模式，出行方式有很多种，自行车，汽车，飞机，火车等，如果不使用任何模式，代码是这样子的publicclassTravelStrategy｛enumStrategy｛WALK，PLANE，SUBWAY｝privateStrategystrategy；publicTravelStrategy（Strategystrategy）｛this。strategystrategy；｝publicvoidtravel（）｛if（strategyStrategy。WALK）｛print（walk）；｝elseif（strategyStrategy。PLANE）｛print（plane）；｝elseif（strategyStrategy。SUBWAY）｛print（subway）；｝｝publicvoidprint（Stringstr）｛System。out。println（出行旅游的方式为：str）；｝publicstaticvoidmain（String〔〕args）｛TravelStrategywalknewTravelStrategy（Strategy。WALK）；walk。travel（）；TravelStrategyplanenewTravelStrategy（Strategy。PLANE）；plane。travel（）；TravelStrategysubwaynewTravelStrategy（Strategy。SUBWAY）；subway。travel（）；｝
　　很明显，如果需要增加出行方式就需要在增加新的elseif语句，那么如何用策略模式来解决这个问题首先，定义一个策略的接口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。strategystrategy；｝publicvoidtravel（）｛if（strategy！null）｛strategy。travel（）；｝｝
　　测试一下代码：publicclassMain｛publicstaticvoidmain（String〔〕args）｛TravelContexttravelContextnewTravelContext（）；travelContext。setStrategy（newPlaneStrategy（））；travelContext。travel（）；travelContext。setStrategy（newWalkStrategy（））；travelContext。travel（）；travelContext。setStrategy（newSubwayStrategy（））；travelContext。travel（）；｝｝
　　以后如果再增加什么别的出行方式，就再继承策略接口即可，完全不需要修改现有的类策略模式的优点定义一系列算法：策略模式的功能就是定义一系列算法，实现让这些算法可以相互替换；所以会为这一系列算法定义公共的接口，以约束一系列算法要实现的功能；如果这一系列算法具有公共功能，可以把策略接口实现成为抽象类，把这些公共功能实现到父类里面避免多重条件语句：根据前面的示例会发现，策略模式的一系列策略算法是平等的，可以互换的，写在一起就是通过ifelse结构来组织，如果此时具体的算法实现里面又有条件语句，就构成了多重条件语句，使用策略模式能避免这样的多重条件语句更好的扩展性：在策略模式中扩展新的策略实现非常容易，只要增加新的策略实现类，然后在选择使用策略的地方选择使用这个新的策略实现就好了策略模式的缺点客户必须了解每种策略的不同：比如让客户端来选择具体使用哪一个策略，这就可能会让客户需要了解所有的策略，还要了解各种策略的功能和不同，这样才能做出正确的选择，而且这样也暴露了策略的具体实现增加了对象数目：由于策略模式把每个具体的策略实现都单独封装成为类，如果备选的策略很多的话，那么对象的数目就会很可观只适合扁平的算法结构：策略模式的一系列算法地位是平等的，是可以相互替换的，事实上构成了一个扁平的算法结构，也就是在一个策略接口下，有多个平等的策略算法，就相当于兄弟算法；而且在运行时刻只有一个算法被使用，这就限制了算法使用的层级，使用的时候不能嵌套使用小结
　　以上就是对Android开发中常用的装饰者模式、单例模式、策略模式的认识；有需要了解更多设计模式的小伙伴，可以私信发送进阶即可免费领取一份Android全套进阶技术知识学习文档大厂面试真题及答案解析PDF文档，助你更快的掌握Android相关的技术知识
　　内容展示如下：
　　架构设计必入技能详解
　　由于篇幅原因，资料就不完全展示了，以上的资料保证100免费，最后大家如果觉得手册内容有用的话，可以点赞分享一下哦