今天要跟大家聊的是状态模式(State Pattern),它描述的是程序因为内部状态发生转变而有不同行为的情况。比如说自动售货机,当用户把钱塞入投币处,对于自动售货机来说,它的投币状态变成了已投币,于是它的行为也发生了变化——将货物移动到取货处。完成后,自动售货机的投币状态又转移回了未投币,于是它的行为又发生了变化——不出货。
责任链模式(Chain of Responsibility Pattern)也是一种极为常见的设计模式,如 Servlet 规范中的过滤器、Spring 中多个 AOP 的链式处理、OA 系统多级主管流程审批等等,这些都是责任链模式的实际业务场景应用。
策略模式(Strategy Pattern)从某种意义上可以说是面向对象程序设计特性之一的多态的一种应用,它描述的是为了达成某种目的而存在多种可供选择的实现方式的情况,我们将这些可供选择的实现方式命名为策略,各个策略具体的实现内容不尽相同,但是它们达成的结果都是一致的。
之前谈到年初公司项目基于 DDD 思想进行领域重构时应用到了门面模式,今天来说说重构时运用到的另一种设计模式——模板方法模式(Template Method Pattern)。
今天要跟大家聊的是观察者模式(Observer Pattern),观察者模式非常容易理解,好比说微博,用户关注了明星成为其粉丝,每当明星发布微博的时候总是会给用户发送一条消息推送通知。
今天要跟大家聊的是享元模式(Flyweight Pattern),顾名思义享元就是共享元信息。为什么要共享元信息?有两个原因,第一是创建元信息的过程可能比较耗时、耗费资源;第二是元信息内容重复率较高,每次都创建新的内容一致的资源并没有意义。
今天要跟大家聊的是组合模式(Component Pattern),需要强调的是:这里说的组合与之前在桥接模式中就提到过“以组合代替继承”思想中的“组合”不是一个概念。后者是指将A类变成B类的属性,以此来实现B类获得A类的能力的行为,而前者则是将相似对象组合成一组可被调用的树形数据结构的一种设计思想。
事实上,门面模式在传统 Dao-Service-Controller 分层架构中极为常见。试着回想一下,你定义的 Controller 是不是一般只有一些 Service 的调用,只涉及一些逻辑判断,不会有具体的业务逻辑在 Controller 代码块中?如果有,那可能是你分层分的不够彻底吧。
相比于装饰器模式而言,适配器模式在实际项目中的运用更加广泛,并且只要有适当的工作经验(三年以下),就一定用到过这种设计模式。举个例子,张三负责的交易中心提供了一个抽象且通用的创建订单接口,该接口原本是给系统内部的其他业务中心提供的,现在万恶的产品经理又提了一个新需求——交易中心的创建订单接口需要暴露给外部系统,将用户在第三方平台下的单导入到本平台中,用于后续对用户进行营促销活动。
装饰器模式的应用极为广泛,连 JDK 源码都将它奉为瑰宝,众多 IO 类就是适配器模式的最佳实践。