设计模式小结

在以下举例中，大部分是虚构，例子只是为了简单。关于app的例子只是自己虚构出来的。

创建型设计模式：

简单工厂、工厂模式、抽象工厂

简单工厂专门定义一个类用于负责创建其他类的实例，被创建的实例通常具有共同的父类
工厂模式定义一个用于创建对象的接口，让子类决定实例化哪一个类，使一个类的实例化延迟到其子类（只是个假设）例如飞机工厂只生产飞机，超火工厂只生产超级火箭，火箭工厂只生产火箭。优点：一个调用者想创建一个对象只需要知道名称就可以，不需要知道类名。扩展性高，增加一个产品只需要扩展一个工厂类。屏蔽产品的实现，只需要关注接口。
缺点：扩展工厂类使得类数量成倍增加，增加了系统复杂度，也增加了系统具体类的依赖。
抽象工厂提供一个创建一系列相关或者相互依赖对象的接口，而无需指定他们具体的类。
简单来说，一种工厂可以有多个品牌的工厂，一个品牌的工厂可以生产多种物品。缺点，扩展难——加代码地方多。优点：当一个产品族中的多个对象被设计成一起工作时，他能保证客户端始终只是用一个产品族中的对象。

当产品只有一个的时候，抽象工厂就变成了工厂模式。

例子

简单工厂：火箭工厂，只能生产火箭。
工厂模式：礼物工厂，制造礼物，不同的礼物继承于礼物基类或者实现礼物接口，要根据参数确定生产哪一种礼物。
抽象工厂模式：礼物面板工厂，礼物面板不仅有礼物，还有道具。 APP换皮肤，设置的一些控件一起换皮肤。

单例模式

单例模式，就是只有一个实例，构造函数为private。
有多种实现方法：

懒汉式 2.饿汉式（线程安全、线程不安全） 3.双重锁 4.内部类 5.枚举

优点：在内存中只有一个实例，减少了内存的开销，尤其是频繁的创建和销毁实例。
缺点：没有接口，不能继承，与单一职责冲突，一个类应该只关心内部逻辑，不该关心外面怎么变化。

例子

在客户端用户应该是单例。

建造者模式

一个复杂对象的建立，一些基本部件不会变，而其组合经常变化。
优点：建造者独立，易扩展。便于控制细节风险。
缺点：产品必须有共同点，范围有限制。如果内部变化复杂，会有很多的建造类。
使用场景：需要生成的对象具有复杂的内部结构，需要生成的对象内部属性本身相互依赖。

例子

肯德基的套餐：肉汉堡+纸包装--可口可乐+杯子装素汉堡+塑料装——百事可乐+瓶子装
与工厂模式的区别，建造者模式更关注零件装配的顺序。

原型模式

用于创建重复的对象，又保证性能。（直接创建对象代价较大，就采用原型模式，只需要克隆再更新数据），比如从数据库获取的数据，从网络上请求回来解析出来的对象可以使用原型。

例子

刺客型英雄，当创建了第一个刺客型英雄后，在创建第二个、第三个的时候，可以直接克隆第一个刺客，再在此基础上进行创作。

结构型设计模式：

适配器模式

作为两个不兼容的接口之间的桥梁。将一个类的接口转换成客户希望的另一个接口。
使用场景：有动机地修改一个正常运行的系统的接口，应该考虑使用适配器。（适配器不是在设计时添加的，而是解决正在服役的项目的问题）
优点：灵活、可以让两个没有关联的类一起运行。
缺点：过多使用适配器，会让系统零乱。因为java单继承，所以至多只能适配一个适配器类，而且目标类必须是抽象类。

例子

ListView RecyclerView 都需要适配器Adapter来适配数据。
屏幕适配。做好的APP，要适配大部分市场使用的机型，否则界面达不到效果，甚至混乱。
美国电器110V，中国220V，所以要有个适配器把110V转为220V来使用中国电器。

桥接模式

把抽象化和实现化解耦，使得两者可以独立变化。
主要解决：再有多种可能会变化的情况下，使用继承会造成类爆炸，扩展不灵活。
优点：抽象与实现分离，优秀的扩展能力，实现细节对客户透明。
缺点：理解和设计难度增大，针对抽象进行设计和编程。（因为聚合关联关系在抽象层）。
使用场景：对于两个独立变化的维度，使用桥接模式在合适不过了。

例子

普通弹幕字体没有颜色，粉丝弹幕、高级弹幕字体可以有颜色。他们可以继承弹幕库类，弹幕库又拥有绘制弹幕这一API，让可以有不同大小颜色的画笔实现这一接口即可。

过滤器模式

可以让开发人员使用不同的标准来过滤一组对象，通过逻辑运算以解耦的方式把他们连接起来。
其实就是分组的操作，可以根据指定的标准进行分组筛选。

例子

用户分类，可以过滤出男性、女性、年龄段、贵族、白嫖党等用户的列表

组合模式

部分整体模式，把一组相似的对象当作一个单一的对象。依据树形结构来组合对象。就是一个对象中包含其他对象（节点），以此类推。
如何实现：树枝和叶子实现统一的接口，树枝内部组合该接口，并且含有内部属性List，里面放组件。
优点：节点自由增加，高层模块调用简单。
缺点：其叶子和树枝的声明都是实现类，而不是接口，违反了依赖倒置原则。
使用场景：部分、整体场景，如树形菜单、文件、文件夹的管理。

装饰器模式

允许向一个现有的对象添加新的功能，同时不改变其结构。是作为现有类的一个包装。
主要解决：为了扩展一个类经常使用继承实现，由于继承会为类引入静态特征，并且随着扩展功能的增多，子类会很膨胀。
何时使用：在不想增加很多子类的情况下扩展类。
如何实现：组件类充当抽象角色，不具体实现，修饰类引用和继承组件类，具体扩展类重写父类方法。
优点：装饰类、被装饰类可以被扩展，不会相互耦合，装饰模式是继承的一个替代模式。可以动态扩展一个实现类的功能。
缺点：多层装饰会比较复杂。
使用场景：扩展一个类的功能。动态增加功能、撤销功能。可以代替继承。嘿嘿嘿。
装饰者模式和桥接模式的区别（个人理解）：桥接模式是主体拥有客体的接口，客体实现接
口；装饰者模式是装饰器拥有被装饰者主体，装饰方法。装饰者类只需实现装饰器接口。

例子

弹幕和边框，边框颜色可以变化，不影响弹幕本体。所以可以用装饰器把边框装饰到弹幕上。
还有个游戏解释：装饰模式为已有类动态附加额外的功能，比如LOL，王者农药等Dota游戏中，英雄升级一样。每次英雄升级都会附加一个额外技能点学习技能，具体的英雄就是被修饰者，技能栏就是装饰器，每个技能就是具体的装饰器（实现装饰器）。
英雄的皮肤
礼物的外观，比如火箭，在（一条小团团OvO）的直播间中，火箭为主播定制，名称是飞天小猪；在妃凌雪的直播间中，火箭改成了空投补给箱。

外观模式

隐藏系统的复杂性，向客户端提供了一个访问系统的接口。
如何解决：客户端不与系统耦合，外观类与系统耦合。
优点：减少系统相互依赖提高灵活性提高了安全性。
缺点：不符合开闭原则，改东西很麻烦，继承重写都不合适。
在层次化结构中，可以使用外观模式定义系统中每一层的入口。

例子

一键登录、一键开播。

其实就是，把所有步骤整合到了一起。。。肯定不适合扩展。

享元模式

用于减少创建对象的数量，以减少内存占用和提高性能。
用HashMap存储这些对象。
缺点：提高系统复杂度，需要分离出外部状态和内部状态。且外部状态要具有固有化的状态，不应该随着内部状态的变化而变化，否则会造成系统的混乱。
使用场景：系统有大量相似对象需要缓冲池的场景。这些类必须有一个工厂加以控制。

例子

游戏中的子弹。同一类型的子弹可以重复使用而不用创建，只需要修改它的其他属性。

代理模式

创建具有现有对象的对象，以便向外界提供功能接口。为其他对象提供一种代理来控制对这个对象的访问。
何时使用：想在访问一个类的时候做一些控制。——>增加中间层。实现与被代理类组合。
优点：职责清晰、高扩展性。
缺点：增加了代理可能会导致请求的处理速度变慢。实现代理需要额外工作，有些代理复杂。

例子

保护代理、Cache代理、远程代理、同步化代理图片资源缓存判断代理

与适配器的区别：适配器对象主要改变所考虑对象的接口，而代理模式不能改变所代理类的接口。
与装饰器的区别：装饰器是为了增强功能，而代理模式是为了加以控制。

责任链模式

链式处理请求。
优点：降低耦合度，将请求的发送者和接收者解耦。对象不知道链的存在。增加新的请求处理类很方便。灵活，可以改变链内成员的次序，允许动态新增、删除责任。
缺点：不能保证请求一定被接收，系统性能受一定影响，代码调试的时候可能会造成循环调用。可能不容易观察运行时特征，有碍于排错。
使用场景：多个对象处理同一请求。

例子

日志记录级别就使用了责任链模式。 INFO、DEBUG、ERROR、WARNNING 可以创建不同的Logger来处理日志信息。

行为型设计模式

命令模式

请求以命令的形式包裹在对象中，并传给调用对象，调用对象可以寻找可以处理该命令的合适的对象，并把该命令传给相应的对象，该对象执行命令。
目的：将一个请求封装成一个对象，从而可以使用不同的请求对客户进行参数化。
将行为请求者和行为实现者解耦合。
实现：定义三个角色：Received真正的命令执行者、Command、Invoker使用命令对象的入口
优点：降低耦合，新的命令很容易添加到系统中。
缺点：导致系统有过多的具体命令类。
可以支持命令的撤销和恢复操作。

例子

其实就是执行一系列命令，这些命令继承基命令，通过执行者的execute来遍历基命令类型list

解释器模式

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

例子

可以用到自然语言处理中，根据语法规则来处理数据。

迭代器模式

提供一种方法顺序访问一个聚合对象中各个元素，而又无须暴露该对象的内部表示。
主要解决：不同的方式来遍历整个整合对象。
如何解决：把在元素之间游走的责任交给迭代器。定义hasNext接口 next。
优点：支持以不同的方式遍历一个聚合对象增加新的聚合类和迭代器类都很方便，不需要修改原有代码。
缺点：因为迭代器模式将存储数据和遍历数据的职责分离，增加新的聚合类需要对应的迭代器类，类的个数成对增加，增加了系统的复杂性。
使用场景：为遍历不同的聚合结构提供一个统一的接口。

例子

遍历用户昵称、等信息

中介者模式

降低多个对象和类之间的通信复杂性。用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显示地相互引用，从而使其耦合松散，而且可以独立地改变他们之间的交互。
何时使用：多各类相互耦合形成了网状结构。
关键代码：对象之间的通信封装到一个类中单独处理。
优点：降低类的复杂度，将一对多变成了一对一，各类之间解耦符合迪米特原则。
缺点：中介者会变的庞大，变得复杂难以维护。中介者出了问题都会受影响
新增一个同事类，不得不去修改抽象中介者类和具体中介者类，此时可以使用观察者模式和状态模式来解决这个问题。
使用场景：1.系统中对象之间存在比较复杂的引用关系，导致他们之间的依赖关系结构混乱而且难以复用该对象。2.想要通过一个中间类来封装多个类中的行为，而又不想生成太多子类。

例子

聊天室来让多个用户想聊天时发送消息，展示消息给所有用户。
弹幕界面~~

备忘录模式

在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。
何时使用：这样做的目的是为了允许用户取消不确定或者错误的操作，能够恢复到原先状态。
优点：给用户后悔药，方便回滚实现了信息的封装，用户不需要关心状态的保存细节。
缺点：消耗资源
使用场景：需要保存/恢复数据的相关状态场景提供回滚操作。
注意事项：为了符合迪米特原则，还要增加一个管理备忘录的类，为了节约内存，可以使用原型模式+备忘录模式。

例子

游戏存档 Ctrl-Z 数据库中的事务管理

观察者模式

一对多关系，使用观察者模式。当一个对象被修改时，会自动通知他的依赖对象。
何时使用：一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知，进行广播通知。
关键代码：在抽象类中有一个ArrayList存放观察者们。
优点：观察者和被观察者是抽象耦合的。建立一套触发机制
缺点：若果一个被观察者对象有很多的直接或者间接的观察者，将所有的观察者都通知到会很花时间。如果他们之间有循环依赖的话可能会导致系统崩溃。只是知道被观察者状态变了，不知道怎么变得。
使用场景：1.一个抽象模型有两个方面，其中一个方面依赖于另一个方面。将这些方面封装在独立的对象中使它们可以各自独立地改变和复用。
2.一个对象的改变将导致其他一个或多个对象也发生改变，而不知道具体有多少对象将发生改变，可以降低对象之间的耦合度。
3.一个对象必须通知其他对象，而并不知道这些对象是谁。
4.需要在系统中创建一个触发链，A对象的行为将影响B对象，B对象的行为将影响C对象……，可以使用观察者模式创建一种链式触发机制。
注意：避免循环引用如果顺序执行，一个观察者错误会导致卡死，一般采用异步方式。

例子

广播比如用户给某个主播送了一个超火，那么其他直播间的观察者就会得到此通知，展示在UI上一个广播通知条：XXX给XXX主播送了XX个超级火箭，快去围观！

状态模式

类的行为是基于他的状态改变的。
主要解决：对象的行为依赖于它的状态（属性），并且可以根据它的状态改变而改变它的相关行为。
何时使用：代码中包含大量与对象状态有关的条件语句。
如何解决：将各种具体的状态类抽象出来。
关键代码：通常命令模式的接口中只有一个方法。而状态模式的接口中有一个或者多个方法。而且，状态模式的实现类的方法，一般返回值，或者是改变实例变量的值。也就是说，状态模式一般和对象的状态有关。实现类的方法有不同的功能，覆盖接口中的方法。状态模式和命令模式一样，也可以用于消除 if...else 等条件选择语句。
应用实例： 1、打篮球的时候运动员可以有正常状态、不正常状态和超常状态。
优点： 1、封装了转换规则。 2、枚举可能的状态，在枚举状态之前需要确定状态种类。
3、将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。 4、允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。 5、可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。
缺点： 1、状态模式的使用必然会增加系统类和对象的个数。 2、状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。 3、状态模式对"开闭原则"的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态，而且修改某个状态类的行为也需修改对应类的源代码。
注意事项：在行为受状态约束的时候使用此模式，且状态不超过5个。

例子

主播直播状态。

空对象模式

就是创建一个对象，其内部的各种属性，行为都是自定义空属性、不做任何操作。

例子

有的时候不能只返回一个null，而是要返回一个“空”对象，具有对象的外壳，内部内容赋值空。

策略模式

一个类的行为或其算法可以在运行时更改。
意图：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。
主要解决：在有多种算法相似的情况下，使用 if...else 所带来的复杂和难以维护。
何时使用：一个系统有许多许多类，而区分它们的只是他们直接的行为。
如何解决：将这些算法封装成一个一个的类，任意地替换。
关键代码：实现同一个接口。
应用实例： 1、诸葛亮的锦囊妙计，每一个锦囊就是一个策略。 2、旅行的出游方式，选择骑自行车、坐汽车，每一种旅行方式都是一个策略。 3、JAVA AWT 中的 LayoutManager。
优点： 1、算法可以自由切换。 2、避免使用多重条件判断。 3、扩展性良好。
缺点： 1、策略类会增多。 2、所有策略类都需要对外暴露。
使用场景： 1、如果在一个系统里面有许多类，它们之间的区别仅在于它们的行为，那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为。
2、一个系统需要动态地在几种算法中选择一种。
3、如果一个对象有很多的行为，如果不用恰当的模式，这些行为就只好使用多重的条件选择语句来实现。
注意事项：如果一个系统的策略多于四个，就需要考虑使用混合模式，解决策略类膨胀的问题。

例子

商城促销活动

策略模式与状态模式比较：

状态模式的类图和策略模式类似，并且都是能够动态改变对象的行为。但是状态模式是通过状态转移来改变 Context 所组合的 State 对象，而策略模式是通过 Context 本身的决策来改变组合的 Strategy 对象。所谓的状态转移，是指 Context 在运行过程中由于一些条件发生改变而使得 State 对象发生改变，注意必须要是在运行过程中。

状态模式主要是用来解决状态转移的问题，当状态发生转移了，那么 Context 对象就会改变它的行为；而策略模式主要是用来封装一组可以互相替代的算法族，并且可以根据需要动态地去替换 Context 使用的算法。

模板模式

意图：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
主要解决：一些方法通用，却在每一个子类都重新写了这一方法。
何时使用：有一些通用的方法。
如何解决：将这些通用算法抽象出来。
关键代码：在抽象类实现，其他步骤在子类实现。
应用实例： 1、在造房子的时候，地基、走线、水管都一样，只有在建筑的后期才有加壁橱加栅栏等差异。 2、西游记里面菩萨定好的 81 难，这就是一个顶层的逻辑骨架。
3、spring 中对 Hibernate 的支持，将一些已经定好的方法封装起来，比如开启事务、获取 Session、关闭 Session 等，程序员不重复写那些已经规范好的代码，直接丢一个实体就可以保存。
优点： 1、封装不变部分，扩展可变部分。 2、提取公共代码，便于维护。 3、行为由父类控制，子类实现。
缺点：每一个不同的实现都需要一个子类来实现，导致类的个数增加，使得系统更加庞大。
使用场景： 1、有多个子类共有的方法，且逻辑相同。 2、重要的、复杂的方法，可以考虑作为模板方法。
注意事项：为防止恶意操作，一般模板方法都加上 final 关键词。
其实就是定义了一个抽象父类，父类已经有公共部分方法，子类都要实现他一些非公共方法。

例子

各种直播间通用方法：拉流，评论等公共代码封装到父类。子类写父类模板的其他方法。

访问者模式

使用了一个访问者类，它改变了元素类的执行算法。通过这种方式，元素的执行算法可以随着访问者改变而改变。
主要使数据结构和数据操作分离。
何时使用：需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免让这些操作"污染"这些对象的类，使用访问者模式将这些封装到类中。
如何解决：在被访问的类里面加一个对外提供接待访问者的接口。
关键代码：在数据基础类里面有一个方法接受访问者，将自身引用传入访问者。
应用实例：您在朋友家做客，您是访问者，朋友接受您的访问，您通过朋友的描述，然后对朋友的描述做出一个判断，这就是访问者模式。
优点： 1、符合单一职责原则。 2、优秀的扩展性。 3、灵活性。
缺点： 1、具体元素对访问者公布细节，违反了迪米特原则。 2、具体元素变更比较困难。
3、违反了依赖倒置原则，依赖了具体类，没有依赖抽象。
使用场景：1、对象结构中对象对应的类很少改变，但经常需要在此对象结构上定义新的操作。
2、需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免让这些操作"污染"这些对象的类，也不希望在增加新操作时修改这些类。
注意事项：访问者可以对功能进行统一，可以做报表、UI、拦截器与过滤器。

例子

只有开通了贵族，礼物面板上才会有贵族礼物。

设计模式-菜鸟教程学习笔记