How to manage application configuration ?
-
I am asking for suggestions on how to manage multi object application configuration. I have a hardware intensive application where objects contribute to overall application configuration. Some objects require knowledge / access of / to previously configured objects - there is required sequence in building the application configuration. I do have a main/ primary object and sort of tree structure (menu driven) of the rest of them . Where would be the most logical place to build and keep the commonly accessible "configuration object "? Should it be a separate object or part of the "main object" ? Thanks
-
I am asking for suggestions on how to manage multi object application configuration. I have a hardware intensive application where objects contribute to overall application configuration. Some objects require knowledge / access of / to previously configured objects - there is required sequence in building the application configuration. I do have a main/ primary object and sort of tree structure (menu driven) of the rest of them . Where would be the most logical place to build and keep the commonly accessible "configuration object "? Should it be a separate object or part of the "main object" ? Thanks
I'd say it doesn't matter. There are pros and cons to each solution. If you make it part of the main object you have fewer global/high-level objects but every time you access the configuration you go through the main object. This means at least more typing. If you make it a separate (global) object, the opposite is true. My own take: some years ago I was going with the config as part of the main object for reasons of "code purity". These days I go with a separate object for pragmatic reasons.
Mircea
-
I'd say it doesn't matter. There are pros and cons to each solution. If you make it part of the main object you have fewer global/high-level objects but every time you access the configuration you go through the main object. This means at least more typing. If you make it a separate (global) object, the opposite is true. My own take: some years ago I was going with the config as part of the main object for reasons of "code purity". These days I go with a separate object for pragmatic reasons.
Mircea
-
I am asking for suggestions on how to manage multi object application configuration. I have a hardware intensive application where objects contribute to overall application configuration. Some objects require knowledge / access of / to previously configured objects - there is required sequence in building the application configuration. I do have a main/ primary object and sort of tree structure (menu driven) of the rest of them . Where would be the most logical place to build and keep the commonly accessible "configuration object "? Should it be a separate object or part of the "main object" ? Thanks
Presuming that I understand what you are saying.
Member 14968771 wrote:
Some objects require knowledge / access of / to previously configured objects
That is basically an incorrect way to think of that unless you stated it incorrectly. You have class A1 which can have an instance a1. Now a1 not A1 is the only thing that is 'configured'. Then there is class B1 which has instance b1. And instance b1 needs access to a1. Note that b1 does NOT have access to the configuration for a1. It should not even know that a1 is 'configured'. Conversely if b1 needs access to the same configuration information as a1 then the configuration information should not be limited to a1 but should be generic. As an example if you have UI objects that represent a Box and a Button and both use a 'configured' color X then you would call that X something like 'outline.color.border'. You would not call it 'Box.color.border' Now AFTER you figure out the hierarchy of the configuration data then you figure out the best way to manage it. Generally you would have a parallel set of configuration objects which in some way are related to each other and which expose the loaded configuration data. C#, as one example, has a dynamic class structure which supports creating from configuration files. But the same thing can be achieved (and perhaps is easier to understand) just by have one class with a method that takes a name and returns a value. But regardless the configuration object (or objects) is entirely independent from the classes that use the configuration. As a reminder do not forget about error handling and default values. If the configuration file is not found or a configuration value is missing (because it is misspelled) then what do you want the application (and objects) to do.
-
Presuming that I understand what you are saying.
Member 14968771 wrote:
Some objects require knowledge / access of / to previously configured objects
That is basically an incorrect way to think of that unless you stated it incorrectly. You have class A1 which can have an instance a1. Now a1 not A1 is the only thing that is 'configured'. Then there is class B1 which has instance b1. And instance b1 needs access to a1. Note that b1 does NOT have access to the configuration for a1. It should not even know that a1 is 'configured'. Conversely if b1 needs access to the same configuration information as a1 then the configuration information should not be limited to a1 but should be generic. As an example if you have UI objects that represent a Box and a Button and both use a 'configured' color X then you would call that X something like 'outline.color.border'. You would not call it 'Box.color.border' Now AFTER you figure out the hierarchy of the configuration data then you figure out the best way to manage it. Generally you would have a parallel set of configuration objects which in some way are related to each other and which expose the loaded configuration data. C#, as one example, has a dynamic class structure which supports creating from configuration files. But the same thing can be achieved (and perhaps is easier to understand) just by have one class with a method that takes a name and returns a value. But regardless the configuration object (or objects) is entirely independent from the classes that use the configuration. As a reminder do not forget about error handling and default values. If the configuration file is not found or a configuration value is missing (because it is misspelled) then what do you want the application (and objects) to do.
Let me try differt way of describing / expressing the problem Object A builds a "CONFIG A" Object B needs access to "CONFIG A" to build "CONFIG B" Object C needs both "CONFIG A" and "CONFIG B" to operate. I am working on building a library , hence common access, where to "store" both "CONFIG A" and "CONFIG B". PS The example may be illogical - only "CONFIG B" shlud be needed by object C....
-
Let me try differt way of describing / expressing the problem Object A builds a "CONFIG A" Object B needs access to "CONFIG A" to build "CONFIG B" Object C needs both "CONFIG A" and "CONFIG B" to operate. I am working on building a library , hence common access, where to "store" both "CONFIG A" and "CONFIG B". PS The example may be illogical - only "CONFIG B" shlud be needed by object C....
No that doesn't help at all. Making it as simple as I can... There is a set (one or more) objects that use the configuration. There is another set (one or more) objects that manage the configuration (lets say read it from a file.) The two sets must not be the same.
