spring的价值的质疑

Class A{
public void doSth(){
 InterfaceB b=new B();
 b.do();
 .....
 .....
}
}

这种情况，怎么mock B来隔离测试A呢？

那个JMock的例子似乎回答了您的问题。

您仔细看看我的代码，A里面写死了InterfaceB b=new B();
这种情况下，怎么把b替换成mock来测？

import org.jmock.Mockery;
import org.jmock.Expectations;

class PublisherTest extends TestCase {
    Mockery context = new Mockery();

    public void testOneSubscriberReceivesAMessage() {
        // set up
        final Subscriber subscriber = context.mock(Subscriber.class);

        Publisher publisher = new Publisher();
        publisher.add(subscriber);
        
        final String message = "message";
        
        // expectations
        context.checking(new Expectations() {{
            one (subscriber).receive(message);
        }});

        // execute
        publisher.publish(message);
        
        // verify
        context.assertIsSatisfied();
    }
}

 Publisher, Subscriber不就是相当于您说的A,B吗？

Spring IOC使用起来相当自然,何谈扭曲的使用...,即使你只使用Spring的基本ioc容器,你也会获益良多...

"spring的主要价值似乎是支持单元测试",容易进行单元测试只是spring带来的一点附加值而已...

依赖注入那么好的编程模型如果都不值得的话,真不知道还有什么值得的了...

DI不是只是用来作单元测试的。

这儿应该不是能与不能的问题，不是那么绝对，如果一定要用能与不能来做判断，那么java都不必出现了，理论上没有c+=甚至c,汇编搞不定的问题。

而是说，依赖注入对设计有利，而spring则促进了依赖注入的使用。

如果业务处理类，它所使用的倚赖，都是依靠在这个类内部实现或者查找，那么必然使得正常的业务逻辑和获取依赖的方法混在一起。

我取个最简单的场景，某个注册的工作类，它需要获取当前"容许的用户名的最大长度"，这个依赖非常简单吧？基本每个注册类都有这个限制，我们现在把场景考虑的全面一点，对于复杂一点的系统，这个最大长度的限制可能来源很多，比如配制文件，数据库，可能类工作在前台比如web而配制在后台，可能需要和第三放系统一起工作而需要到第三方系统中获取而对方只提供web service...

这么一个简单的依赖，“用户名的最大长度”，如果用依赖注入，只要一个简单的setUsernameMaxLength()方法就可以搞定。考虑上面那么多种可能都出现，最恶劣的情况是要求一个系统可以同时支持然后通过配制方式进行，这对于将一个产品卖给n家客户的公司来说是最正常不过的要求。

那么我们来看一个很有"spring"风格的采用依赖注入的设计，通常都将会是这样：

注册工作类：
public void RegisterWork {
    public void setUsernameMaxLengthProvider(UsernameMaxLengthProvider provider) {
        int maxLength = provider.getUsernameMaxLength(); //简单获取结果，不管provider细节
    }
    ....
}
“用户名的最大长度”的提供者接口
public interfacd UsernameMaxLengthProvider {
    public int getUsernameMaxLength();
}
“用户名的最大长度”的提供者则可以有以下实现，都只负责读取数据，不关心数据被谁使用，怎么使用：
1.直接提供，可以用spring 构造函数方式注入usernameMaxLength值，也可以junit测试时直接new DirectdProvide对象
public class DirectdProvider implements UsernameMaxLengthProvider  {
    private int usernameMaxLength = 10;
    public int getUsernameMaxLength() {
        return UsernameMaxLength;
    }
    public DirectdProvider (int usernameMaxLength) {
        this.usernameMaxLength = usernameMaxLength;
    }
}
2.读本地配制文件
public class LocalConfigFileProvider implements UsernameMaxLengthProvider  {   
    public void read(File configFile) {
        usernameMaxLength = ....
    }
}
3.类似的从数据库读取 DatabaseProvide
4.类似的web service从第三方读取 WebServiceProvider
5.其他的可能扩展的方式

开发时逻辑清晰，代码可读性超强，基本看类名和函数名搞定。测试时，轻松测试RegisterWork，testcase中只要worker.setUsernameMaxLengthProvider(new DirectdProvider(20))就搞定。而针对UsernameMaxLengthProvider的几个实现类，更是轻松使用junit，每个都覆盖一遍。

呵呵，现在我们可以砍刀，最简单的一个int型的“用户名的最大长度”，都可能遭遇如此复杂的场景。如果不用倚赖注入，而是选择在RegisterWork中自己搞定“用户名的最大长度”的获取，那么可能要遇到以下问题：
1. RegisterWork极其复杂，可以想像类似的依赖肯定还有其他
2. 获取“用户名的最大长度”的方式和注册的业务处理逻辑完全没有直接联系，对注册过程来说它只关注结果，“用户名的最大长度”是10还是20，而不是到底读本地文件还是读数据库。喧宾夺主了，次要逻辑干扰了主要逻辑
3. 难于测试。获取“用户名的最大长度”的方式的这些代码，被藏在RegisterWork类中，而且很有可能是private方法不对外暴露（如果不依赖注入还需要暴露吗？暴露给谁呢），怎么用mock测试？怎么能保证以上几种的实现都覆盖到？
4. 难于扩展。就算上面都搞定了，某一天突然来了一个变态需求，要求用ldap从另一个地方取配置呢？难道再把ldap请求的那一大片代码也写到RegisterWork里面？
5. 更难于被第三方扩展。运气好，上面这个ldap取配制的变态需求客户开始没有要求。顺利开发完成测试通过然后准备上线，最后一晚了客户才发现，"哦，给忘了，你们想办法给加上，快，快，明天一早就要上线运行了...你们写死在代码里面了？那只能你们修改了原代码了"。吐血了吧，先骂一顿，可是活还的干啊，咬牙切齿的把新的实现代码加上了，还得编译打包更新重启...如果是spring多好，单独写一个LdapProvider类，测试（这个测试比杂在RegisterWork里面测试简单的多）通过后单独提供这个class仍classpath下，修改spring的配制将原来的***Provider替换掉，轻松搞定，甚至可以把这活仍给客户的开发人员，告诉他们怎么替换就可以了，管你ladp还是其他，谁让你们需求不明确，自己扩展去。
6. 容易出错。刚吐血完成上面的变态需求，更新完毕，一会客户电话来了，“...怎么...不正常了？”。又吐血几升地检查，终于找出来了，原来是刚才写ladp访问的代码时不小心改错了RegisterWork的一个地方，谁让RegisterWork类有几十上百个方法好几千行呢，一时急，又没有测试到......可是客户不会理解的。

上述的场景，spring + 依赖注入的设计方式，优点很明显吧。

再考虑一下维护和二次开发的问题，上面的spring + 依赖注入的代码，好看易懂，方便扩展，维护起来轻松。如果是那么堆在RegisterWork里面，在那个大堆中代码要找出这些代码并读懂，估计不是件轻松的事情。

代码维护是需要成本的，写出易于维护的代码，是一个优秀程序员的基本素养，至少，不能让下一个接手的人骂娘吧？

花了一个小时回贴，自己都觉得辛苦，呵呵

希望能对楼主有所帮助。

去看了一下“依赖注入是否值得？”的那个帖子，发现有些道理和我上面举的列子是相通的：

1. "虽然能够方便地编写Mock代码是很棒的特性，但这只是主要利益之外的附带好处，主要的利益是降低了对象间的耦合。我可以修改数据访问部分的代码，而不需要触及负责工资计算的引擎，这是我得到的主要益处。"

我的例子中如何注册和如何获取“用户名的最大长度”，成功解耦。任意修改一个都不对对方造成任何影响。

2."简单来说，依赖注入让你的代码更容易改变。这就是它在敏捷社群中流行的原因，他们的整个软件开发实践都围绕着快速变化。"

我的例子中完成ldap取配制的需求时，明显体现了快速变化的优势。

你这不就是自己手动实现的依赖注入吗，跟我例子里的A，B怎么会是一回事呢？

并不是所有场景都适合用“观察者”模式的。

 

如果出现了这样的代码：InterfaceB b=new B();你还怎么替换b？