关于Stub API

在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(官方介绍文章)到现在还没推广开呢。

// 未完待续