Зачем нужны службы (IServiceProvider)?

Я подхожу к этому вопросу после изучения структуры XNA, но мне хотелось бы получить общее представление.

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

а затем мы делаем что-то с любыми функциями / свойствами, имеющимися в интерфейсе:

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

Я пытаюсь понять, почему такая реализация лучше, чем:

myObject = InstanceFromComponentThatWouldProvideTheService();

myObject.DoSomething();

Когда вы используете способ получения интерфейса с помощью служб, вы на самом деле просто получаете экземпляр компонента, который в любом случае предоставляет службу . Правильно? У вас не может быть "экземпляра" интерфейса. И есть только один класс, который может быть поставщиком услуги. Таким образом, все, что у вас действительно есть, - это экземпляр вашего класса компонента, с той лишь разницей, что у вас есть доступ только к подмножеству объекта компонента (независимо от того, какое подмножество есть в интерфейсе).

Чем это отличается от простого наличия публичные и частные методы и свойства? Другими словами, общедоступные методы / свойства компонента - это «интерфейс», и мы можем остановиться со всеми этими окольными путями. Вы все еще можете изменить способ реализации этого «интерфейса», ничего не нарушая (до тех пор, пока вы не измените сигнатуру метода, но это также нарушит реализацию служб).

И будет связь один-к-одному между компонент и службу в любом случае (более одного класса не могут зарегистрироваться в качестве поставщика службы), и я не вижу, чтобы класс был поставщиком более одной службы (srp и все такое).

Итак Думаю, я пытаюсь понять, какую проблему призван решить этот фреймворк. Что мне не хватает?