java设计模式在项目中的使用场景 一 (编辑中)

Java设计模式在项目中的使用场景(一)

关于设计模式，在Java中是个老生常谈的问题，基于以下几个原因:

   1: 学一遍忘记一遍,每次都感觉会了,过了几天还是大多都忘记了
   2: 网上的关于设计模式的使用案例，很多都是为了模式而模式，很多的例子都比较牵强
   3: 焦虑心理，觉得是不是所有的设计模式都需要掌握，回过头来看，其中有些设计模式都什么玩意儿，真用到项目里面，
      怎么维护，给自己挖坑吧

写篇博文总结一下:

1: 责任链模式

责任链模式是我比较喜欢用的一个模式，适用的场景，通常都是一个触发，会有一系列功能类似、结构类似的事情需要做，比如：
接收到一条报警的kafka消息,具体可能会触发: 
      1: 错误报警
       2: 超时报警
       3: 流量的异常上涨
       4: 流量的异常下跌
       5: 其他可能的报警
责任链模式有很明显的特点:
     1: 这几个需要报警的项目，我可以随意调整，先后顺序不同，无所谓
     2: 从执行结果来看可能仅仅执行一个，但也有可能都执行.
     3: 我可以创建多个责任链，比如第一个责任链配置1,2,第二个责任链都配置,很灵活
这也就是责任链模式自己特殊的点，与网上比较常见的红楼梦传花鼓的案例对比一下，我们看看红楼梦传花鼓有个特点：
     1:  这几个人物的座位是固定的,意味着从一开始，这个流转顺序是固定的
     2:  当鼓声音停下的时候，只有一个人会因为手上有花，而出来酒令
所以在我看来，实际项目中使用的时候，传花鼓，我会选择使用状态模式来实现，而上面这份对比，
恰恰也是责任链模式与状态模式的区别
代码案例:  https://github.com/ylzyqt/reading-integration/blob/master/design/chain.md

2: 状态模式

状态模式也是我比较喜欢用的一个模式，上面写了责任链模式，具体的区别也写出来了，状态模式适用于一系列行为，
这一些列行为会因为状态的变化，而对实际运行结果有影响，也找一个实际使用中的例子：
涉及到用户的项目里面，往往都有个环节,发送短信, 假设公司共签署了3个供应商的短信通道，
分别为A,B,C 通道，根据对方的稳定性，排序从高到低为 A->B-C ,所以具备以下特性:
   1: A->B-C 的顺序是固定的，这是按照稳定性排序得出的结论
   2: 同一条短信，只会在A,B,C 中有一个通道来发送，不会出现多个发送的场景
   3: 这里有个健康度，根据发送的成功率、发送的耗时等因素得出的，命名为状态因子
   执行的结果就是，优先由A发送，加入某天A发生了故障，那么系统得自动切换到B,如果B因为压力的原因，
   那么自动切换到C 由此起到一个分流的作用
   代码案例:
   https://github.com/ylzyqt/reading-integration/blob/master/design/state.md