状态模式在实际开发中的应用
这雾霾很严重:
如果要新增状态怎么办。比如说现在要加个评价状态,那岂不是要在抽象类和已经存在的所有状态类都加上一个评价的方法,破坏开闭原则
【回复】回复 @Lifetimeout : 开闭原则是对拓展开放,加方法是拓展,并没有修改之前的方法。每个状态类都新加一个方法,这已经很优雅了。
【回复】回复 @程序猿一枚-有风 : 可以针对这种出一期状态机吗
【回复】回复 @杀死彼得潘 :可以有默认实现,用抽象类也行,用接口也行,不过这样写的话逻辑就写死了。我目前正在搜索更好的办法,等有了更新一讲新的,实在找不着就认了纳格兰の夏:
第一个问题:什么情况下会在paid、ship、receive之后再重新调用这3个方法中的任何一个?
【回复】回复 @下落冬没 : 感觉有用的地方,就是订单状态校验
【回复】我也觉得,感觉没什么场景具体。他们本来就是属于单独的动作,不是连贯动作。 动作完成接口就返回了萨满的法杖:
[滑稽][滑稽][滑稽],你猜为啥spring体系里面很少有人这样写?纳格兰の夏:
第二个问题:order类里增加了状态对象和相关的行为方法,这就变成了一个充血模型,那么我在从数据库获取订单的时候,怎么维护这个状态对象?SHANGTTTTT:
状态模式是同样的方法不一样的结果(没钱状态下吃霸王餐,有钱状态就付钱),策略模式是同样的方法不同的策略相同的结果(用支付宝微信都是付钱了)。KwanKwan爱睡觉:
Up可以了解下Spring的状态机模式,有助于打开状态模式的新世界[吃瓜]
【回复】结合spring的状态机模式,代码会更简洁,扩展性更强我擦勒哟:
大佬,每期的源码可以传到github吗?这样方便一些星の翼:
请教一下 真的做幂等还是要在数据库里面核验吧 状态模式不保证幂等浑水摸鱼的陈教主:
up您好,请问源码可以分享一下吗[打call]