代码之家 › 专栏 › 技术社区 › kolosy

关于通过委托进行配置的思考

design-patterns c#

kolosy · 技术社区 · 16 年前

我正在使用Divan CouchDB库的一个分支,需要在后台使用的httpwebrequest上设置一些配置参数。起初,我开始在所有涉及的构造函数层和方法调用层中处理参数,但后来决定——为什么不传入一个配置委托?

class Foo {
    private parm1, parm2, ... , parmN
    public Foo(parm1, parm2, ... , parmN) {
        this.parm1 = parm1;
        this.parm2 = parm2;
        ...
        this.parmN = parmN;
    }

    public Bar DoWork() {
        var r = new externallyKnownResource();
        r.parm1 = parm1;
        r.parm2 = parm2;
        ...
        r.parmN = parmN;
        r.doStuff();
    }
}

做:

class Foo {
    private Action<externallyKnownResource> configurator;
    public Foo(Action<externallyKnownResource> configurator) {
        this.configurator = configurator;
    }

    public Bar DoWork() {
        var r = new externallyKnownResource();
        configurator(r);
        r.doStuff();
    }
}

class Foo 使用 externallyKnownResource

3 回复 | 直到 16 年前

dnewcome 16 年前

这里我可能遗漏了一些东西,但在DoWork()中创建externallyKnownResource对象似乎是一个很大的缺点。这就排除了替代实现的简单替换。为什么不:

public Bar DoWork( IExternallyKnownResource r ) { ... }

Reed Copsey 16 年前

这会导致更清洁的环境看代码,但有一个巨大的缺点。

如果您在配置中使用委托,您将无法控制对象的配置方式。问题是代理可以执行以下操作: 任何东西 -你无法控制这里发生的事情。你让第三方在你的构造函数中运行任意代码,并相信他们会做“正确的事情”。这通常意味着你必须编写大量代码,以确保委托正确设置了所有内容,否则你可能会得到非常脆弱、容易破坏的类。

验证委托是否正确设置了每个需求变得更加困难,尤其是当您深入到树中时。通常,验证代码最终会比原始代码更混乱,通过层次结构传递参数。