No, i contenitori e i costruttori IoC non violano il Principio Aperto / Chiuso.
Se devi aggiungere una nuova dipendenza alla tua classe, il modo Open / Closed per farlo sarebbe creare una nuova classe che erediti da quella vecchia e che abbia un nuovo costruttore con la nuova dipendenza, sovrascrivendo i metodi dove richiesto.
Se la tua classe orgional è "aperta" per l'estensione, questo dovrebbe essere possibile.
Il tuo contenitore IoC nella tua app, nel frattempo, non richiede alcuna estensione della sua funzionalità per registrare la nuova classe piuttosto che la vecchia. Quindi il principio di Open Closed non si applica affatto
La tua app stessa presumibilmente può tranquillamente consumare la nuova classe come una sottoclasse dell'originale e iniettata tramite IoC, quindi ancora una volta il principio non si applica.
Se si scopre che non si è in grado di creare una sottoclasse della classe originale e aggiungere la dipendenza e le funzionalità richieste e che è necessario modificarne il codice per far funzionare quella funzionalità extra. Quindi la tua classe originale ha fallito il test aperto / chiuso.
Tuttavia, in questi giorni immagino che tutti stiano usando le interfacce anziché le classi base. Così eviti molti di questi problemi.
Modifica. re: per quanto riguarda la classe radice nell'app?
Tecnicamente hai la stessa opzione con la classe principale della tua app, ovvero sotto classe e modifica la registrazione interna. Solo perché stai utilizzando un contenitore IoC, ciò non significa che non puoi ignorare la tua funzione di configurazione, rimuovere e aggiungere registrazioni o rendere la tua classe aperta all'estensione in altri modi.
Ma a questo livello non avrebbe senso farlo. A meno che l'app non sia un plug-in o altro, nessun altro codice lo consumerà, non c'è alcun svantaggio nel cambiare semplicemente il codice nella classe radice.