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