Program setting design pattern

Question

I want to have the changing setting of my program to take effect right away rather than rebooting my program, what design pattern is suitable here.

1. have a centric setting class, once the setting changed it has to update the property of objects that need to be updated, if the number of objects is big, this will create unnecessary dependencies between objects and the settings

2. how about observer pattern, but it seems this pattern is not suitable here either. Then i have to add event handler to the objects, but seems this is not the responsibility of objects.

what's your solution?

Answer 1

1. is not a good idea. You would not want your settings object to know about all these objects. The other way around is definetely better.

2. -> why is this pattern not suitable here?

Answer 2

Observer pattern sounds like what you do want !

Consider it in the context of "SettingListener"

Answer 3

We had once a similar request for one of our projects.

We used a Singleton class that contained the settings. All the objects knew about this object and were pooling their settings from there whenever they needed.

This Singleton had a isValid property. You obtained the configurations by the getInstance method of the Singleton. When isValid was false, the getInstance just reloaded the configs into the instance before returning it.

Basically, you changed the settings file that the Singleton was using and then invalidated the Singleton to announce it to reload its settings.

Answer 4

Depending on what is being changed there are a couple of ways to handle not restarting the application.

If you have all your settings in a singleton then you can tell it to reload from the config file and since the static values are in this, the application immediately starts to use the new values.

If you are changing something more critical, you may have to ensure that your application is designed in a way so that a controller can go in and make the necessary changes, but this may best require a restart, even if the user doesn't do it, but you just tell the application to reinitialize itself.

Answer 5

A variation on #2: Define a way to mark certain features to be settings. For example,

class Screen {
    ...
    [Setting("screen.blink")]
    public boolean Blink { ... set { ... } }
}

The idea here is that when the user toggles the screen.blink setting, your settings code will automatically do, say, Screen.Instance.Blink = true (or false). It's the same thing as the observer pattern, but it seems more loosely coupled to me.

On the other hand, the settings code has to know how to get its hands on the right object. In the toy example above I assume you can do Screen.Instance. That's rather simplistic. It all depends on your project. You would need to figure out a convention for finding configurable objects that works for you.

Answer 6

I partly agree with dpb. Using a Singleton is a good way for centralizing access of "cached" settings. However, this is passive access. When a setting is changed no class using the Singleton SettingClass will be notified of the change.

To get a notification mechanism you need to introduce some kind of publisher - subscriber pattern.

I understand that you have problems with introducing an event handler in your observer, because you argue that is not the responsibility of the observer. I agree with that.

If you have - for example - a passive business entity you do not want to pollute it with event handlers or attributes. Maybe you could use a combination of an observer and visitor pattern, so you don't need invasive actions on your classes for notification.