怎么处理超级大的switch？

考虑有下面的代码：

interface IRequest {
    request: () => void;
}


class ARequest implements IRequest {
    request() {
        console.log('A request impl.');
    }
}


class BRequest implements IRequest {
    request() {
        console.log('B request impl.');
    }
}

enum RequestType {
    A,
    B,
}

class RequestManager {
    getRequest(type: RequestType) {
        switch(type) {
            case RequestType.A:
                return new ARequest();
            case RequestType.B:
                return new BRequest();
        }
    }
}

上面只是列了两个case，但实际项目中，上面可能有几十个case。想象下，如果这个时候你需要添加一个新的request类的实现，你需要改动RequestType,RequestManager，比如新增一个CRequest。

enum RequestType {
    A,
    B,

    C,
}

class CRequest implements IRequest {
    request() {
        console.log('C request impl.');
    }
}

class RequestManager {
    getRequest(type: RequestType) {
        switch(type) {
            case RequestType.A:
                return new ARequest();
            case RequestType.B:
                return new BRequest();
            case RequestType.C:
                return new CRequest();
        }
    }
}

在软件工程当中，我们提倡对修改关闭，对新增开放，也就是所谓的开发关闭原则。那上面的例子，其实不符合这个设计原则。因为每次添加新的Requst实现，都会导致去修改RequestManager，我们更提倡的应该是，面向接口编程，RequestManager应该是一个比较稳定的类，我们应该保证，在后续添加新的实现的时候，不需要改动到RequestManager类，而是通过RequestManager类提供的接口，来动态改变RequestManager内部的状态，而不是直接修改RequestManager里面的代码。

还有一个重要的点是，getRequest里面，随着request的日益增多，switch代码会越来越长，这也导致这里是一个很容易出问题的地方。

为了解决上面的两个问题，试着对RequestManager改造，引入一个对外的接口，内部增加一个map来管理所有的Request对象实现。

改造之后的代码如下：

class RequestManager {

    private requestMap = new Map<RequestType, IRequest>();

    constructor() {
        this.initDefaultRequest();
    }

    private initDefaultRequest() {
        this.registerRequest(RequestType.A, new ARequest());
        this.registerRequest(RequestType.B, new BRequest());
    }
    getRequest(type: RequestType) {
        return this.requestMap.get(type);
    }

    public registerRequest(type: RequestType, request: IRequest) {
        this.requestMap.set(type, request);
    }
}

上面的代码中，所有的request对象，通过map来维护，在RequestManager中可以初始化一些默认的request，供外部直接使用，同时，对外提供registerRequest的方法，供外部扩展。

修改成上面的代码之后，现在，如果我们要添加一个request，比如就是刚刚的CRequest。我们来看下怎么添加：

class App {
    public readonly requestManager = new RequestManager();
    init() {
        this.requestManager.registerRequest(RequestType.C, new CRequest());
    }
}


class Bussiness {
  	private app: App = new App();
    init() {
       this.app.requestManager.registerRequest(RequestType.C, new CRequest());
   }
}

比如以上例子，App类代表整个应用，在应用下面，我们有N个模块，requestManager是其中的一个模块，那这个时候，外部如果想用，我们只需要要使用app对象下的requestManager提供的registerRequest方法，用来注册新的Request就行了，这样，在业务方来看，并没有去修改应用本身的代码，同时，应用提供了统一的对外接口，应用里面的模块也更加高内聚，更加稳定。这也就是上面说的，只对新增开放，对修改关闭。就是这个意思。

上面的例子中，其实还有一个问题，那就是如果我们要添加一个类型，我们需要修改RequestType这个枚举类，每次新增都需要添加一个枚举元素，虽然这里修改非常简单，引入bug的可能性非常小，但是有没有办法杜绝这个问题呢？

我们来看下面的代码：

interface IRequest {
    request: () => void;

    getRequestType: () => IRequestType;
}


class ARequest implements IRequest {
    private static REQUEST_TYPE: IRequestType = { type: 'a' };
    request() {
        console.log('A request impl.');
    }

    getRequestType() {
        return ARequest.REQUEST_TYPE;
    }
}


class BRequest implements IRequest {
    private static REQUEST_TYPE: IRequestType = { type: 'b' };
    request() {
        console.log('B request impl.');
    }

    getRequestType() {
        return BRequest.REQUEST_TYPE;
    }
}
interface IRequestType {
    type: string;
}


class CRequest implements IRequest {
    private static REQUEST_TYPE: IRequestType = { type: 'c' };
    request() {
        console.log('C request impl.');
    }

    getRequestType() {
        return CRequest.REQUEST_TYPE;
    }
}

class RequestManager {

    private requestMap = new Map<IRequestType, IRequest>();

    constructor() {
        this.initDefaultRequest();
    }

    private initDefaultRequest() {
        this.registerRequest(new ARequest());
        this.registerRequest(new BRequest());
    }
    getRequest(type: IRequestType) {
        return this.requestMap.get(type);
    }

    public registerRequest(request: IRequest) {
        this.requestMap.set(request.getRequestType(), request);
    }
}


class App {
    public readonly requestManager = new RequestManager();
}


class Bussiness {
  	private app: App = new App();
    init() {
       this.app.requestManager.registerRequest(new CRequest());
   }
}

在上面的代码中，首先我们通过给接口IRequest添加getRequestType方法，这个方法主要用来约束实现类的，就是说，实现类必须实现这个方法，然后，返回值类型，我们定义了IRequestType，这里同样也是约束返回值的类型，这样，在编写实现的时候，代码就可以按照事先定义好的约束来写，这样可以增加代码的统一性，同时，也能够避免大家代码写的不一致，导致维护性很差的问题。因为我们的约束定义好了，实现的话，那就是“戴着脚镣跳舞”。

再来看上面的代码，是否解决了上面的问题呢？我想应该是解决了，现在，如果我们要添加一个新功能，而这个新功能，我们已有的request实现无法满足的话，那就需要添加新的request实现，这个实现，添加一个实现，我们只需要重新写一个request的实现，然后调用app.requestManager.registerRequest，来注册即可，这样，就真正的实现了上面我们说的，针对接口编程，对修改关闭，对新增开发的设计原则。

使用instanceof判断类型，然后添加操作？

考虑如下的代码：


// 分类接口
interface ICategory {
    doSomething: () => void;
}

// 分类A
class ACategory implements ICategory {
    doSomething() {
        console.log('A doSomething...')
    }
}

// 分类B
class BCategory implements ICategory {
    doSomething() {
        console.log('B doSomething...')
    }
}



class CategoryEngine {
    private categories: ICategory[] = [];
    constructor() {
        this.categories = [new ACategory(), new BCategory()];
    }
    handle() {
        this.categories.forEach((category: ICategory) => {
            if (category instanceof ACategory) {
                this.doSomething2(category);
            }
            category.doSomething();
            // ....
        })
    }
    doSomething2(category: ICategory) {
        // do something else
        return category;
    }
}

上面的代码中，我们定义了一个ICategory（类别）的接口，然后有两个类别的实现，然后在CategoryEngine我们试图对所有存在的类别做一些事情，当然这里只是举一个例子，实际的项目当中，可能是其他类似的问题。在handle方法中，我们遍历所有的类别，来做一些事情，注意观察，在forEach内部，我们使用了instanceof来判断category是否为ACategory，然后来调用CategoryEngine里面的方法来特殊处理。

那上面的代码有什么问题，其实有问题的。假设，我后面需要添加一个CCategory，并且，这个CCategory也需要特殊处理，那怎么办呢？这个时候，就又要修改CategoryEngine中的代码，修改handle方法中的if判断，然后判断是否为CCategory，比如像下面这样：

// 分类接口
interface ICategory {
    doSomething: () => void;
}

// 分类A
class ACategory implements ICategory {
    doSomething() {
        console.log('A doSomething...')
    }
}

// 分类B
class BCategory implements ICategory {
    doSomething() {
        console.log('B doSomething...')
    }
}

// 分类C
class CCategory implements ICategory {
    doSomething() {
        console.log('C doSomething...')
    }
}

class CategoryEngine {
    private categories: ICategory[] = [];
    constructor() {
        this.categories = [new ACategory(), new BCategory()];
    }
    handle() {
        this.categories.forEach((category: ICategory) => {
            if (category instanceof ACategory) {
                this.doSomething2(category);
            } else if (category instanceof CCategory) {
                this.doSomething3(category);
            }
            category.doSomething();
            // ....
        })
    }
    doSomething2(category: ICategory) {
        // do something else
        return category;
    }

    doSomething3(category: ICategory) {
        // do something else
        return category;
    }
}

代码于是变成了上面这个样子，那后面如果需要继续判断呢？那只能继续修改这个类了。那这个类，出现问题的风险，也就越大。

对于上面的问题，我们应该怎么来处理呢？

看下面的代码：

// 分类接口
interface ICategory {
    doSomething: () => void;

    preDo: () => ICategory;
}

// 分类A
class ACategory implements ICategory {
    doSomething() {
        console.log('A doSomething...')
    }

    preDo() {
        console.log('A pre do...');
        return this;
    }
}

// 分类B
class BCategory implements ICategory {
    doSomething() {
        console.log('B doSomething...')
    }
    preDo() {
        console.log('B pre do...');
        return this;
    }
}

// 分类C
class CCategory implements ICategory {
    doSomething() {
        console.log('C doSomething...')
    }
    preDo() {
        console.log('C pre do...');
        return this;
    }
}

class CategoryEngine {
    private categories: ICategory[] = [];
    constructor() {
        this.categories = [new ACategory(), new BCategory()];
    }
    handle() {
        this.categories.forEach((category: ICategory) => {
            category.preDo();
            category.doSomething();
            // ....
        })
    }
}

看上面的代码，我们在ICategory中添加了一个新的方法，preDo（名字随便取的）方法。在CategoryEngine中，我们对于每个category，都直接先调用preDo，然后调用doSomething方法，可以发现，现在没有if判断了，之前在if判断之后，针对特定category的处理，都收到category的具体实现内部取了，而对于不需要特殊处理的，我们只需要在具体的category里面，实现一个空的方法即可。当然，你也可以，定义一个AbstractCategory的抽象类，实现ICategory接口，其他所有的实现，继承这个抽象类，这样，如果不需要特殊处理，preDo接口就都不用覆写了。

上面的例子，同样也说明了，对修改关闭，对新增开放的设计原则。

依赖怎么处理？

目前，腾讯文档表格中，很多如下的代码：

interface A {

}

interface B {

}

interface C {

}

interface IDependency {
    a: A;
    b:B;
    c: C;
}


class SubModule1 {
    private a: A;
    constructor(dependency: IDependency) {
        this.a = dependency.a;
    }
}

class SubModule2 {
    private a: A;
    private b: B;
    constructor(dependency: IDependency) {
        this.a = dependency.a;
        this.b = dependency.b;
    }
}

class ModuleA {
    private subModule1: SubModule1;
    private subModule2: SubModule2;
    constructor(dependency: IDependency) {
        this.subModule1 = new SubModule1(dependency);
        this.subModule2 = new SubModule2(dependency);
    }
}

上面的代码中，在ModuleA中，有两个子模块，同时，这两个子模块，依赖的外部模块不同，但是在ModuleA中的时候，看起来，ModuleA的依赖是所有子模块的依赖的集合，但是这里有个问题就是，我需要在每个模块以及子模块中，都定义需要依赖的模块对象，同时，还需要外部一层层传递依赖进来。另一个问题是，两个子模块依赖的东西不一样，但是缺同时将所有父模块的依赖全部传递给了子模块，这就导致一个问题，传递进去的所有依赖，哪个子模块用了哪些，外部并不清楚，而且假设，后续，有的模块不要这个依赖了，但是在ModuleA中，你并不敢直接去掉，你需要到每一个子模块中去确认，是否还有使用到。

那针对上面的问题，应该怎么处理呢？我们知道，在Angular2中，引入了DI的机制。那如果，我们的项目当中，也有类似的机制，那代码就变成如下这样了：

interface A {

}

interface B {

}

interface C {

}

// 存放所有实例对象（demo）
const Annotation = new Map();
export const Autowired = () => {
    return (target: any, name: string) => {
        target[name] = Annotation.get(name);
        if (!target[name]) {
            throw new Error(`属性${name}没有可用的实例。`);
        }
    };
};

class SubModule1 {

    @Autowired()
    private a: A;
}

class SubModule2 {
    @Autowired()
    private a: A;
    @Autowired()
    private b: B;
}

class ModuleA {
    @Autowired()
    private subModule1: SubModule1;
    @Autowired()
    private subModule2: SubModule2;
}

可以看出，上面的代码中，每一个模块，对自己依赖的模块，都非常清楚，而且不再需要层层传递依赖进去，代码量也减少了非常多。

上面的DI部分，并没有完全写出，只是作为示例，可以参考别的文章自己实现，应该是比较简单的，或者也可以直接找我交流。

总结

上面的几个例子，只是在平时写代码中，观察到的一些问题，然后写了这篇个人对于这些问题的解决办法，如果你有更好的办法，欢迎指出，谢谢！