分解依赖

概念:本文中的“分解依赖” 是指对部分不满足我们要求的类和方法进行依赖分解,通过装饰器来达到我们需要的功能。

正文:正如下面代码所示,如果你要在你的代码中加入单元测试但有一部分代码是你不想测试的,那么你应用使用这个的重构。下面的例子中我们应用静态类来完成某些工作,但问题是在单元测试时我们无法mock静态类,所以我们只能引入静态类的装饰接口来分解对静态类的依赖。从而我们使我们的调用类只需要依赖于装饰接口就能完成这个操作。

namespace LosTechies.DaysOfRefactoring.BreakDependencies.Before
{
    public class AnimalFeedingService
    {
        private bool FoodBowlEmpty { get; set; }

        public void Feed()
        {
            if (FoodBowlEmpty)
                Feeder.ReplenishFood();

            // more code to feed the animal
        }
    }

    public static class Feeder
    {
        public static void ReplenishFood()
        {
            // fill up bowl
        }
    }
}

重构后代码如下,我们添加一个接口和一个实现类,在实现类中调用静态类的方法,所以说具体做什么事情没有改变,改变的只是形式,但这样做的一个好处是增加了了代码的可测试性。在应用了分解依赖模式后,我们就可以在单元测试的时候mock一个IFeederService对象并通过AnimalFeedingService的构造函数传递给它。这样就可以完成我们需要的功能。

namespace LosTechies.DaysOfRefactoring.BreakDependencies.After
{
    public class AnimalFeedingService
    {
        public IFeederService FeederService { get; set; }

        public AnimalFeedingService(IFeederService feederService)
        {
            FeederService = feederService;
        }

        private bool FoodBowlEmpty { get; set; }

        public void Feed()
        {
            if (FoodBowlEmpty)
                FeederService.ReplenishFood();

            // more code to feed the animal
        }
    }

    public interface IFeederService
    {
        void ReplenishFood();
    }

    public class FeederService : IFeederService
    {
        public void ReplenishFood()
        {
            Feeder.ReplenishFood();
        }
    }

    public static class Feeder
    {
        public static void ReplenishFood()
        {
            // fill up bowl
        }
    }
}

总结:这个重构在很多时候和设计模式中的一些思想类似,使用中间的装饰接口来分解两个类之间的依赖,对类进行装饰,然后使它满足我们所需要的功能。

版权声明:本文为博主http://www.zuiniusn.com原创文章,未经博主允许不得转载。

时间: 2024-08-18 23:20:03

分解依赖的相关文章

小酌重构系列[9]——分解依赖

概述 编写单元测试有助于改善代码的质量,在编写单元测试时,某些功能可能依赖了其他代码(比如调用了其他组件).通常我们只想测试这些功能本身,而不想测试它所依赖的代码. 为什么呢?单元测试的目标是验证该功能是否正确,然而功能所依赖的代码是处于功能范围外的,这些代码可能是一些外部的组件,单元测试无法验证这些外部组件的准确性.单元测试因调用"依赖的代码"出错而失败时,会影响测试结果的判断,我们无法确定功能本身是否是正确的.也许功能是正确的,但调用依赖的代码出错时,这个单元测试仍然会被认为是失败

偏差方差分解

偏差方差分解 (误差分解) 先引入一个问题: Machine Learning 与 Curve Fitting 的区别是什么?1 Curve Fitting 是使用所有的数据拟合一条曲线; 而 Machine Learning 是采用真实世界中采样的一小部分数据,并且我们希望我们的模型能够对于未知数据有不错的泛化性能.因此涉及到Bias-Variance的权衡. 学习算法的预测误差, 或者说泛化误差(generalization error)可以分解为三个部分: 偏差(bias), 方差(var

C#重构经典全面汇总

C#重构经典全面汇总 1.  封装集合 概念:本文所讲的封装集合就是把集合进行封装,仅仅提供调用端须要的接口. 正文:在非常多时候,我们都不希望把一些不必要的操作暴露给调用端,仅仅须要给它所须要的操作或数据即可,那么做法就是封装.这个重构在微软的代码库也常常遇到. 比方最经典的属性对字段的封装就是一个非常好的样例,那么以下我们将看到对集合的封装.例如以下代码所看到的,调用端仅仅须要一个集合的信息,而我们则提供了一个IList的集合.大家都知道IList具有对集合的全部操作,所以这会带来非常多隐患

Spring源码分析——BeanFactory体系之接口详细分析

Spring的BeanFactory的继承体系堪称经典.这是众所周知的!作为Java程序员,不能错过! 前面的博文分析了Spring的Resource资源类Resouce.今天开始分析Spring的IOC部分.众所周知,IOC是Spring框架最迷人的地方.它最重要的接口,就是BeanFactory了.BeanFactory有着庞大的继承.实现体系,有众多的子接口.实现类.本博文的目标就是抽丝剥茧,从源代码入手,分析Spring的实现和架构,从中进步. 在阅读的过程中,可以参照Spring文档来

小酌重构系列[15]——策略模式代替分支

前言 在一些较为复杂的业务中,客户端需要依据条件,执行相应的行为或算法.在实现这些业务时,我们可能会使用较多的分支语句(switch case或if else语句).使用分支语句,意味着"变化"和"重复",每个分支条件都代表一个变化,每个分支逻辑都是相似行为或算法的重复.当追加新的条件时,我们需要追加分支语句,并追加相应的行为或算法. 上一篇文章"使用多态代替条件判断"中,我们讲到它可以处理这些"变化"和"重复&qu

4.AutowireCapableBeanFactory 自动装配工厂

AutowireCapableBeanFactory 根据名称:自动装配的BeanFactory,其实也是对BeanFactory的增强 源代码: /* * Copyright 2002-2016 the original author or authors. * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in complian

AutowireCapableBeanFactory 根据名称:自动装配的BeanFactory,其实也是对BeanFactory的增强

//自动装配的Bean 工厂 public interface AutowireCapableBeanFactory extends BeanFactory { //工厂没有自动装配的Bean int AUTOWIRE_NO = 0; //根据名称自动装配的Bean int AUTOWIRE_BY_NAME = 1; //表明根据类型自动装配 int AUTOWIRE_BY_TYPE = 2; //根据构造方法快速装配的Bean int AUTOWIRE_CONSTRUCTOR = 3; //B

C#重构学习2

转帖重构学习 重构?代码坏味道?看到这两个疑问,也许就知道本期的话题是关于“重构”的,重构无处不在,重构可大可小,重构随时随地.让重构时刻记在脑海,使自己的代码变的优美.就让这本“重构艺术”手册带你走进重构的世界,亲密接触重构,如欣赏艺术般,体会重构的魅力. 文章下载地址:http://files.cnblogs.com/xia520pi/C_Sharp_Refactoring.rar 文章的目录: 1.代码重构 1.1.版权声明 1.2.内容详情 2.项目重构方案设计 2.1.版权声明 2.2

[Android Pro] 开发一流的 Android SDK:Fabric SDK 的创建经验

cp from : https://academy.realm.io/cn/posts/oredev-ty-smith-building-android-sdks-fabric/ Ty Smith Ty 是一个在 Twitter 的 Android 技术负责人,专职于 Fabric 开发工具团队.他曾经负责架构了 Fabric 平台和 Twitter 的 Android SDK,推动了 Digits 和 Twitter SDK 的开源事业,可以说是他一手创建了更大的 Twitter 体系结构.他