Inyección de dependencias y ajustes de aplicaciones

Digamos que estoy definiendo una clase de implementación de navegador para mi aplicación:

class InternetExplorerBrowser : IBrowser {
    private readonly string executablePath = @"C:\Program Files\...\...\ie.exe";

    ...code that uses executablePath
}

A primera vista, esto podría parecer una buena idea, ya queexecutablePath los datos están cerca del código que los usará.

El problema surge cuando intento ejecutar esta misma aplicación en mi otra computadora, que tiene un sistema operativo de idioma extranjero:executablePath Tendrá un valor diferente.

Podría resolver esto a través de una clase Singleton de AppSettings (o uno de sus equivalentes) pero nadie sabe que mi clase realmente depende de esta clase de AppSettings (que va en contra de las ideas DI). También podría plantear una dificultad para las pruebas unitarias.

Podría resolver ambos problemas teniendoexecutablePath siendo pasado a través del constructor:

class InternetExplorerBrowser : IBrowser {
    private readonly string executablePath;

    public InternetExplorerBrowser(string executablePath) {
        this.executablePath = executablePath;
    }
}

pero esto planteará problemas en miComposition Root (el método de inicio que hará todo el cableado de las clases necesarias) ya que ese método debe saber cómo conectar las cosas y debe conocer todos estos pequeños datos de configuración:

class CompositionRoot {
    public void Run() {
        ClassA classA = new ClassA();

        string ieSetting1 = "C:\asdapo\poka\poskdaposka.exe";
        string ieSetting2 = "IE_SETTING_ABC";
        string ieSetting3 = "lol.bmp";

        ClassB classB = new ClassB(ieSetting1);
        ClassC classC = new ClassC(B, ieSetting2, ieSetting3);

        ...
    }
}

que se convertirá fácilmente en un gran desastre.

Podría solucionar este problema pasando una interfaz del formulario

interface IAppSettings {
    object GetData(string name);
}

a todas las clases que necesitan algún tipo de configuración. Entonces podría implementar esto como una clase regular con todas las configuraciones incrustadas en él o como una clase que lee datos de un archivo XML, algo similar. Si hago esto, ¿debería tener una instancia de clase de AppSettings general para todo el sistema, o tener una clase de AppSettings asociada a cada clase que pueda necesitar una? Eso ciertamente parece un poco exagerado. Además, tener todas las configuraciones de aplicaciones en el mismo lugar hace que sea fácil mirar y ver cuáles podrían ser todos los cambios que necesito hacer cuando intento mover el programa a diferentes plataformas.

¿Cuál podría ser la mejor manera de abordar esta situación común?

Editar:

¿Y qué hay de usar unIAppSettings con todos sus ajustes codificados en él?

interface IAppSettings {
    string IE_ExecutablePath { get; }
    int IE_Version { get; }
    ...
}

Esto permitiría la seguridad de tipo en tiempo de compilación. Si veo que la interfaz / clases concretas crecen demasiado, podría crear otras interfaces más pequeñas de la formaIMyClassXAppSettings. ¿Sería una carga demasiado pesada para soportar en proyectos medianos / grandes?

También he leído sobre AOP y sus ventajas en relación con preocupaciones transversales (supongo que esta es una). ¿No podría también ofrecer soluciones a este problema? Quizás etiquetar variables como esta:

class InternetExplorerBrowser : IBrowser {
    [AppSetting] string executablePath;
    [AppSetting] int ieVersion;

    ...code that uses executablePath
}

Luego, al compilar el proyecto, también tendríamos seguridad en el tiempo de compilación (haciendo que el compilador verifique que realmente hayamos implementado código que entretejería datos). Esto, por supuesto, vincularía nuestra API con este Aspecto particular.