thoughts on configuration through delegates

Question

i'm working on a fork of the Divan CouchDB library, and ran into a need to set some configuration parameters on the httpwebrequest that's used behind the scenes. At first i started threading the parameters through all the layers of constructors and method calls involved, but then decided - why not pass in a configuration delegate?

so in a more generic scenario,

given :

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();
    }
}

do:

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();
    }
}

the latter seems a lot cleaner to me, but it does expose to the outside world that class Foo uses externallyKnownResource

thoughts?

Answer 1

This can lead to cleaner looking code, but has a huge disadvantage.

If you use a delegate for your configuration, you lose a lot of control over how the objects get configured. The problem is that the delegate can do anything - you can't control what happens here. You're letting a third party run arbitrary code inside of your constructors, and trusting them to do the "right thing." This usually means you end up having to write a lot of code to make sure that everything was setup properly by the delegate, or you can wind up with very brittle, easy to break classes.

It becomes much more difficult to verify that the delegate properly sets up each requirement, especially as you go deeper into the tree. Usually, the verification code ends up much messier than the original code would have been, passing parameters through the hierarchy.

Answer 2

IMO, you're best off accepting a configuration object as a single parameter to your Foo constructor, rather than a dozen (or so) separate parameters.

Edit:

there's no one-size-fits-all solution, no. but the question is fairly simple. i'm writing something that consumes an externally known entity (httpwebrequest) that's already self-validating and has a ton of potentially necessary parameters. my options, really, are to re-create almost all of the configuration parameters this has, and shuttle them in every time, or put the onus on the consumer to configure it as they see fit. – kolosy

The problem with your request is that in general it is poor class design to make the user of the class configure an external resource, even if it's a well-known or commonly used resource. It is better class design to have your class hide all of that from the user of your class. That means more work in your class, yes, passing configuration information to your external resource, but that's the point of having a separate class. Otherwise why not just have the caller of your class do all the work on your external resource? Why bother with a separate class in the first place?

Now, if this is an internal class doing some simple utility work for another class that you will always control, then you're fine. But don't expose this type of paradigm publicly.

Answer 3

I may be missing something here, but it seems like a big disadvantage to create the externallyKnownResource object down in DoWork(). This precludes easy substitution of an alternate implementation. Why not:

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