0

Question

In the context of an MVC, desktop architecture, is there a canonical solution or a design pattern / best practice to give access to an immutable value class to multiple components at different levels of nesting?

Use case examples:

  • User settings: Some controllers or views need to access the user settings so that their behavior complies to the user preferences
  • Current theme: every view must have access to the current theme so that they know which colors, fonts, and styles to use

Note that these classes are not necessarily singletons (we could want to create different Theme instances at a time for instance) BUT the current theme should only point to one instance at a time. This reference would be the single version of truth, even though the instance it references could change over time.

Concrete example

My MainWindow component has far too many responsibilities so I want to break it down into just a few, higher level components. These new components should have only one responsibility so that the MainWindow is merely the glue which holds them together and delegates method calls when required.

But some of these sub-components need to access the user settings at some point. These settings are managed by SettingsComponent which is a direct child of the MainWindow. The only way other components can access the settings is to call methods from SettingsComponent. So, if I encapsulate the lower-level components into higher level components, they won’t have access to SettingsComponent anymore.

Some (bad?) solutions

1- Expose a static reference to the instance of MainWindow (since there can be only one for the lifetime of the application). To access the settings or the current theme, each component could then call: Gui.getMainWindowInstance().getSettingsComponent().getSettings()

2- Keep and manage a copy of the user settings inside every component which need to know about them. When the settings change, these components will be notified and update their own copy of the settings accordingly. This solution doesn't seem right because:

  • There won't be a single version of truth anymore.
  • It feels weird to have views keep a reference to an instance of the user settings

3- Externalize the Settings from SettingsComponent to a service or provider class. This class would expose static methods which could be consumed anywhere from any component. Pseudo-code example:

class SettingsProvider {
    get(): Settings { /* ... */ }
    update(settings: Settings): void { /* ... */ }
}

So from anywhere in my code I could do:

class SomeComponent {
    someMethod(): void {
        settings = SettingsProvider.get();
        // do stuff
    }
}

This third solution seems cleaner but I wonder if it would be a good practice or just makeup on a poorly designed software.

Am I missing an obvious, cleaner solution?

How is this problem usually solved? Is there any article, book, or online resource which provides a clean solution to this specific problem?

1
  • There isn't even a canonical agreement about how an MVC architecture has to look like, and definitely not a programming language environment agnostic one. Each environment has other means of providing "globally visible", "shared" state or data, and often there is more than just one possible solution. For example, for database-centric application, often the central database is used for exactly this, sometimes together with an event mechanism when central configuration data changes.
    – Doc Brown
    Apr 21, 2021 at 20:20

1 Answer 1

2

This sounds a lot like the class of problems that Dependency Injection intends to solve.

If you want to avoid depending on a DI framework, you could create and keep the settings and style objects in your main window object and pass a reference to the main window to every subcomponent. If the subcomponent needs to access the settings, it may ask the main window just like in your first case, except that it wouldn't access a global variable but the reference to the main window injected into it upon construction.

I'd avoid creating intermediate components such as a SettingComponent whose only job is to keep an instance of Settings. Store the Settings in your main window and be done with it. Doing someObject.getThis().getThat() looks ugly. Instead grab the settings from the window for later use if you need it:

settings = mainWindow.getSettings()
...
if (settings.getBool("SaveOnEachChange")) {
   doChange();
}
2
  • Thank you! I indeed want to avoid using a DI framework so I can get better at designing desktop software architecture. I have a question regarding your solution: When the current theme changes, MainWindow would have to notify every component (event very low-level components like buttons or simple containers). This would mean MainWindow should keep a reference to every GUI components in the application? The same would apply for the user settings. This would mean I'd be drilling several levels deep to pass two parameters: an instance of Settings and Theme to every constructor? Am I correct?
    – orangeBall
    Apr 21, 2021 at 15:39
  • Don't overcomplicate things. Visual property changes are usually communicated through the already present hierarchy of visual components, the main window doesn't need to keep references to every single low-level item, it just notifies the directly contained components. The same could be done for settings, but it's normally not necessary to react immediately to setting changes unless they are reflected in UI visual states. Apr 21, 2021 at 19:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.