0

I am using the chain of responsibility design pattern for my pipeline. One problem I discovered is that the configuration object becomes larger and larger as I add more chains. Essentially, my config object is becoming a massive singleton. Is there an effective way to handle this situation?

Details:

My current set up is

handler.next = handler2
handler2.next = handler3
...

and I use the chain by passing a config object to it.

handler.HandleRequest(config)

the config object has all the config information required for the handlers thus becomes larger and larger as I add more chains.

Possible solution:

In this post the best answer is to use dependency injection.

Which design patterns can be applied to the configuration settings problem?

However, I am not sure how to use dependency injection on the chain of responsibility design without substantially changing the design.

Could someone help me on this issue? Thanks!

Community
  • 1
  • 1
hwasungmars
  • 11
  • 1
  • Do your chains process the configuration object (in order to do what?) or do they extract their configuration from the config object? – Sebastian Weber Mar 05 '13 at 09:26
  • The chains just extract configuration from the config object, for example like where the data file is located for each chain etc. The config object is responsible of checking whether the config the user provided is valid. – hwasungmars Mar 05 '13 at 10:56
  • Also take a look at the Decorator pattern. It might be easier to apply than a Chain of Responsibility (and is especially useful when adding cross-cutting concerns). – Steven Mar 05 '13 at 13:00

1 Answers1

0

I think you are trying to do things together that don't really belong together.

If you need to extract settings/configuration values for different parts of your application, why do you try to read them all in one place?

I prefer small "settings objects" for each component that needs some kind of settings. I usually start with objects that contain all hard-coded default values and derive from that base-settings when I have to. The derived objects can read from arbitrary sources (most of the time that is the app.config file but I used databases and web-services as well).

This is a blog post that describes settings objects in more detail.

Sebastian Weber
  • 6,766
  • 2
  • 30
  • 49
  • The reason I have a config object that holds all the configuration is because of when I run the chain of responsibility, each handler only knows which is the next handler and thus can only pass down the entire configuration. If I want to do dependency injection, then I find it awkward to do it because that will mean that I will have to substantially modify how the chain of responsibility is set up. At the moment, it just returns pointers to the next handler. Is there a good way to fix this? – hwasungmars Mar 05 '13 at 12:28
  • @hwasungmars I still don't get it. You have a large configuration object (where does this object come from? what's it's backing store? file? database?). You throw this object into a pipeline of handlers. Each handler looks for some snippets of information inside that config object and does ... what with that information? store it locally? create new objects out of that information? – Sebastian Weber Mar 05 '13 at 14:30