Java开发设计模式

Java开发共23种设计模式，这里写写自己的理解，后续也会不定时补充

Java设计模式有23中设计模式，又根据模式特点分为三大类：创建者模式、结构型模式、行为型模式。学习设计模式是为了开发时使我们的代码更符合设计原则（六原则一法则）

单一职责原则：一个类只做它该做的事情。
开闭原则：软件实体应当对扩展开放，对修改关闭。
依赖倒转原则：面向接口编程。
里氏替换原则：任何时候都可以用子类型替换掉父类型。
接口隔离原则：接口要小而专，绝不能大而全。
合成复用原则：在代码复用上优先考虑合成、聚合(has a)关系，而不是继承(is a)。
迪米特法则：迪米特法则又叫最少知识原则，一个对象应当对其他对象有尽可能少的了解。

创建者模式

创建者模式讲的是如何更好的创建对象将对象的创建和使用分离，其中分为：单例模式、工厂模式、抽象工厂模式、原型模式、建造者模式5种。

单例模式

单例模式有两种：

饿汉式：类加载时就被创建，优点：创建对象更快；缺点：比较消耗系统资源也许不需要使用也会被加载导致启动慢
懒汉式：首次使用该对象时才会被使用，优点：启动快占用资源少；缺点：容易发生线程的不安全需要做好对应安全措施

工厂模式

工厂模式主要有两种：（PS：简单工厂模式严格来说不算设计模式，应该是编程的一种习惯所以没算上是工厂模式）

工厂方法模式：
优点：1.用户只需要知道具体的工厂名称就可以得到所要的产品不需要知道具体细节，
   2. 在系统增加新的产品时只需要添加具体产品类和对应的具体工厂类，无须对原工厂进行任何修改，满足开闭原则
缺点：1.每增加一个产品就要增加一个具体产品类和一个对应的具体工厂类，这增加了系统的复杂度
抽象工厂模式：
优点：当一个产品族中的多个对象被设计成一起工作时，它能保证客户端始终只使用同一个产品族中的对象
缺点：当产品族中需要增加一个新的产品时，所有的工厂类都需要进行修改。

原型模式

用一个已经创建的实例作为原型，通过复制该原型对象来创建一个和原型对象相同的新对象

建造者模式

优点：1.建造者模式的封装性很好。使用建造者模式可以有效的封装变化，在使用建造者模式的场景中，一般产品类和建造者类是比较稳定的，因此，将主要的业务逻辑封装在指挥者类中对整体而言可以取得比较好的稳定性。
   2.在建造者模式中，客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象。
   3.可以更加精细地控制产品的创建过程。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程。
   4.建造者模式很容易进行扩展。如果有新的需求，通过实现一个新的建造者类就可以完成，基本上不用修改之前已经测试通过的代码因此也就不会对原有功能引入风险。符合开闭原则
缺点：造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，则不适合使用建造者模式，因此其使用范围受到一定的限制。

补充：建造者模式使用中使用最多的是内部类建造的方式比如：

Phone builder = new Phone.Builder()
                .cpu("高通晓龙8Gen2")
                .mainboard("华硕主板")
                .screen("三星屏幕")
                .builder();

结构型模式

结构型模式讲的是如将类或对象通过某种布局组成更大的结构，其中分为：代理模式、适配器模式、装饰者模式、桥接模式、外观模式、组合模式、享元模式7种。

代理模式

  当我们需要控制某个对象的访问时，我们可以使用代理模式通过代理模式对对象进行增强或者扩展。代理模式有2种分别是：静态代理模式和动态代理模式

静态代理：代理类在编译器就生成了
动态代理：代理类由Java运行时动态生成，动态代理又分为：JDK代理和CGLib代理
优点：代理模式在客户端与目标对象之间起到一个中介作用和保护目标对象的作用；
   代理对象可以扩展目标对象的功能；
   代理模式能将客户端与目标对象分离，在一定程度上降低了系统的耦合度；
缺点：增加了系统复杂度

适配器模式

  将一个类的接口转换成客户希望的另一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。适配器模式有类适配器和对象适配器两种。

装饰者模式

  指在不改变现有对象结构的情况下，动态地给该对象增加一些职责（即增加其额外功能）的模式。

好处：饰者模式可以带来比继承更加灵活性的扩展功能，使用更加方便，可以通过组合不同的装饰者对象来获取具有不同行为状态的多样化的结果。装饰者模式比继承更具良好的扩展性，完美的遵循开闭原则，继承是静态的附加责任，装饰者则是动态的附加责任。
   装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能。

桥接模式

  将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。比如：我们是选windows系统还是mac系统播放avi格式的视频还是mp4格式的视频

外观模式

  又名门面模式，是一种通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具体的细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性。

优点：降低了子系统与客户端之间的耦合度，使得子系统的变化不会影响调用它的客户类。
   对客户屏蔽了子系统组件，减少了客户处理的对象数目，并使得子系统使用起来更加容易。
缺点：不符合开闭原则，修改很麻烦

组合模式

  又名部分整体模式，是用于把一组相似的对象当作一个单一的对象。组合模式依据树形结构来组合对象，用来表示部分以及整体层次。这种类型的设计模式属于结构型模式，它创建了对象组的树形结构。

优点：组合模式可以清楚地定义分层次的复杂对象，表示对象的全部或部分层次，它让客户端忽略了层次的差异，方便对整个层次结构进行控制。
   客户端可以一致地使用一个组合结构或其中单个对象，不必关心处理的是单个对象还是整个组合结构，简化了客户端代码。
   在组合模式中增加新的树枝节点和叶子节点都很方便，无须对现有类库进行任何修改，符合“开闭原侧”。
   组合模式为树形结构的面向对象实现提供了一种灵活的解决方案，通过叶子节点和树枝节点的递归组合，可以形成复杂的树形结构，但对树形结构的控制却非常简单。

享元模式

  运用共享技术来有效地支持大量细粒度对象的复用。它通过共享已经存在的对象来大幅度减少需要创建的对象数量、避免大量相似对象的开销，从而提高系统资源的利用率。

优点：极大减少内存中相以或相同对象数量，节约系统资源，提供系统性能
   享元模式中的外部状态相对独立，且不影响内部状态
缺点：为了使对象可以共享，需要将享元对象的部分状态外部化，分离内部状态和外部状态，使程序逻辑复杂

行为型模式

行为型模式讲的是对象或类之间怎样相互协作完成单个对象无法单独完成的任务，其中分为：模板模式、策略模式、命令模式、职责链模式、状态模式、观察者模式、中介者模式、迭代器模式、访问者模式、备忘录模式、解释器模式11种。

模板模式

  定义一个操作中的算法骨架，而将算法的一些步骤延迟到子类中，使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。

优点：提高代码复用性，将相同部分的代码放在抽象的父类中，而将不同的代码放入不同的子类中。
   实现了反向控制，通过一个父类调用其子类的操作，通过对子类的具体实现扩展不同的行为，实现了反向控制，并符合“开闭原则”。
缺点：对每个不同的实现都需要定义一个子类，这会导致类的个数增加，系统更加庞大，设计也更加抽象。
   父类中的抽象方法由子类实现，子类执行的结果会影响父类的结果，这导致一种反向的控制结构，它提高了代码阅读的难度。

策略模式

  该模式定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的变化不会影响使用算法的客户。策略模式属于对象行为模式，它通过对算法进行封装，把使用算法的责任和算法的实现分割开来，并委派给不同的对象对这些算法进行管理。

优点：策略类之间可以自由切换，由于策略类都实现同一个接口，所以使它们之间可以自由切换。
   易于扩展，增加一个新的策略只需要添加一个具体的策略类即可，基本不需要改变原有的代码，符合“开闭原测”
   避免使用多重条件选择语句(if else),充分体现面向对象设计思想。
缺点：客户端必须知道所有的策略类，并自行决定使用哪一个策略类。
   策略模式将造成产生很多策略类，可以通过使用享元模式在一定程度上减少对象的数量。

命令模式

  将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。这样两者之间通过命令对象进行沟通，这样方便将命令对象进行存储、传递、调用、增加与管理。

优点：降低系统的耦合度。命令模式能将调用操作的对象与实现该操作的对象解耦。
   增加或删除命令非常方便。采用命令模式增加与删除命令不会影响其他类，它满足“开闭原则”，对扩展比较灵活。
   可以实现宏命令。命令模式可以与组合模式结合，将多个命令装配成一个组合命令，即宏命令。
   方便实现Udo和Redo操作。命令模式可以与后面介绍的备忘录模式结合，实现命令的辙销与恢复。
缺点：使用命令模式可能会导致某些系统有过多的具体命令类
   系统结构更加复杂。

职责链模式

   又名职责链模式，为了避免请求发送者与多个请求处理者耦合在一起，将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链；当有请求发生时，可将请求沿着这条链传递，直到有对象处理它为止。

优点：降低了对象之间的耦合度，该模式降低了请求发送者和接收者的耦合度。
   增强了系统的可扩展性，可以根据需要增加新的请求处理类，满足开闭原则。
   增强了给对象指派职责的灵活性，当工作流程发生变化，可以动态地改变链内的成员或者修改它们的次序，也可动态地新增或者删除责任。
   责任链简化了对象之间的连接，一个对象只需保持一个指向其后继者的引用，不需保持其他所有处理者的引用，这避免了使用众多的if或者if…else语句。
   责任分担，每个类只需要处理自己该处理的工作，不能处理的传递给下一个对象完成，明确各类的责任范围，符合类的单一职责原则。
缺点：不能保证每个请求一定被处理。由于一个请求没有明确的接收者，所以不能保证它一定会被处理，该请求可能一直传到链的末端都得不到处理。
   对比较长的职责连，请求的处理可能涉及多个处理对象，系统性能将受到一定影响
   职责链建立的合理性要靠客户端来保证，增加了客户端的复杂性，可能会由于职责链的错误设置而导致系统出错，如可能会造成循环调用。

状态模式

   对有状态的对象，把复杂的“判断逻辑“提取到不同的状态对象中，允许状态对象在其内部状态发生改变时改变其行为。

优点：将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。
   允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。
缺点：状态模式的使用必然会增加系统类和对象的个数。
   状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。
   状态模式对“开闭原则”的支持并不太好。

观察者模式

  又被称为发布-订阅(Publish/Subscribe)模式，它定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态变化时，会通知所有的观察者对象，使他们能够自动更新自己。

优点：降低了目标与观察者之间的耦合关系，两者之间是抽象耦合关系。
   被观察者发送通知，所有注册的观察者都会收到信息【可以实现广播机制】
缺点：如果观察者非常多的话，那么所有的观察者收到被观察者发送的通知会耗时
   如果被观察者有循环依赖的话，那么被观察者发送通知会使观察者循环调用，会导致系统崩溃

中介者模式

  又叫调停模式，定义一个中介角色来封装一系列对象之间的交互，使原有对象之间的耦合松散，且可以独立地改变它们之间的交互。

优点：松散耦合，中介者模式通过把多个同事对象之间的交互封装到中介者对象里面，从而使得同事对象之间松散耦合，基本上可以做到互补依赖。这样一来同事对象就可以独立地变化和复用，而不再像以前那样“牵一处而动全身”了。
   集中控制交互，多个同事对象的交互，被封装在中介者对象里面集中管理，使得这些交互行为发生变化的时候，只需要修改中介者对象就可以了，当然，如果是已经做好的系统，那么就扩展中介者对象，而各个同事类不需要做修改。
   一对多关联转变为一对一的关联，没有使用中介者模式的时候，同事对象之间的关系通常是一对多的，引入中介者对象以后，中介者对象和同事对象的关系通常变成双向的一对一，这会让对象的关系更容易理解和实现
缺点：当同事类太多时，中介者的职责将很大，它会变得复杂而庞大，以至于系统难以维护

迭代器模式

  提供一个对象来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。

优点：它支持以不同的方式遍历个聚合对象，在同一个聚合对象上可以定义多种遍历方式。在迭代器模式中只需要用一个不同的迭代器来替换原有迭代器即可改变遍历算法，我们也可以自己定义迭代器的子类以支持新的遍历方式。
   迭代器简化了聚合类。由于引入了迭代器，在原有的聚合对象中不需要再自行提供数据遍历等方法，这样可以简化聚合类的设计。
   在迭代器模式中，由于引入了抽象层，增加新的聚合类和迭代器类都很方便，无须修改原有代码，满足“开闭原则”的要求。
缺点：增加了类的个数，这在一定程度上增加了系统的复杂性。

访问者模式

  封装一些作用于某种数据结构中的各元素的操作，它可以在不改变这个数据结构的前提下定义作用于这些元素的新的操作。

优点：扩展性好，在不修改对象结构中的元素的情况下，为对象结构中的元素添加新的功能。
   复用性好，通过访问者来定义整个对象结构通用的功能，从而提高复用程度。
   分离无关行为，通过访问者来分离无关的行为，把相关的行为封装在一起，构成一个访问者，这样每一个访问者的功能都比较单一。
缺点：对象结构变化很困难，在访问者模式中，每增加一个新的元素类，都要在每一个具体访问者类中增加相应的具体操作，这违背了“开闭原则”。
   违反了依赖倒置原则，访问者模式依赖了具体类，而没有依赖抽象类。

备忘录模式

  又叫快照模式，在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，以便以后当需要时能将该对象恢复到原先保存的状态。

优点：提供了一种可以恢复状态的机制。当用户需要时能够比较方便地将数据恢复到某个历史的状态。
   实现了内部状态的封装。除了创建它的发起人之外，其他对象都不能够访问这些状态信息。
   简化了发起人类。发起人不需要管理和保存其内部状态的各个备份，所有状态信息都保存在备忘录中，并由管理者进行管理，这符合单一职责原则。
缺点：资源消耗大。如果要保存的内部状态信息过多或者特别频繁，将会占用比较大的内存资源。

解释器模式

  给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子。

优点：易于改变和扩展文法。由于在解释器模式中使用类来表示语言的文法规则，因此可以通过继承等机制来改变或扩展文法。每一条文法规则都可以表示为一个类，因此可以方便地实现一个简单的语言。
   实现文法较为容易。在抽象语法树中每一个表达式节点类的实现方式都是相似的，这些类的代码编写都不会特别复杂。
   增加新的解释表达式较为方便。如果用户需要增加新的解释表达式只需要对应增加一个新的终结符表达式或非终结符表达式类，原有表达式类代码无须修改，符合"开闭原则"。
缺点：对于复杂文法难以维护。在解释器模式中，每一条规则至少需要定义一个类，因此如果一个语言包含太多文法规则，类的个数将会急剧增加，导致系统难以管理和维护。
   执行效率较低。由于在解释器模式中使用了大量的循环和递归调用，因此在解释较为复杂的句子时其速度很慢，而且代码的调试过程也比较麻烦。