在Spring’17，Salesforce为开发者提供了一个强大的工具，Apex STUB API。
看完官方文档提供的例子之后，感觉确实很美好，但又觉得没什么机会用。
不同于Java项目对框架和设计模式的极致追求。
我接手的Apex代码均为意识流散文诗式写法。根本没有抽象化，解耦等操作。
Stub Api是基于Java的Mocking Framework
mockito开发的。
使用Mocking Framework的前提是代码必须进行解耦，就是所谓的依赖注入（Dependency Injection）。
要求代码不能按业务直接写成流水账，而是将模块之间的强依赖解开。
比如，A类的构造强依赖与B类，如果没有B则没有A。
A a = new A();
//-----------------------------------
Class A {
private B b;
public A() {
b = new B();
}
public String getName() {
return b.getName();
}
}
Class B {
public String getName() {
return "I'm the B";
}
}
那么，问题来了，如果我有一个C类，返回“I’m the C”，我就要为C类新建一个A1类，在A1类中将A1与C进行强依赖。
如果需求越来越多，代码也随时越来越膨胀。
那么怎么改变这个局面呢？
B b = new B();
A a = new A(b);
-----------------------------------------------
Class A {
private CustomObject co;
public A(CustomObject cObj) {
this.co = cObj;
}
public String getName() {
reutrn co.Name;
}
}
Class B extends CustomObject {
public String getName() {
return "I'm the B";
}
}
abstract Class CustomObject {
abstract public String getName();
}
这样一来，A和B的强依赖就解耦了，不再是每次new一个A，就必然得到B的内容，而是根据我传进去的B来决定A返回的内容。
如果想返回“I’m the C”，就不用再去新建一个A1类，想返回“I’m the D”，不用再去新建一个A2类。
只有依赖注入的写法才能进行方便的Mocking。
Stub Api可以做到的是，在解耦之后，为A类mock一个B类，C类。做到完美的单元测试（模块隔离）。
Whatever，用不上。至今还没见到过有控制反转思想的的Apex。
说句题外话，apex-enterprise-patterns(官方介绍文章)到现在还没推广开呢。
// 未完待续