This pattern can be used as alternative to Observer or Mediator pattern, in the situations where the number of objects that require dynamic configuration is large and the configuration keeps changing very frequently at runtime. In such situation the Observer or Mediator pattern can become bottleneck due to large number of objects to be updated with the configuration.
Configuration Manager: object contains the latest configuration along with its version, Configuration Manager can also contain logic to accept new configuration, validate it and keep track of current valid configuration by assigning a version id.
Configuration Manager should also provide method to get current version and get latest configuration.
Configuration: An abstraction of configuration (may not be required in simple implementation).
Configured Object: This is the object which needs the configuration update at runtime. This object must have an attribute to keep reference of Configuration Manager. When an operation is invoked on configured object, it checks its current configuration version with the version at Configuration Manager and decides if needs updated configuration from Configuration Manager.
Object Factory: The object factory creates instances of Configured Object initialized with correct Configuration Manager.
This pattern allows lazy update of shared configuration at runtime, without forcing update configuration for all the objects at once. It also reduces burden of configuration update further, as each object decides when to update its configuration (at the time when an operation is invoked on it). The advantages of lazy configuration update become more pronounced as only update of configuration parameter at Configuration Manager requires synchronized access.
The Object Factory can create instance of configured objects setting other attributes and reference to Configuration Manager leaving configuration for lazy update by Configuration Manager.
Configuration Manager can implement logic to accept and validate configuration as required, thus reducing complexity of Configured Object. It can also keep history of configuration changes if such logs are required, this can also enable Configuration Manager to rollback to a particular version of configuration.
In simple implementation the Configuration Manager can also take up role of Object Factory.
You may not need an abstraction of configuration; the concrete Configuration Manager can use setters on Configured Objects to update configuration attributes.
I have used this pattern for developing a decision matrix based rule engine API. Rules for decision can be updated at runtime (i.e. Add, delete and update) even when rule engine is executing. Also there can be multiple instances of rule engine using same rule set (configuration) especially in multithreaded applications.
Observer pattern and Mediator pattern.