• 一个快速切换一个底层实现的思路分享


        现实场景往往是这样,我们应对一个需求,很快就会有一个处理方法了,然后根据需求做了一个还不错的实现。因为实现了功能,业务很happy,老板很开心,all the world is beatiful.

        但随着公司的发展,有人实现了一套底层的标准组件,按要求你必须要接入他那个,他的功能与你类似,但你必须要切换成那个。且不论其实现的质量怎么样,但他肯定是有一些优势的,不过他作为标准套件,不可能完全同你的需求一致。因此,这必定涉及到改造的问题。

        一般这种情况下,我们是不太愿意接的,毕竟代码跑得好好的,谁愿意动呢?而且别人的实现如何,还没有经过考验,冒然接入,可能带来比较大的锅呢。(从0到1没人关注准确性,但从1到到1.1就会有人关注准确性了,换句话说这叫兼容性)

        但是,往往迫于压力,我们又不得不接。

        这时候我们有两种做法,一种是硬着头皮直接改代码为别人的方式。这种处理简单粗暴,而且没有后顾之忧。不过,随之而来的,就是大面积的回归测试,以及一些可能测试不到的点,意味着代码的回滚。对于一些线上运维比较方便的地方,也许我们是可以这样干。但这并不是本文推荐的做法,也不做更多讨论。

        更稳妥的做法,应该是在保有现有实现的情况下,进行新实现的接入,至少你还可以对照嘛。进可攻,退可守。


    1. 快速接入新实现1:抽象类

        既然我们不敢直接替换现有的实现,那么就得保留两种实现,所以可以用抽象类的方式,保持原有实现的同时,切入新的实现。是个比较直观的想法了,具体实现如下:

    1. 抽象一个公共类出来

    public abstract class AbstractRedisOperate {
    
        private AbstractRedisOperate impl;
    
        public AbstractRedisOperate() {
            String strategy = "a";  // from config
            if("a".equals(strategy)) {
                impl = new RedisOperateA1Imp();
            }
            else {
                impl = new RedisOperateB2Imp();
            }
        }
    
        // 示例操作接口
        public void set(String key, String value);
    }

    2. 实现两个具体类

    // 实现1,完全依赖于抽象类实现(旧有功能)
    public class RedisOperateOldImp extends AbstractRedisOperate {
    
    }
    
    // 实现2,新接入的实现
    public class RedisOperateB2Imp extends AbstractRedisOperate {
    
        @Override
        public void set(String key, String value) {
            System.out.println("this is b's implement...");
        }
    }

    3. 保持原有的实现类入口,将其实现变成一个外观类或者叫适配器类

    // 加载入口
    @Service
    public class RedisOperateFacade extends AbstractRedisOperate {
    
        public RedisOperateFacade() {
            // case1. 直接交由父类处理
            super();
        }
    
        @Override
        public void set(String key, String value) {
            // fake impl
        }
    }

        以上实现有什么好处呢?首先,现有的实现被抽离,且不用做改动被保留了下来。新的实现类自行实现一个新的。通过一个公共的切换开关,进行切换处理。这样一来,既可以保证接入了新实现,而且也保留了旧实现,在出未知故障时,可以回切实现。

        以上实现有什么问题?

        当我们运行上面的代码时,发现报错了,为什么?因为出现了死循环。虽然我们只加载了一个 Facade 的实现,但是在调用super时,super会反过来加载具体的实现,具体的实现又会去加载抽象类super,如此循环往复,直到栈溢出。也叫出现了死循环。


    2. 解决简单抽象带来的问题

        上一节我们已经知道为什么出现加载失败的问题,其实就是一个循环依赖问题。如何解决呢?

        其实就是简单地移动下代码,不要将判断放在默认构造器中,由具体的外观类进行处理,加载策略由外观类决定,而非具体的实现类或抽象类。

        具体操作如下:

    // 1. 外观类控制加载
    @Service
    public class RedisOperateFacade extends AbstractRedisOperate {
    
        public RedisOperateFacade() {
            // case1. 直接交由父类处理
            // super();
            // case2. 决定加载哪个实现
            String strategy = "a";  // from config center
            if("a".equals(strategy)) {
                setImpl(new RedisOperateOldImp());
            }
            else {
                setImpl(new RedisOperateB2Imp());
            }
        }
    
    }
    // 2. 各实现保持自身不动
    public class RedisOperateOldImp extends AbstractRedisOperate {
        // old impl...
    }
    
    public class RedisOperateB2Imp extends AbstractRedisOperate {
    
        // new impl...
        @Override
        public void set(String key, String value) {
            System.out.println("this is b's implement...");
        }
    }
    
    // 3. 抽象类不再进行加载策略处理
    public abstract class AbstractRedisOperate {
        // 持有具体实现
        private AbstractRedisOperate impl;
    
        public AbstractRedisOperate() {
        }
    
        protected void setImpl(AbstractRedisOperate impl) {
            this.impl = impl;
        }
    
        // 示例操作接口, old impl...
        public abstract void set(String key, String value);
    }

        做了微小的改动,将加载策略从抽象类中转移到外观类中,就可以达到正确的加载效果了。实际上,为了简单起见,我们甚至可以将原有的实现全部copy到抽象类中,而新增的一个原有实现类,则什么也不用做,只需新增一个空继承抽象类即可。而新的实现,则完全覆盖现有的具体实现就可以了。从而达到一个最小的改动,而且顺利接入一个新实现的效果。

        但是如果依赖于抽象类的具体实现的话,会带来一个问题,那就是如果我们的子类实现得不完善,比如遗漏了一些实现时,代码本身并不会报错提示。这就给我们带来了潜在的风险,因为那样就会变成,一部分是旧有实现,另一部分是新的实现。这可能会有两个问题:一是两个实现有一个报错一个正常;二是无法正常切换回滚,两种实现耦合在了一起。


    3. 更完善的方案:基于接口的不同实现

        怎么办呢?我们可以再抽象一层接口出来,各实现针对接口处理,只有外观类继承了抽象类,而且抽象类同时也实现了接口定义。这样的话,就保证了各实现的完整性,以及外观类的统一性了。这里,我利用的是语法的强制特性,即接口必须得到实现的语义,进行代码准确性的保证。(当然了,所有的现实场景,接口都必须有相应的实现,因为外部可见只有接口,如果不实现则必定不合法)

    具体实现如下:

    //1. 统一接口定义
    public interface UnifiedRedisOperate {
    
        void set(String key, String value, int ttl);
    
        // more interface definitions...
    }
    // 2. 各子实现类
    public class RedisOperateOldImp implements UnifiedRedisOperate {
    
        @Override
        public void set(String key, String value) {
            System.out.println("this is a's implement...");
        }
    }
    public class RedisOperateB2Imp implements UnifiedRedisOperate {
    
        @Override
        public void set(String key, String value) {
            System.out.println("this is b's implement...");
        }
    }
    // 3. 外观类的实现
    @Service
    public class RedisOperateFacade extends AbstractRedisOperate {
    
        public RedisOperateFacade() {
            // case1. 直接交由父类处理
            // super();
            // case2. 外观类控制加载
            String strategy = "a";  // from config center
            if("a".equals(strategy)) {
                setImpl(new RedisOperateOldImp());
            }
            else {
                setImpl(new RedisOperateB2Imp());
            }
        }
    
    }
    public abstract class AbstractRedisOperate implements UnifiedRedisOperate {
    
        private UnifiedRedisOperate impl;
    
        protected void setImpl(UnifiedRedisOperate impl) {
            this.impl = impl;
        }
    
        // 接口委托
        public void set(String key, String value) {
            impl.set(key, value);
        }
    
        // more delegates...
    }

        看起来是多增加了一个接口类,但是实际上整个代码更加清晰易读了。实际上,一个好的设计,最初应该也是基于接口的(即面向接口编程),而我们在这里重新抽象出一个接口类来,实际上就是弥补之前设计的不足,也算是一种重构了。所有的实现都基于接口,一个实现都不能少,从而减少了出错的概率。

        如此,我们就可以放心的进行生产切换了。

     文章原创发布微信公众号地址: 一个快速切换一个底层实现的思路分享

  • 相关阅读:
    Mysql 查看 数据库/表 磁盘占用
    COLA 4.0 整洁面向对象分层架构
    《语言选择与就业方向》(2010/06/09)
    《为什么程序员不愿写文档》(2010/06/22)
    《我?还是我们?》(2010/06/30)
    《选择大公司还是小公司》(2010/06/11)
    《加班,加班,加班》(2010/06/17)
    《薪水的苦恼》(2010/06/15)
    《新手面试时的常见问题和对策》(2010/06/15)
    《大量编程带来的快乐和烦恼》(2010/06/20)
  • 原文地址:https://www.cnblogs.com/yougewe/p/16413213.html
Copyright © 2020-2023  润新知