Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I would probably create a generic configuration class, and have each module depend on one or several concrete configuration classes that are singletons. A module depends on a configuration class instance with settings that are significant for that module only, and optionally on one or more other configuration class instances with settings that pertain to more than one module. Due to the fact that the configuration objects are singletons the modules that share configuration objects automatically get the same settings.</p> <p>You would create the configuration classes according to functionality, not according to module usage. The functionalities a module uses implicate which configuration objects it will need.</p> <p>Every module that gets added to an application adds all the needed configuration classes as dependencies, other configuration classes are not added. The singleton configuration objects add themselves to a list (or registry if you will) of such objects on application startup. The application itself does not need to know about details, just loading and saving the settings from and to persistent storage is enough. It can OTOH make use of the same infrastructure if it needs to.</p> <p>Generally I would implement everything in terms of interfaces, and leave the persistence mechanism outside. Thus you would be free later on to have configurations in INI files, the registry, or even a database (which would give you a simple way of implementing a history of configuration changes). I have found that I have not locked myself that much into a way of doing things since I started programming against interfaces instead of hierarchies of classes.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload