设计模式应用场景的优缺点

大家应该都知道，在Java设计模式中会有很多的设计模式应用场景，这些场景也有优缺点，下面小编就来给大家介绍一下。

外观模式：

也被称为门面模式。当我们开发Android的时候，无论是做SDK还是封装API，大多都会用到外观模式，

它通过一个外观类使得整个系统的结构只有一个统一的高层接口，这样能降低用户的使用成本;

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

使用场景：

1.构建一个有层次结构的子系统时，使用外观模式定义子系统中每层的入口点。如果子系统之间是相互依赖的，则可以让其通过外观接口进行通信，减少子系统之间的依赖关系;

2.子系统往往会因为不断的重构演化而变得越来越复杂，大多数的模式使用时也会产生很多很小的类，这给外部使用它们的用户程序，带来了使用上的困难。我们可以用外观类提供一个简单的接口，对外隐藏子系统的具体实现并隔离变化;

3.当维护一个遗留的大型系统时，可能这个系统已经非常难以维护和拓展;但是因为它含有重要的功能，所以新的需求必须依赖于它，这时可以使用外观类，为设计粗糙或者复杂的遗留代码提供一个简单的接口，让新系统和外观类交互，而外观类负责与遗留的代码进行交互;

优点：

1.减少系统的相互依赖，所有的依赖都是对外观类的依赖，与子系统无关;

2.对用户隐藏了子系统的具体实现，减少用户对子系统耦合;这样即使具体的子系统发生了变化，用户也不会感知到;

3.坚强了安全性，子系统中的方法如果不在外观类中开通，就无法访问到子系统中的方法;

缺点：

不符合开放封闭原则。如果业务出现变更，则可能要直接修改外观类;

建造者模式：也被称为生成器模式;

定义：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示;

使用场景：

1.当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时;

2.相同的方法，不同的执行顺序，缠身不同的事件结果时;

3.多个部件或零件都可以被装配到一个对象中，但是产生的运行结果又不相同时;

4.产品类非常复杂，或者产品类中的调用顺序不同而产生了不用的效能;

5.在创建一些复杂的对象时，这些对象的内部组成构件间的建造顺序是稳定的，但是对象的内部组成构件面临着复杂的变化

优点：

1.使用建造者模式可以使客户端不必知道产品内部组成的细节;

2.具体的建造者类之间是相互的独立的，容易扩展;

3.由于具体的建造者是独立的，因此可以对建造过程逐步细化，而不对其他的模块产生任何影响

缺点：

产生多余的Build对象以及导演类;

装饰器模式：

动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活;

使用场景：

1.在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责;

2.需要动态地给一个对象增加功能，这些功能可以动态的撤销;

3.当不能采用继承的方式对系统进行扩充或者采用继承不利于系统扩展和维护时;

优点：

1.通过组合而非继承的方式，动态地扩展一个对象的功能，在运行时选择不同的装饰器，从而实现不同的行为;

2.有效避免了使用继承的方式扩展对象功能而带来的灵活性差、子类无线扩张的问题;

3.具体组件类与具体装饰类可以独立变化，用户可以根据需要增加新的具体组件类和具体装饰类，在使用时在对其进行组合， 原有代码无须改变，符合“开放封闭原则”;

缺点：

1.因为所有对象均继承于Speciality，所以如果Speciality内部结构发生改变，则不可避免影响所有子类(装饰者和被装饰者)。 如果基类改变，则势必影响对象的内部;

2.比继承更加灵活机动的特性，也同时意味着装饰模式比继承更加易于出错，排错也很困难。对于多次装饰的象，调试时寻找错误可能需要逐级排查，较为繁琐，所以，只在必要的时候使用装饰模式;

3.装饰层数不能过多，否则会影响效率;

享元模式:

享元模式是池技术的重要实现方式，它可以减少应用程序创建的对象，降低程序内存的占用，提高程序的性能;

定义：使用共享对象有效地支持大量细粒度的对象;

使用场景：

1.系统中存在大量的相似对象;

2.需要缓冲池的场景;

简单工厂模式(又叫作静态工厂方法模式)

定义：简单工厂模式属于创建型模式，这是由一个工厂对象决定出哪一种产品类的实例

使用场景：

1.工厂类负责创建的对象比较少

2.客户只需要传入工厂类的参数，而无需关心创建对象的逻辑

优点：使用户根据参数获得对应类的实例，避免了直接实例化类降低了耦合性

缺点：可实例化的类型在编译期间已经被确定。如果增加新类型，则需要修改工厂，这违背了开放封闭原则。

简单工厂需要知道所有要生成的类型，其当子类过多或者子类层次过多时不适合使用。

观察者模式

观察者模式又被称为发布-订阅模式，属于行为型设计模式的一种，是一个在项目中经常使用的模式，

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

使用场景：

1.关联行为场景。需要注意的是，关联行为是可拆分的，而不是“组合”关系;

2.事件多级触发场景;

3.跨系统的消息交换场景，如消息队列、事件总线的处理机制;

优点：

1.观察者与被观察者之间是抽象耦合，容易扩展;

2.方便建立一套触发机制;

缺点：

在应用观察者模式时需要考虑一下开发效率和运行效率的问题。程序中包括一个被观察者、多个观察者，开发、调试等内容会比较复杂，而且在java中消息的通知一般是顺序执行的，那么一个观察者卡顿，会影响整体的执行效率，在这种情况下，一般会采用异步方式;

代理模式：也被称为委托模式，它是结构型设计模式的一种。

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

动态代理：在代码运行时通过反射来动态地生成代理类的对象，并确定道理来代理谁使用范围：

使用场景：

1.远程代理：为一个对象在不同的地址空间提供局部代表，这样系统可以将Server部分实现隐藏;

2.虚拟代理：使用一个代理对象表示一个十分耗费资源的对对象并在真正需要时才创建;

3.安全代理：用来控制真实对象访问时的权限。一般用于真实对象有不同的访问权限时;

4.智能指引：当调用真实的对象时，代理处理另外一些事，比如计算机真实对象的引用计数，当该对象没有引用时，可以自动释放它;或者访问一个实际对象时，检查是否已经能够锁定它，以确保其他对象不能改变它;

优点：

1.真实主题类就是实现实际的业务逻辑，不用关心其他非本职的工作;

2.真实主题类随时都会发生变化，但是因为它实现了公共的接口，所以代理类可以不做任何修改能够使用;

策略模式

当我们写代码时总会遇到一种情况，就是我们会有很多的选择，由此衍生出很多的if...else或者case，如果每个条件语句中包含了一个简单的逻辑，那还比较容易处理;但如果在一个条件语句中又包含了多个条件语句，就会使得代码变得臃肿，维护的成本也会加大，这显然违背了开放封闭原则。

定义：定义一系列的算法，报每一个算法封装起来，并且使它们相互替换。策略模式使得算法可独立于使用它的客户而独立变化;

使用场景：

1.对客户隐藏具体策略(算法)的实现细节，彼此完全独立;

2.针对同一类型问题的多种处理方式，仅仅是具体行为有差别时;

3.在一个类中定义了很多行为，而且这些行为在这个类里的操作以多个条件语句的形式出现; 策略模式将相关的条件分支移入他们各自的Strategy类中，以代替这些条件语句;

优点：

1.使用策略模式可以避免使用多重条件语句。多重条件语句不移维护，而且容易出错;

2.易于拓展，当需要添加一个策略时，只需要实现接口就可以了

缺点：

1.每一个策略都是一个类，复用性小。如果策略过多，类的数量会增加;

2.上层模块必须知道有哪些策略，才能够使用这些策略，这与迪米特原则相违背;

模板方法模式：

在软件开发中，有事会遇到类似的情况：某个方法的实现需要多个步骤，其中有些步骤是固定的;而有些步骤并不固定，存在可变性。为了提高代码的复用性和系统的灵活性，可以使用模板方法来应对这类情况;

定义：定义一个操作中的算法框架，而将一些步骤延迟到子类中，是的子类不改变一个算法的结构即可重新定义算法的某些特定步骤;

使用场景：

1.多个子类有共有的方法，并且逻辑基本相同时;

2.面对重要、复杂的算法，可以把核心算法设计为模板方法，周边相关细节功能则由各个子类实现;

3.需要通过子类来决定父类算法中的某个步骤是否执行，实现子类对父类的反向控制;

优点：

1.模板方法模式通过把不变的行为搬移到超类，去除了子类中的重复代码;

2.子类实现算法的某些细节，有助于算法的扩展;

缺点：

每个不同的实现都需要定义一个子类，这会导致类的个数的增加，设计更加抽象;

Java的知识点有很多，如果大家想学习更多相关知识，可以来关注一下赢咖4的Java赢咖4在线学习，里面的内容详细，适合没有基础的朋友学习，相信会对大家有所帮助的。