设计模式④ :分开考虑

这篇具有很好参考价值的文章主要介绍了设计模式④ :分开考虑。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一、前言

有时候不想动脑子,就懒得看源码又不像浪费时间所以会看看书,但是又记不住,所以决定开始写"抄书"系列。本系列大部分内容都是来源于《 图解设计模式》(【日】结城浩 著)。该系列文章可随意转载。

二、Bridge 模式

Bridge 模式 :将类的功能层析结构与实现层次结构分离。

1. 介绍

Bridge 模式的作用是将两种东西连接起来,它们分别是 类的功能层次结构 和 类的实现层次结构,但是通常来说,类的层次结构不应当过深。

  • 类的功能层次结构 :在父类中具有基本功能,在子类中增加新的功能。这种层次结构成为 类的功能层次结构。
  • 类的实现层次结构:父类通过声明抽象方法来定义接口,子类通过实现具体方法来实现接口。这种层次结构称为 类的实现层次结构。

Bridge 模式登场的角色

  • Abstraction (抽象化) : 该角色位于“类的功能层次结构”的最上层,他使用 Implementor 角色的方法定义了基本的功能。该角色保存了 Implementor 角色的实例。在示例程序中,由 Display 类扮演此角色。
  • RefineAbstraction (改善后的抽象化) :在 Abstraction 角色的基础上增加了新功能的角色。在示例程序中,由 CountDisplay 类扮演此角色。
  • Implementor (实现者) :该角色位于“类的实现层次结构”的最上层,他定义了用于实现 Abstraction 角色的接口的方法。在示例程序中由 DisplayImple 类扮演此角色。
  • ConcreteImplementor (具体实现者) :该角色负责实现在 Implementor 角色中定义的接口(API)。在实例程序中,由 StringDisplayImple 类扮演该角色。

类图如下,左侧的两个类构成了“类的功能层次结构”,右侧的两个类构成了“类的实现层次结构”。类的两个层次结构之间的桥梁是 impl 字段:
设计模式④ :分开考虑,# 《图解设计模式》,设计模式


Demo 如下:

// 类的功能层次结构
public class Display {
    private DisplayImpl impl;

    public Display(DisplayImpl impl) {
        this.impl = impl;
    }

    public void open() {
        impl.rawOpen();
    }

    public void print() {
        impl.rawPrint();
    }

    public void close() {
        impl.rawClose();
    }
}
// 类的实现层次结构
public interface DisplayImpl {
    void rawOpen();

    void rawPrint();

    void rawClose();
}

// 类的实现层次结构
public class StringDisplayImpl implements DisplayImpl {
    @Override
    public void rawOpen() {
        System.out.println("StringDisplayImpl.rawOpen");
    }

    @Override
    public void rawPrint() {
        System.out.println("StringDisplayImpl.rawPrint");
    }

    @Override
    public void rawClose() {
        System.out.println("StringDisplayImpl.rawClose");
    }
}

// 类的功能层次结构
public class CountDisplay extends Display {
    public CountDisplay(DisplayImpl impl) {
        super(impl);
    }

    public void multiDisplay() {
        for (int i = 0; i < 3; i++) {
            print();
        }
    }
}

public class BridgeDemoMain {
    public static void main(String[] args) {
        Display display1 = new Display(new StringDisplayImpl());
        Display display2 = new CountDisplay(new StringDisplayImpl());
        display1.display();
        System.out.println("--------------------------------");
        display2.display();
        System.out.println("--------------------------------");
        ((CountDisplay)display2).multiDisplay();
    }
}

输出结果:

设计模式④ :分开考虑,# 《图解设计模式》,设计模式
综上:通过 CountDisplay 类完成了对 Display 类的方法扩展,即类的功能层次结构扩展。通过 DisplayImpl 类完成了与 Display 的解耦,Display 将 open、print、close 方法委托给了 impl 来实现,即类的实现层次结构扩展。

2. 应用

  • Spring 中的 BeanPostProcessor 接口:在 Spring 中 Bean 创建前后会调用 BeanPostProcessor 的方法来对 Bean进行前置或后置处理,而 BeanPostProcessor 具有很多子接口,如 InstantiationAwareBeanPostProcessor 、MergedBeanDefinitionPostProcessor 等,其子接口都各自增加了自己的方法。如下接口定义:

    public interface BeanPostProcessor {
    	@Nullable
    	default Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
    		return bean;
    	}
    	@Nullable
    	default Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
    		return bean;
    	}
    
    }
    
    
    public interface InstantiationAwareBeanPostProcessor extends BeanPostProcessor {
    
    	@Nullable
    	default Object postProcessBeforeInstantiation(Class<?> beanClass, String beanName) throws BeansException {
    		return null;
    	}
    
    
    	default boolean postProcessAfterInstantiation(Object bean, String beanName) throws BeansException {
    		return true;
    	}
    
    	@Nullable
    	default PropertyValues postProcessProperties(PropertyValues pvs, Object bean, String beanName)
    			throws BeansException {
    
    		return null;
    	}
    
    
    	@Deprecated
    	@Nullable
    	default PropertyValues postProcessPropertyValues(
    			PropertyValues pvs, PropertyDescriptor[] pds, Object bean, String beanName) throws BeansException {
    
    		return pvs;
    	}
    
    }
    


个人使用:该部分内容是写给自己看的,帮助自身理解,因此就不交代项目背景了,读者请自行忽略(◐ˍ◑)

  • 项目A中需要对文件进行解析,当时为了兼容各种文件,定义了文件解析委托类,并且在此基础上进行了扩展,如下,不同的文件类型基于自身的特性实现不同的接口来完成基础功能的解析:

    // 接口, 文件解析委托类
    public interface DocDelegate extends Closeable {
    
        /**
         * 读取全部内容
         *
         * @return
         */
        <K> K readContent();
    
        /**
         * 关闭
         *
         * @throws IOException
         */
        @Override
        default void close() {
    
        }
    }
    
    // 用于解析可以按行读取的文件,如 Excel
    public interface DocLineDelegate<T> extends DocDelegate {
        /**
         * 按行分割 内容
         *
         * @return
         */
        List<T> readLineContent();
    
    }
    
    // 用于解析可以按页读取的文件,如Word
    public interface DocPageDelegate<T> extends DocDelegate {
        /**
         * 获取当前页数
         *
         * @return
         */
        int getNumberOfPages();
    
        /**
         * 读取某一页的内容
         *
         * @param page
         * @return
         */
        T readPage(int page);
    
    }
    

3. 总结

Bridge 模式的特征是将“类的功能层次结构” 和“类的实现层次结构”分离开了。当想要增加功能时,只需要在“类的功能层次结构” 一侧增加类即可。不必对“类的实现层次结构”做任何修改,而且增加够的功能可以被“所有的实现”使用。

需要注意的是,虽然使用“继承”也很容易扩展类,但是类之前形成了一种强关联关系,如果需要修改类之前的关系,使用继承就不合适了,因为每次改变都需要修改原程序。这是便可以使用"委托"来代替“继承关系”。如上述Demo中,Display 将 open、print、close 方法委托给了 impl 来实现,如果需要改变关联关系,在创建 Display 时传入新的 Impl 实现即可。

三、Strategy 模式

Strategy 模式 : 整体地替换算法

1. 介绍

Strategy 模式登场的角色:

  • Strategy (策略):Strategy 角色负责决定实现策略所必需的接口(API)。
  • ConcreteStrategy(具体的策略):ConcreteStrategy角色负责实现 Strategy 角色的接口,即负责实现具体的策略。
  • Context(上下文):负责使用Strategy 角色。Context 角色保存了 ConcreteStrategy 角色的实例,并使用ConcreteStrategy 角色去实现需求。

类图如下:
设计模式④ :分开考虑,# 《图解设计模式》,设计模式


Demo如下:

// 策略接口
public interface Strategy {
    int getNumber();
}

// 获取随机奇数
public class OddNumberStrategy implements Strategy {
    @Override
    public int getNumber() {
        int number;
        do {
            number = RandomUtils.nextInt();
        } while (number % 2 == 0);
        return number;
    }
}

// 获取随机偶数
public class EvenNumberStrategy implements Strategy {

    @Override
    public int getNumber() {
        int number;
        do {
            number = RandomUtils.nextInt();
        } while (number % 2 != 0);
        return number;
    }
}
//策略上下文,持有所有策略
public class StrategyContext {

    private EvenNumberStrategy evenNumberStrategy = new EvenNumberStrategy();

    private OddNumberStrategy oddNumberStrategy = new OddNumberStrategy();
    
    public int getEventNumber(){
        return evenNumberStrategy.getNumber();
    }  
    public int getOddNumber(){
        return oddNumberStrategy.getNumber();
    }
}

public class StrategyDemoMain {
    public static void main(String[] args) {
    	// 选择合适的策略执行
        StrategyContext strategyContext = new StrategyContext();
        final int oddNumber = strategyContext.getOddNumber();
        final int eventNumber = strategyContext.getEventNumber();
        System.out.println("oddNumber = " + oddNumber);
        System.out.println("eventNumber = " + eventNumber);
    }
}

2. 应用

  • 线程池的任务拒绝策略:在我们自定义线程时是需要传入一个任务拒绝处理器,Java默认提供了多种拒绝策略的实现,通过选择不同的策略可以在线程池满任务时选择对应的处理方式,如丢失任务、抛出异常等。如下,可以通过传入不同的 RejectedExecutionHandler 来实现不同的拒绝策略。

    public ThreadPoolExecutor(int corePoolSize,
                              int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue,
                              ThreadFactory threadFactory,
                              RejectedExecutionHandler handler) {
        if (corePoolSize < 0 ||
            maximumPoolSize <= 0 ||
            maximumPoolSize < corePoolSize ||
            keepAliveTime < 0)
            throw new IllegalArgumentException();
        if (workQueue == null || threadFactory == null || handler == null)
            throw new NullPointerException();
        this.corePoolSize = corePoolSize;
        this.maximumPoolSize = maximumPoolSize;
        this.workQueue = workQueue;
        this.keepAliveTime = unit.toNanos(keepAliveTime);
        this.threadFactory = threadFactory;
        this.handler = handler;
    }
    
    
  • Dubbo的负载均衡策略: Dubbo 通过 LoadBalance 接口完成负载均衡,而负载均衡有多种方案可以选择,如随机、轮询、按比重等等,Dubbo 对每种情况实现了各自的 LoadBalance ,然后根据配置选择合适的 LoadBalance 策略来完成负载均衡。

    	// AbstractLoadBalance 中,子类 LoadBalance 实现 doSelect 方法来实现自己的策略。
        @Override
        public <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) {
            if (CollectionUtils.isEmpty(invokers)) {
                return null;
            }
            if (invokers.size() == 1) {
                return invokers.get(0);
            }
            return doSelect(invokers, url, invocation);
        }
    
        protected abstract <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation);
    


个人使用:该部分内容是写给自己看的,帮助自身理解,因此就不交代项目背景了,读者请自行忽略(◐ˍ◑)

  • 项目A 中需要对文件进行解析读取,对于同一份文件,在不同的用途时需要解析获取的数据也不同,此时会为每种目的建立不同的读取策略,通过不同的策略来获取不同的信息。

  • 项目B 中需要手动提供一个 TraceId 进行数据记录,对于这种情况肯定是通过AOP 完成,除此之外,为了普适性,额外提供了一个 TraceId 生成的策略类,如果某个项目需求不同,需要生成不同格式的 TraceId,则可以通过实现策略类来完成。如下:

    public interface TraceIdStrategy {
        /**
         * 获取 id
         *
         * @return
         */
        String getTraceId();
    
        /**
         * 获取id
         *
         * @param traceId
         * @return
         */
        String getTraceId(String traceId);
    }
    
    //提供一个默认的策略
    public class DefaultTraceIdStrategy implements TraceIdStrategy {
    
        @Override
        public String getTraceId() {
            return UUID.randomUUID().toString();
        }
    
        @Override
        public String getTraceId(String traceId) {
            return traceId;
        }
    }
    
    // 注入MDC 
    @Order(Integer.MIN_VALUE)
    public class MDCTraceConfigurer implements WebMvcConfigurer {
    
        private final TraceIdStrategy traceIdStrategy;
        
        public MDCTraceConfigurer(ObjectProvider<TraceIdStrategy> traceIdStrategyOp) {
            this.traceIdStrategy = traceIdStrategyOp.getIfAvailable(DefaultTraceIdStrategy::new);
        }
    
        @Override
        public void addInterceptors(InterceptorRegistry registry) {
            registry.addInterceptor(new MDCTraceInterceptor(traceIdStrategy)).addPathPatterns("/**");
        }
    }
    

3. 总结

相关设计模式:文章来源地址https://www.toymoban.com/news/detail-815645.html

  • Flyweight 模式 :有时会使用Flyweight 模式让多个地方可以共用 ConcreteStrategy 角色。
  • Abstract Factory 模式 :使用 Strategy 模式可以整体替换算法,使用 Abstract Factory 模式则可以整体地替换具体工厂、零件和产品
  • State 模式:使用Strategy 模式和 State模式都可以替换被委托对象,而且他们的类之间的关系也很相似。但是这两种模式的目的不同。Strategy 模式中 ConcreteStrategy 角色是代表算法的类。在 Strategy 模式中,可以替换被委托的对类。而在 State模式中,ConcreteState 角色是表示 “状态” 的类。在 State模式中,每次状态变化时,被委托对象的类都必定会被替换掉。

到了这里,关于设计模式④ :分开考虑的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 软件设计模式与体系结构-设计模式-行为型软件设计模式-状态模式

    与策略模式类似,状态模式将不同状态下的行为封装在不同的类中,每个类代表一个状态 状态模式的组成 Context:定义了与客户程序的接口,它保持了一个concreteState的代表现在状态的实例 State:定义了状态接口,它的各个子类封装了在各种不同状态下的行为 ConcreteState子类:

    2024年02月13日
    浏览(42)
  • 软件设计模式与体系结构-设计模式-行为型软件设计模式-中介者模式

    模式动机: 为了减少对象两之间复杂的引用关系,使之成为一个松耦合的系统,需要适用中介者模式 定义: 用一个中介对象来封装一系列的对象交互,中介者使各对象不需要显式地相互引用,从而使耦合松散,而且可以独立地该变它们之间的交互 中介者模式又称为调停者模

    2024年02月12日
    浏览(39)
  • 设计模式-工厂设计模式

    在简单工厂模式的基础上进一步的抽象化 具备更多的可扩展和复用性,增强代码的可读性 使添加产品不需要修改原来的代码,满足 开闭原则 优点 符合 单一职责 ,每个工厂只负责生产对应的产品 符合 开闭原则 ,添加产品只需添加对应的产品类和工厂类 使用者只需要知道

    2024年02月11日
    浏览(45)
  • 【设计模式】单例模式|最常用的设计模式

    单例模式是最常用的设计模式之一,虽然简单,但是还是有一些小坑点需要注意。本文介绍单例模式并使用go语言实现一遍单例模式。 单例模式保证一个类仅有一个实例,并提供一个访问它的全局访问点。 使用场景: 当类只能有一个实例而且可以从一个公开的众所周知的访

    2024年04月29日
    浏览(41)
  • 设计模式之工厂设计模式

    一种创建型模式,用于封装和管理对象的创建 根据产品是具体产品还是具体工厂可分为简单工厂模式和工厂方法模式 用一个工厂类,根据不同的参数,返回不同的对象。 (根据工厂的抽象程度,可分为工厂方法模式和抽象工厂模式) 工厂方法模式将生成具体产品的任务分发

    2024年02月03日
    浏览(43)
  • 【精选】设计模式——工厂设计模式

    工厂设计模式是一种创建型设计模式,其主要目的是通过将对象的创建过程封装在一个工厂类中来实现对象的创建。这样可以降低客户端与具体产品类之间的耦合度,也便于代码的扩展和维护。 以下是Java中两个常见的工厂设计模式示例: 简单工厂模式又称静态工厂模式,通

    2024年02月04日
    浏览(48)
  • 【设计模式】单例设计模式

    目录 1、前言 2、基本语法 2.1、懒汉式单例 2.2、饿汉式单例 2.3、双重检验锁单例模式 2.4、静态内部类单例模式 2.5、枚举单例模式 2.6、ThreadLocal单例模式 2.7、注册单例模式 3、使用场景 4、使用示例 5、常见问题 5、总结 单例模式是一种设计模式,它确保一个类只能创建一个实

    2024年02月09日
    浏览(42)
  • 结构型设计模式之组合模式【设计模式系列】

    C++技能系列 Linux通信架构系列 C++高性能优化编程系列 深入理解软件架构设计系列 高级C++并发线程编程 设计模式系列 期待你的关注哦!!! 现在的一切都是为将来的梦想编织翅膀,让梦想在现实中展翅高飞。 Now everything is for the future of dream weaving wings, let the dream fly in reali

    2024年02月15日
    浏览(46)
  • 结构型设计模式之代理模式【设计模式系列】

    C++技能系列 Linux通信架构系列 C++高性能优化编程系列 深入理解软件架构设计系列 高级C++并发线程编程 设计模式系列 期待你的关注哦!!! 现在的一切都是为将来的梦想编织翅膀,让梦想在现实中展翅高飞。 Now everything is for the future of dream weaving wings, let the dream fly in reali

    2024年02月16日
    浏览(48)
  • 设计模式浅析(十) ·设计模式之迭代器&组合模式

    日常叨逼叨 java设计模式浅析,如果觉得对你有帮助,记得一键三连,谢谢各位观众老爷😁😁 案例 有两家门店,门店A呢只提供早餐,门店B呢只提供午餐,有一天这两家店铺想要进行合并,一起做大做强,再创辉煌。 合并后呢,对于菜单的定制存在了一定的问题: 门店A的

    2024年04月11日
    浏览(47)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包