混合使用太香了：策略设计模式+工厂模式+模板方法模式

轻狂小男生:
我看到有小白，问handler不会很多吗？那有什么用，我告诉你，handler的修改与增加不会导致你的整体代码的可读性，而且我们也不鼓励在核心代码部分加入大量的狗屁判断，能够用抽象的用抽象来代替，如果有一定代码的阅读能力，可以看看源码，源码的优美程度，觉对让你怀疑人生[吃瓜]

【回复】这就是小白和大神的区别了。他们总觉得类多了不好找代码。可以猜测一下，他们的命名方式估计也是随意命名，不然怎么会不好找类嘛。java代码的5大原则之一的开闭原则，能很好的保证代码维护的效率。说怕类多的小白估计是se刚入门，还在main里写逻辑的阶段。所谓无知者无畏，贻笑大方。
【回复】源码优美到不看完看不懂
【回复】回复 @改了名的潮流 :也没有贻笑大方吧，闻道有先后，术业有专攻，如是而已
账号已注销:
视频里说到各种if else嵌套的，判断条件众多，可以弄个链式结构，类似于 Person .name("a") .year(10) .sex("小仙女") .create() 这样需要的参数一目了然， 设计模式是面向对象编程入门基础， 就是耦合的解决方法，提高代码通用性 在各大官方以及三方库源码中都常见使用， 学习成本是一到两天， 写工具类和基础类很常用，方便阅读源码

【回复】大兄弟[笑哭]要搞清楚sex和gender的区别，我是做少儿编程的，之前这么写被一个国外的学生笑死了
【回复】回复 @简单说两句丶 :sex是偏生理上的“性”，男性和女性，当然么也有色情的意思；所以最好用gender，这个是社会化的“性别”，男人女人。
【回复】链式调用不好的一点就是容易产生npe还不好排查 在阿里是不建议使用链式调用的
C-Azure:
我往往不敢改if else，只要还能用。。。 毕竟不是我的代码，而且里面的逻辑往往很复杂，并且涉及到一堆异常中断、线程同步[笑哭] 不过像例子里的那种，一般还是枚举好用吧。。或者直接建个头文件写宏[OK] 不管怎么说，视频赞一个[OK]

【回复】[抠鼻]接手的旧项目，用户权限+增删改权限+自建全权限+项目模式组合起来有几十种，如果只是一个还好说，问题是这玩意有好几十个地方都有判断还各不相同，所以只能继续加if了，没别的办法
【回复】回复 @IT老哥 :这和语言估计已经没关系了，应该是直接接手的老代码，代码结构以及逻辑混乱，改好的bug可能还没有改出来的bug多，项目不大还能直接重构，项目大了要么靠自动测试活下去，要么等着踩雷然后重构。。。。
韭中韭中韭:
底端程序员：代码工整易读，然后被开除。 高端程序员：代码堆在一起谁也看不懂，公司离不开你。 懂了么兄弟们

【回复】怎么可能，我在公司用函数式风格写.Net代码让代码易读也没被开除过呀，比如这样 var onReloadBtnPressed = select from standardEvent.onBtnPressed where x == "ReloadBtn" onReloadBtnPressed.Subscribe(behaviors【x】) [doge][doge][doge]
【回复】写的烂代码，还没过试用期就开除了
IT老哥:
公众号名：IT老哥， 公众号里回复：设计模式demo，即可获取视频里的代码， 回复：Java学习路线，即可获取一份完整的学习路线； 回复：Java全套教程，即可获取Java基础、Java web、Java EE、spring boot等完整学习视频。 回复：Java电子书，即可获取顶级程序员必读的13本书 回复：简历模板，即可获取100份免费的精美简历；

【回复】回复 @都是大舅 :用了这个设计模式主方法里依旧要进行判断什么条件下调用AAA()方法，什么条件下调用BBB（）。最简单的判断方式依旧是if else，不过整体代码可读性提高了。 要么就是用try catch 捕获所有调用的方法，使得没有实现的后续方法依旧可以运行，意思就是不管异常。 大概的意思就是再主方法里调用所有抽象方法 AAA（）、BBB（）、CCC（） 每个方法都添加try catch， 如果张三实现BBB（）方法 那么AAA（）、CCC（）报异常并且异常被捕获，BBB（）方法依旧可以顺利执行。 感觉这种方式更加得不偿失，不过作者思想还是可以借鉴的，如果在模式里中再加上“分组”概念 或许就行解决这个问题
【回复】String name = "张三"; AbstractHandler strategy = Factory2.getInvokeStrategy(name); //strategy.AAA(name); String str = strategy.BBB(name); System.out.println(str); 就跟你这个Junit测试方法一样，这个注释的AAA方法我可能也会用到，BBB也会调用，只是根据name不同，分别调用，这时候不还是要判断name的值么？
【回复】老哥:枚举+Lambda+静态策略方法，可以干掉if else ，还不用创建过多的策略实现类。。[星星眼]
fengyi007:
我也经常这么优化，不过比较懒，用枚举实现的工厂方法模式和策略模式～

【回复】枚举的安全性更高，能够提升编译器检测能力
怀秋___:
这个真的可以，我在实习，看到同事写的屎一样的代码，还让我改，if else嵌套十多个属实恶心[翻白眼]

【回复】你这还算好 我实习第二周开始改东西补接口 注释什么p都没有 几千行代码几千行sql慢慢改 所有数据全部map封装还是没有注释 还有各种逻辑错误的 又写了一堆sql判断[无语]
【回复】哈哈，十几个if 嵌套属实牛批
【回复】回复 @彃哩彃哩彈幕網 :[疑惑]这种人咋进的
怎么说不会改:
如果公司if else有上千行，说明不是好公司，首先好公司review就让你过不了

【回复】就算大厂，也有这种情况的，因为有很多的老代码，还有就是有的并不重视这个review的过程，就是走个过场
【回复】回复 @有点谱 :初期项目急着上线，根本没有那么多review
【回复】公司如果引用了sonar之后，这种代码连sonar都过不了的
小白同学学AI:
问题：取代大量的if-else 解决方案：三行代码 01:18 策略模式 if-else里面的逻辑抽出来写成策略 Bean类 引入Handler（） 02...

【回复】我用工厂模式加策略模式直接报空
我的Future:
这样理论上是不可以的吧 Spring的初始化代码刚走完就放到工厂Map中会有一个很大的bug 如果有后置处理器对Bean进行包装的话 那么放到Map中的对象和本身的Bean对象就不一样了。举个例子 如果Bean使用了@Transactional注解 那么Bean就会被后置处理器中处理而生成了代理对象 但是这个Bean被提前放到了Map中(这边需要理解Bean的整个生命周期)，所以并不是代理对象，那么整个注解也就会失效了。个人见解，错误勿喷。

【回复】针对这种情况,可以实现SmartInitializingSingleton接口,在所有bean创建生命周期完成后执行
【回复】也可以不用注册到map中，就每次把容器中的Bean策略类集合拿过遍历，然后进行匹配就行了
【回复】按照你这个意思，那最后不是有两个bean？一个是map中的普通对象，还有一个代理对象。这明显不对啊
WasYesterday:
不知道现在评论up能不能看到，其实即然up主提到这个视频是对代码的优化。那么up对if else结构优化可能疏忽了一个关键性问题，甚至在高吞吐情况带来致命的问题。if ese有一个分支预测的概念，很多人都知道if eles命中了第一个分支后续就不会再判断了，但在实现业务代码时却没几个人利用了这一点。实际业务中多个分支逻辑在使用率上来说几乎是一边倒，基本上一个常用条件占到了7，8成以上。而你的handle也只是匹配，map也是无序的。匹配算法应该单独把高命中handle单独提出来。up讲的设计模式思路非常棒，但对if else的结构优化浅层的问题反而最容易忽视，也许当初留下这段代码的人反而是高明且朴素的做法（扫地僧），后来人反而在浅显的第一层评头论足[妙啊] 我觉得up可以在出个视频讲讲，这才是编程中拔云见雾，简单而不简单

【回复】[doge]up不是让你使用设计模式替代所有的if-else....在实际开发中,代码会根据业务类型走不同类型的逻辑调用,而这部分的业务逻辑提前用设计模式拆出来,在后期维护上是很方便的,在子handle中...if-else还是会正常有的,你把每个子handle想想成200行代码的方法类,如果不拆出来,原来的业务逻辑可能是1000行左右,如果后期继续增加判断类型,那后者为了减少阅读前人的代码,不可避免的会使用if-else之前的代码作为业务流程,这样就会造成变量和作用域的耦合,再后期维护和优化的时候,这些代码会牢牢的粘在一起,再也拆不出来,就是传说中的si山
【回复】我觉得没啥问题吧，map虽然无序，但你传的参数就是key，直接就根据key取出来了，又不是list要遍历到传的参数相等的为止，up的这种设计高命中只取决于你的参数
凑合凑合12138:
知识点get到了，谢谢up分享。 我在说下我的看法，大多数if的判断条件，都比较迷，会涉及多个变量，要确定handler的key又要一坨if else，或者key的形式也要经过特殊设计。 还有就是数据访问的问题，流程优化了，可能出现变量作用域的问题。 最后，up现在视频的目的是提高自己的技能，如果是完全的新功能第一次写可以，工作中大部分是维护和增加现有的逻辑，这时还是不要拿来试手了，为了加一个分支，你改了一片代码，真犯不上。 最后支持up，[热词系列_三连]

【回复】回复 @云朵上的小蚂蚁 :我的意思就是工作中遇到祖传代码si山，别觉得自己能行去搞什么优化重构啊[笑哭][笑哭][笑哭]
【回复】回复 @遇见Happiness :软件构造？的实验？啥⊙∀⊙？
缺钱找我准没错:
老哥太刚了，一点多还在录视频，所以大家可以给我一个赞吗[微笑]

鱼戏莲叶混:
讲到点上了，平时增删改做多了，也没用到什么高级的东西，很想让写的代码看起来高大上，我平时看我自己写的代码真是low的一批

【回复】嗯嗯，写业务代码的时候可以多用用设计模式，也是提高技术的方法
【回复】多用map，那个value不单单可以是任何对象，接口，函数指针
IT老哥:
公众号回复：设计模式demo，即可获取百度云链接，公众号名：IT老哥

【回复】回复 @都是大舅 :公众号名：IT老哥
超级大力喷子出奇迹:
有时候你把问题想复杂了！不过你为了举例子把设计模式引用进去还是很不错的！但实际工作中这是个大忌！用简单可靠安全的方式来重构冗余代码才是让人放心的方式！例如函数改造！

【回复】show me the code~一段文字又不展示代码
热情好客阿卡姆:
面对大量if-else模式时我喜欢用散列表优化

哈哈-艾特-逗儿:
真心感谢老哥，我感觉自己开悟了[呲牙][呲牙]