实际项目运用之Filter模式(过滤器模式)

1 模式简介 1.1 定义 过滤器模式(Filter)也叫条件模式(Criteria),这种模式允许开发人员使用不同的标准来过滤一组对象,通过逻辑运算以解耦的方式把它们连接起来。当我们想要选择满足一个或多个条件的对象子集时,此设计模式非常有用。它属于结构模式。 1.2 优点 它提供了一种根据特定条件过滤对象的方法 我们可以随时添加新过滤器,而不会影响客户端的代码 我们可以在程序执行期间动态选择过滤器 1.3 过滤器设计 角色 过滤器(Filter) - 过滤器在请求处理程序执行请求之前或之后,执行某些任务 过滤器链(Filter Chain) - 过滤器链带有多个过滤器 过滤对象 (Target)- 需要过滤的数据源对象 过滤管理器(Filter Manager) - 过滤管理器管理过滤器和过滤器链 客户端(Client) - Client 是向 Target 对象发送请求的对象 代码演示 Filter public interface Filter { public void execute(String request); } AuthenticationFilter public class AuthenticationFilter implements Filter { public void execute(String request){ System.out.println("Authenticating request: " + request); } } FilterChain

实际项目运用之State模式(状态模式)

1 模式简介 定义: 状态模式允许对象在内部状态改变时改变它的行为,对象看起来好像修改了它的类。这个模式将状态封装成独立的类,并将动作委托到代表当前状态的类的对象 状态模式的优点: >封装了转换规则 枚举可能的状态,在枚举状态之前需要确定状态种类 将所有与某个状态有关的行为放到一个类中,可方便增加新的状态 允许状态转换逻辑与状态对象合成一体,而非复杂条件语句块 可以让多个环境对象共享一个状态对象,从而减少系统中对象的个数 状态模式的缺点: >增加系统类和对象的个数 结构与实现都较为复杂,如果使用不当将导致程序结构和代码的混乱 对”开闭原则”的支持不太好,增加新状态类需在状态类上增加行为方法 状态模式的适用场景: 1. 对象的行为依赖于它的状态,并且可以在运行时根据状态改变行为。 2. 代码中包含大量与对象状态有关的if/else语句 3. 接口幂等要求 状态模式和策略模式: 相同点是它们都需要根据需求选择相应的状态或策略 不同点是状态模式是在一个类中通过不同的动作切换不同的状态,而策略模式是为一个类选择某个策略,即状态模式中的Context是和多个状态关联的,而策略模式中的Context只和一个策略关联 状态模式角色介绍: (1)Context类,依赖倒置原则,通过适配器模式维护状态类 (2)State:抽象状态类或状态接口,用以抽象封装行为 (3)ConcreteState类:具体状态类,实现了State中的抽象方法 2 实际运用 借贷平台的订单,有审核-发布-抢单 等等 步骤,随着操作的不同,会改变订单的状态,通常通过if/else判断订单的状态,从而实现不同的逻辑,伪代码如下: if(审核){ //审核逻辑 }elseif(发布){ //发布逻辑 }elseif(接单){ //接单逻辑 } 上述解决方案缺点非常明显:这类代码难以应对变化,在添加一种状态时,我们需要手动添加if/else,在添加一种功能时,要对所有的状态进行判断。因此代码会变得越来越臃肿,并且一旦没有处理某个状态,便会发生极其严重的BUG,难以维护 2.1 状态模式应用 状态模式本质上是一种基于状态和事件的 状态机 ,下面是订单流程的状态图 通过状态图,我们再设计一张横纵坐标关系表来比较,图如下: 通过上述表 我们可以细化为一个二维数组,来表示状态与事件直接的关系: 2.2 代码实现 我们通过状态的各种图例分析来用代码实现逻辑 状态枚举类 public enum StateEnum { //订单生成 GENERATE(1, "GENERATE"), //已审核 REVIEWED(2, "REVIEWED"), //已发布 PUBLISHED(3, "PUBLISHED"), //待付款 NOT_PAY(4, "NOT_PAY"), //已付款 PAID(5, "PAID"), //已完结 FEED_BACKED(6, "FEED_BACKED"); private int key; private String value; StateEnum(int key, String value) { this.

实际项目运用之Responsibility-Chain模式(责任链模式)

1 模式概要 1.1 简介 责任链模式为请求创建一个接收者对象链,每个接收者都包含对另一个接收者的引用,如果一个对象不能处理该请求,那么它会把请求传给下一个接收者,依此类推 责任链模式避免了请求的发送者和接收者耦合在一起,让多个对象都有可能接收请求,将这些对象连成一条链,并且沿着这条链传递请求,直到有对象处理它为止 1.2 责任链模式优缺点 优点 >降低耦合度。它将请求的发送者和接收者解耦 简化了对象,使得对象不需要知道链的结构 增强给对象指派职责的灵活性,允许动态地新增或者删除责任链 增加新的请求处理类方便 缺点 >不能保证请求一定被接收; 系统性能将受到一定影响,调试时不方便,可能会造成循环调用 2 模式结构 2.1 对象定义 *Handler(抽象处理者)*: 定义一个处理请求的接口,提供对后续处理者的引用 *ConcreteHandler(具体处理者)*: 抽象处理者的子类,处理用户请求,可选将请求处理掉还是传给下家;在具体处理者中可以访问链中下一个对象,以便请求的转发 2.2 类图及设计 代码详解: 抽象处理者 public abstract class Handler { protected Handler nextHandler; // 下一个责任链成员 public Handler getNextHandler() { return nextHandler; } public void setNextHandler(Handler nextHandler) { this.nextHandler = nextHandler; } // 处理传递过来的时间 public abstract void handleMessage(int type); } 具体处理者 在当前处理者对象无法处理时,将执行权传给下一个处理者对象 :::java public class ConcreteHandler1 extends Handler { @Override public void handleMessage(int type) { if (type == 1 || type == 3) { System.

设计模式之单例模式终极版【克隆-序列化-反射】

1 基本内容 1.1 概念 单例模式,是指在任何时候,该类只能被实例化一次,在任何时候,访问该类的对象,对象都是同一个。只要是程序员都会使用到,甚至都不能算是设计模式。但是在我们使用中也需要了解一下单例特性和使用场景 1.2 模式优缺点 单例模式有以下优点: >使用单例模式可以严格的控制用户怎样以及如何访问它 节约系统资源,提高系统的性能 单例模式有以下缺点: >不易扩展 单例类职责过重,在一定程度上违背了“单一职责原则” 如实例化对象长时间未使用,会GC回收,导致对象状态的丢失 # 2 单例模式分类 2.1 饿汉模式 public class SingletonEHan { private SingletonEHan() {} /** * 1.单例模式的饿汉式 */ private static SingletonEHan singletonEHan = new SingletonEHan(); public static SingletonEHan getInstance() { return singletonEHan; } // SingletonEHan instance= SingletonEHan.getInstance(); /** * 2. 单例模式的饿汉式变换写法 * 基本没区别 */ private static SingletonEHan singletonEHanTwo = null; static { singletonEHanTwo = new SingletonEHan(); } public static SingletonEHan getSingletonEHan() { if (singletonEHanTwo == null) { singletonEHanTwo = new SingletonEHan(); } return singletonEHanTwo; } // SingletonEHan instance= SingletonEHan.

实际项目运用之Adapter模式(适配器模式)

1. 模式简介 适配器模式解决的问题:让原本因为接口不兼容而不能一起工作的类可以一起工作 适配器模式中有三种角色: 目标接口Target:用户期望的类,可以是接口,也可以是抽象类或具体类; 需要适配的类Adaptee:当前系统中有的类; 适配器Adapter:在现有接口和目标接口之间的“适配者” 适配器模式的优点: 通过适配器模式,用户在做相似的操作时可以调用同一个接口,其内部过程对于用户是透明的,这样做更简单、更直接、更解耦; 复用了现存的类,解决了现存类和复用环境要求不一致的问题; 将目标接口和现有接口解耦,通过引入一个适配器类,而无需修改原有的代码。 适配器模式的缺点: 使用适配器模式后,如果想要改变适配对象,就需要更换适配器,而更换适配器是一个非常复杂的过程。 适配器模式的适用场景: > 当系统需要使用现有的类,而现有的类不符合系统的接口 当期望的功能和系统中现有的某个类的功能相似,但是具有不同的接口 当系统已经实现某功能,但用户想通过另种接口方式访问,而不想修改原有接口 当使用的第三方组件的接口和系统中定义好的接口不同,不希望修改系统接口 2.案例代码 适配器分类_适配器模式_和对象适配器模式 2.1 类适配器UML 2.2 对象适配器模式UML 2.3 案例代码: 被适配对象 public class Adaptee { public void adapteeMethod() { System.out.println("这是我们已经实现的功能!"); } } 对象适配器 public class Adapter implements Target { private Adaptee adaptee = new Adaptee(); @Override public void targetMethod() { adaptee.adapteeMethod(); } } 目标接口

设计模式之Template模式(模版模式)

1 模式简介 1.1 模版方法模式的定义: 模版方法模式在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中。模版方法使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。 1.2 结构 1.3 模式的组成 抽象类(AbstractClass): 定义抽象的原语操作(primitive operation) ,具体的子类将重定义它们以实现一个算法, 实现一个模板方法,定义一个算法的骨架。该模板方法不仅调用原语操作,也调用定义。 具体子类 (ConcreteClass): 实现原语操作以完成算法中与特定子类相关的步骤。 1.4 优缺点 模版方法模式的优点:  封装不变部分,扩展可变部分;  提取公共代码,便于维护;  行为由父类控制,子类实现。 模版方法模式的缺点:  每一个不同的实现都需要一个子类来实现,导致类个数增加,使系统更加庞大 模版方法模式的适用场景:  当类中有多个子类共有的方法  当有重要的、复杂的方法时,可以考虑作为模板方法 2 案例 抽象类 @FunctionalInterface public interface MyPredicate<T> { boolean test(T t); /** *过滤用户 */ default List<Employee> filterEmployee(List<Employee> emps, MyPredicate<Employee> mp) { List<Employee> list = new ArrayList<>(); for (Employee employee : emps) { if (mp.

实际项目运用之Strategy模式(策略模式)

1. 策略模式概要 策略模式是对算法的包装,是把使用算法的责任和算法本身分割开来,委派给不同的对象管理。策略模式通常把一个系列的算法包装到一系列的策略类里面,作为一个抽象策略类的子类。用一句话来说,就是:“准备一组算法,并将每一个算法封装起来,使得它们可以互换”。 下面就以一个示意性的实现讲解策略模式实例的结构。  这个模式涉及到三个角色:  ● 环境(Context)角色:持有一个Strategy的引用。  ● 抽象策略(Strategy)角色:这是一个抽象角色,通常由一个接口或抽象类实现。此角色给出所有的具体策略类所需的接口。  ● 具体策略(ConcreteStrategy)角色:包装了相关的算法或行为。 1.1 案例代码 策略模式上下文 public class Context { //持有一个具体策略的对象 private Strategy strategy; /** * 构造函数,传入一个具体策略对象 * @param strategy 具体策略对象 */ public Context(Strategy strategy){ this.strategy = strategy; } /** * 策略方法 */ public void contextInterface(){ strategy.algorithmInterface(); } } 抽象策略类 public interface Strategy { /** * 策略方法 */ public void algorithmInterface(); } 具体策略类 public class ConcreteStrategyA implements Strategy { @Override public void algorithmInterface() { //相关的业务 } } public class ConcreteStrategyB implements Strategy { @Override public void algorithmInterface() { //相关的业务 } } public class ConcreteStrategyC implements Strategy { @Override public void algorithmInterface() { //相关的业务 } } 客户端

实际项目运用之Decorator模式(装饰器模式)

1 概述 在项目中,经常因一些新增需求,导致同一业务的变更,如果所在类继承关系如下:Parent、Child、Grandparent,那么要在Child类上增强些功能怎么办?给Child类增加方法?那会对Grandparent产生什么影响?该如何去处理?看完本文,你会找到你的答案。 JavaIO中,像下面的嵌套语句很常见,为什么要怎样定义呢?理解装饰模式后,你会找到答案。 FilterInputStream filterInputStreasm = new BufferedInputStream(new FileInputStream(new File("/user/a"))); 1.1案例 例如下面一个功能需求,4s店的汽车销售向客户推销自家品牌的产品,我们用代码实现,关系如下: 具体代码: 汽车销售类 public abstract class CarSale { /** * 推销车的详情 */ public abstract void displayCarInfo(); /** * 客户签订购买合同 */ public abstract void signContract(String customerName); } 汽车参数详情 public class CarInfo extends CarSale { @Override public void displayCarInfo() { System.out.println("日本丰田GTR"); System.out.println("百公里加速1秒"); System.out.println("油耗偏高"); System.out.println("后驱涡轮增压"); System.out.println("内饰豪华"); System.out.println("发动机噪音偏大"); System.out.println("不支持电动座椅,后视镜加热"); } @Override public void signContract(String customerName) { System.out.println("客户签约销售合同, 付款人:" + customerName); } } 客户

设计模式之builder模式

建造者模式也叫生成器模式,和抽象工厂模式相似,也是一种构建复杂对象的模式。 建造者模式中的角色分类:  抽象建造者Builder:接口类型,用于规范各个产品的组成部分;  具体建造者ConcreteBuilder:实现Builder中的所有方法,返回一个产品实例;  指导者Director:指挥建造者制造相应的产品  产品Product:用户最终看到的复杂对象。 假设我们有一个向客户发送新年祝福邮件的需求,而邮件内容可以是纯文档的,也可以是有动画的,也可以是有音频的,可以动态的添加个组件 uml下图所示: 如上图所示,邮箱有多个组件,包含收件人,发送人,内容,音乐等 通过具体的建造者添加不同的组件模版,最后通过指挥者去调用抽象建造者 来返回具体的email对象 代码如下 ==================product====================== public interface Module { String showInfo(String info); }` public abstract class CommonModule implements Module { protected String moduleName; protected String productionTime() { return Optional.ofNullable(moduleName).orElse("") + "--> createTime : " + LocalDate.now().toString(); } } public class Sender extends CommonModule{ public Sender() { super.moduleName = "发件人"; } @Override public String showInfo(String info) { return Optional.ofNullable(info).orElse("sender : nicky@qq.

设计模式之factory模式

定义:工厂模式通俗意义上讲就是一个多产品的流程化工厂,每个工厂生产同一系列相关性的组件 分类: 按工厂职能划分可以分为三类:  简单工厂模式(Simple Factory)  工厂方法模式(Factory Method)  抽象工厂方法(Abstract Factory) 接下来我们直接通过uml图和具体的代码实现以上三类 我们以汽车工厂生产汽车为例,本田工厂假设要生产CIVIC和CRV两种车型,那么我们该怎么去设计实现 1 简单工厂模式 工厂产品线流程如上图所示:工厂生产汽车通过指定汽车的编号,我们就可以走指定的产品线;调用者只需要选择具体车型而不需要内部车是怎么制造出来的 简单工厂模式主要包括三部分: 工厂角色:上图中的HONDAFactroy 生产车型用 抽象产品角色:上图中的HONDA和HONDACar 包含通用的属性和方法 具体产品角色:上图中的CIVIC和CRV,具体的车型包含各种参数 代码如下 /** * @author nicky_chin [shuilianpiying@163.com] * @since –created on 2017/12/27 at 11:11 */ public class CIVIC extends HONDACar implements HONDA { private String carName; private Double price; public CIVIC() { this.carName = "10代思域"; this.price = 158000.9; } @Override public String introduceCar() { return "CIVIC{" + "carName='" + carName + '\'' + ", price=" + price + "} " + super.