• 密码123456
    2019-08-01
    责任链。最常见到的就是接收http请求了。帮我们转码,转化成实体类,等等。策略模式。最常简单和用到的就是集合排序,自定义排序规则。装饰器,最常见到的就是各种流,比如字符流,字节流等

    作者回复: 👍🏻

    
     17
  • QQ怪
    2019-08-01
    老师这个案例来的太及时了,正想重构公司订单优惠劵红包扣除这方面的代码,真的是及时雨啊?厉害厉害👍🏻
    
     8
  • nightmare
    2019-08-01
    netty中的pipeline,tomcat中的filter,属于责任链, springmvc中对参数解析的就是 策略模式,每一个参数类型一个实现类,用for循环解析参数 java. io就是经典的装饰器模式

    作者回复: 有读源码习惯👍🏻

    
     6
  • CCC
    2019-08-01
    有几个今年秋招的!举个手!老师的课程真的收获很多!
    
     5
  • 李英权
    2020-02-05
    每次看到有人这样做装饰器或者策略模式的初始化,都觉得很可惜,因为这徒增了很多麻烦,其实完全可以把装饰器或策略实现作为枚举值的成员变量 初始化到枚举类型中。无论是以后扩展还是平时使用 都非常简单自然。
    
     1
  • 奋斗的小白鼠
    2019-12-04
    老师,问一个小白问题,产品Map<PromotionType, SupportPromotions> supportPromotions; //支持促销类型 怎么存入数据库了?

    作者回复: 简单的将SupportPromotions促销类型存储起来就好了

    
     1
  • 飞鸽
    2019-09-06
    促销、红包这种情况复杂多变。基于规则配置处理更好。
    
     1
  • 疯狂咸鱼
    2019-09-01
    老师,为什么java io是装饰器模式

    作者回复: 我们知道,InputStream是直接读写文件的,除了InputStream,在其上层还有BufferedInputStream、DataInputStream等其他修饰类,增加了缓存读取、类型读取等功能,相当于InputStream之上加了很多修饰功能,在所以它是一个装饰器模式。

    
     1
  • 峰
    2019-08-02
    感觉老师在红包这个例子里面,其实最重要的解耦是装饰器实现的各种基本的优惠打折手段与工厂的各种优惠规则比如红包抵用券可叠加等等。

    作者回复: 对的,主要用来优化业务的复杂度。

    
     1
  • 冯传博
    2019-08-01
    希望能有个类图,这样就能一目了然的看清楚各个类之间的关系了

    作者回复: 好的,后续补上

    
     1
  • -W.LI-
    2019-08-01
    public BigDecimal countPayMoney(OrderDetail orderDetail) {
            BigDecimal payTotalMoney = new BigDecimal(0);
            payTotalMoney = super.countPayMoney(orderDetail);
            payTotalMoney = countCouponPayMoney(orderDetail);
            return payTotalMoney;
        }
    老师好!这里为啥要调用父类的countPayMoney()方法啊?
    责任链模式:感觉责任连模式比较固定不怎么会变一层往一层调用,解耦,某一层变了不影响别的层。
    策略模式:策略模式,虽然也是封装了很多不同的策略,但是使用时一般一次只选一个实现类使用,不会有嵌套。
    装饰者模式:责任链有的优点他都有,装饰者还能动态组合。
    谢谢老师,希望给出详细答案谢谢
    展开

    作者回复: 由于我们这里考虑到灵活的组合模式,所以需要调用父类的countPayMoney()方法。

    
     1
  • wuyin
    2019-12-03
    public static BigDecimal getPayMoney(OrderDetail orderDetail) { //获取给商品设定的促销类型 Map supportPromotionslist = orderDetail.getMerchandise().getSupportPromotions(); //初始化计算类 IBaseCount baseCount = new BaseCount(); if(supportPromotionslist!=null && supportPromotionslist.size()>0) { for(PromotionType promotionType: supportPromotionslist.keySet()) {//遍历设置的促销类型,通过装饰器组合促销类型 baseCount = protmotion(supportPromotionslist.get(promotionType), baseCount); } } return baseCount.countPayMoney(orderDetail); }
    baseCount只会有一种优惠类型吧,怎么进行组合计算呢
    展开

    作者回复: 这里的场景是多个叠加优惠

    
    
  • neohope
    2019-11-24
    老师您好,想请教一下,在实际做优惠活动时,很多活动策略之间是相互排斥的,用了优惠1就不能用优惠2,用了优惠2就不能用红包。这种自动选择最优优惠策略,在哪里实现比较合理呢?多谢!

    作者回复: 也可以基于该模式实现,我们只需要将叠加逻辑改成选择最优逻辑即可。

    
    
  • 依然亦晨
    2019-09-21
    老师,有个疑问,促销类型类里看到用了clone方法,原型模式,为什么后边都没用调用clone方法的地方呢?

    作者回复: 对的,没有使用,可以忽略

    
    
  • 风轻扬
    2019-09-18
    老师,知行合一同学提的问题。
    BigDecimal payTotalMoney = new BigDecimal(0);
    payTotalMoney = super.countPayMoney(orderDetail);
    payTotalMoney = countCouponPayMoney(orderDetail);
    payTotalMoney不就被覆盖了吗?
    这里的super.countPayMoney()是不能去掉的。去掉就报空指针
    RedPacketDecorator中的super代表的是BaseCount,super.countPayMoney()承担着计算总额的任务。
    CouponDecorator中的super代表的是RedPacketDecorator,这里的super.countPayMoney()承担着计算计算红包优惠额的任务。
    两个super.countPayMoney都不可以省略的。
    望老师明示
    展开

    作者回复: super.countPayMoney(orderDetail)主要是计算了orderDetail中的paymoney,这里写的可读性不是很好,可以这样理解:

    BigDecimal payTotalMoney = new BigDecimal(0);
    super.countPayMoney(orderDetail);//计算paymoney;
    payTotalMoney = countCouponPayMoney(orderDetail);//计算优惠后的价格;

    
    
  • 风轻扬
    2019-09-16
    老师,装修功能里面的BaseDecorator为什么要用abstract修饰呢?也没有抽象方法呢

    作者回复: 这是一个抽象基类,没有特别的,方便后面扩展

    
    
  • godtrue
    2019-09-13
    😀老师,装饰器模式的性能优化点在哪里?是不是加速了研发调整代码扩展代码的速度!

    作者回复: 代码易扩展,逻辑清晰

    
    
  • 疯狂咸鱼
    2019-09-01
    老师你讲的太好了,要加餐加餐
    
    
  • Gred
    2019-08-14
    老师您这段优化的装饰器模式代码里面,就用到装饰器、责任链以及工厂模式。不愧是老师,厉害厉害。
    
    
  • Gred
    2019-08-13
    老师,您在SupportPromotions重写 clone 方法,只对类进行拷贝,但是成员变量只是浅拷贝,如果要实际应用业务场景,是不是应该改用深拷贝,避免其他订单的优化券等信息影响到了。
    
    
我们在线,来聊聊吧