Question

请考虑底部的Javascript代码摘录。它大致由两个模块组成，一个用于处理消息。 messages模块中filtersUpdateSuccess方法的好处是什么？

目前它只是委托tplPanels模块的overwriteAll方法。令我印象深刻的一个想法是，在filtersUpdateSuccess方法中，对tplPanels.overwriteAll的调用可以包装在try / catch中。这对我有利吗，对于额外的间接水平还有其他好处吗？

PS ....我熟悉以下问题并咨询过它并遵循其中的链接，但现在我想在特定的上下文中找到答案而不是更一般的问题：Level of Indirection solves every Problem

function msgHandlers() {
    var scope
        ,msgs;

    return {
        SET_CONTEXT: function(context) {
            scope = context.scope;
            msgs = context.messages;
        }

        ,SUBSCRIBE_ALL: function() {
            me.subscribe(scope, msgs.FILTERS_UPDATE_SUCCESS, this.filtersUpdateSuccess);
            //me.subscribe(scope, msgs.FILTERS_UPDATE_SUCCESS, tpl.overwriteAll);
        }

        ,filtersUpdateSuccess: function(filterValues) {
            tplPanels().overwriteAll(filterValues);
        }
    }
}

function tplPanels() {
    var instances = {};

    return {
        locationInstance: function() {
            if (!instances.locationPanel) {
                instances.locationPanel = locationPanel();
            }
            return instances.locationPanel;
        }
        //more instances, etcetera
        ,overwriteAll: function(filterValues) {
            //do something useful
        }
    }
        //etcetera

Answer 1

这里的情况似乎是接口的抽象，而不是参考间接的额外层。

接口抽象有几个目的：

使一段代码适合一个通用客户端或一个形状不受控制的客户端所需的接口。
使一段代码适合多个客户端共享的接口。
通过抽象出实现细节，使一段代码适合维护者的心理模型。
使一段代码适合计划的（不仅仅是可能的）未来用例所需的接口。

如果系统中的另一个模块已经使用上下文设置 - 订阅 - 过滤接口获取不同的输入，那么它可能很有价值，因为它允许您的代码插入其中：（1）或（2）。

如果你有计划让这个接口有多个提供者或消费者，那么现在让它符合接口是很有价值的，因为你已经完成了将代码分页到内存的工作：（4）上方。

如果其他模块已经以这种方式构建，或者过滤是其他模块使用的常见操作，那么代码维护人员可以利用它来快速学习代码：（3）上面。

如果这些都不适用，那么，由于filtersUpdateSuccess没有关闭tplPanels没有关闭的任何内容，因此接口抽象中没有任何值。

额外的间接水平的任何具体好处

1 个答案: