We want to design many objects to be configurable.
For example, configure FlashingHighlighter. It would make sense to have a class called FlashingHighlighterConfig(or such) that handles configuring the object using PlayerPrefrences(or any equivalent)
Design Concept
One way to solve this problem is to implement a ConfigureObject that maps user settings configuration to an object.
This will require a ConfigurationManager(yay like we need another one of these). Such manager will have access to all Configurable objects (either manually referencing each, or automation). Access to user settings will be required. With this, we can fake user settings in inspector.
Implementation Concept
That class could look like the following:
And we would expand for classes that cannot extent ConfigureObject to the following:
Example
And for those with the reference way
Implementation Cost
We have some configuration implemented in ConnectomeScene. It shouldn't be in there. Each configuration logic should moved into a ConfigureObject
This will also require an instance object of UserSetting. Inevitably, this solution would eliminate the need for havingUserSetting` be a static class which should not cost much.
Closing
Disagreements are welcomed as long as they aim to solve this configuration problem. What might be issues with this solution? Is there a better way? Do you think I use proper variable naming? Please share your thoughts with the team.
We want to design many objects to be configurable.
For example, configure
FlashingHighlighter. It would make sense to have a class calledFlashingHighlighterConfig(or such) that handles configuring the object usingPlayerPrefrences(or any equivalent)Design Concept One way to solve this problem is to implement a
ConfigureObjectthat maps user settings configuration to an object.This will require a
ConfigurationManager(yay like we need another one of these). Such manager will have access to all Configurable objects (either manually referencing each, or automation). Access to user settings will be required. With this, we can fake user settings in inspector.Implementation Concept That class could look like the following:
And we would expand for classes that cannot extent
ConfigureObjectto the following:Example
And for those with the reference way
Implementation Cost We have some configuration implemented in
ConnectomeScene. It shouldn't be in there. Each configuration logic should moved into aConfigureObjectThis will also require an instance object of
UserSetting. Inevitably, this solution would eliminate the need for havingUserSetting` be a static class which should not cost much.Closing Disagreements are welcomed as long as they aim to solve this configuration problem. What might be issues with this solution? Is there a better way? Do you think I use proper variable naming? Please share your thoughts with the team.