Passing compound object for parameters

Question

I have different data modules, which take a couple of parameters from a configuration list. Do you think it's ok to pass a configuration object as a whole module1(config) and let the module pick what it needs, or should I rather pass the individual parameters module1(config.a, config.c, config.f)? The first case doesn't require change interfaces in case I need more configuration parameters, but the second case encapsules more?

Answer 1

The parameter object pattern is widely used in .NET and other object oriented frameworks.

This is essentially what you are describing what talking about passing in a single object and is considered a good practice, so long as the individual parameters have good defaults (so the modules will work even when only some of the parameters are passed in).

If your modules don't have a use for all items in the configuration object I would call this a code smell, however. If they are not needed, why pass them in? The configuration object should match the needs of the module.

Answer 2

So you want to write this method Module1, which depends on some subset of the properties of a Configuration object.

Some reasones you might want Module1 to take the Configuration object as a single parameter:

• Future versions of Module1 might use additional properties of the Configuration object. This would require changes to every call site if you use individual parameters. (This might not matter too much if Module1 is only exposed internally to your own project, and you have and IDE with strong refactoring features. It matters a lot if it is part of a publicly published API.)

• At the places where you want to call Module1, you have a Configuration object available, and it is more convenient to just pass the whole object than to pass in each relevant property.

You might want Module1 to take the relevant properties as individual parameters if:

• At the places where you want to call Module1, you don't have a Configuration object available, and you can supply values for the relevant properties but not all the properties. (This is a strong reason if you are confident that future versions will not use more properties.)

So really, it depends on how you expect the method might change in the future, and how much of a burden it is to change call sites if the signature changes.

Answer 3

You may want to consider using an interface for your parameter itself. Your configuration object will implement the interface, but the interface should include only the properties that you can use on this method.

We call this using role interfaces, and it is an important part of the Interface Segregation Principle. It means that as your configuration object changes, you can choose which properties this particular method is interested in, and add those properties to the interface. No additional refactoring is required. And you still don't have the code smell of getting passed a lot of information you don't need.

Answer 4

I've found it easier to make Configuration objects static. That way, you don't have to pass them around.

The assumption behind static is that you have a single configuration for each process. For me, so far, that assumption holds.