Por que usar serviços (IServiceProvider)?

Estou chegando a essa pergunta explorando a estrutura XNA, mas gostaria de um entendimento geral.

ISomeService someService = (ISomeService)Game.GetServices(typeof(ISomeService));

e depois fazemos algo com quaisquer funções / propriedades que estejam na interface:

someService.DoSomething();  // let's say not a static method but doesn't matter

Estou tentando descobrir por que esse tipo de implementação é melhor do que:

myObject = InstanceFromComponentThatWouldProvideTheService();

myObject.DoSomething();

Quando você usa a maneira de serviços para obter sua interface, está realmente obtendo uma instância do componente que fornece o serviço de qualquer maneira. Certo? Você não pode ter uma interface "instância". E há apenas uma classe que pode ser a provedora de um serviço. Então, tudo o que você realmente tem é uma instância da sua classe de componente, com a única diferença: você só tem acesso a um subconjunto do objeto de componente (qualquer subconjunto que esteja na interface

Como isso é diferente de apenas ter métodos e propriedades públicas e privadas? Em outras palavras, os métodos / propriedades públicos do componente na "interface", e podemos parar com toda essa rotunda. Você ainda pode alterar a maneira como implementa essa "interface" sem interromper nada (até alterar a assinatura do método, mas isso também interromperia a implementação dos serviços).

E, de qualquer maneira, haverá um relacionamento 1 para 1 entre o componente e o serviço (mais de uma classe não pode se registrar para ser um provedor do serviço) e não consigo ver uma classe sendo um provedor de mais de um serviço (srp e tudo isso).

Então eu acho que estou tentando descobrir que problema esse tipo de estrutura pretende resolver. O que estou perdendo

questionAnswers(4)

yourAnswerToTheQuestion