Dany Paredes
Thank you for elaborating on the advantages and disadvantages of the Service Locator pattern. I agree that the pattern can provide benefits such as flexibility and enhanced separation of application layers. However, I still have concerns about violating important design principles and complicating testing when using this approach.
In light of your response, I wonder if you could provide some more complex examples or scenarios(idea for the second part of article?🤔😄) where you think the Service Locator pattern, and specifically the inject() function in Angular, would be a better choice than Dependency Injection. It would be helpful to see some practical use cases that demonstrate the advantages of this approach. Thanks again for the post 😊
P.S. But I should note that at first, when I accidentally discovered this approach, I was very pleased🤩
After some time, when I wandered through the Angular source code, I saw this approach there(if I'm not mistaken 😅)
Hello Dany Paredes!
Thank you for the article. It reminded me of when I passed an injector from a child class to a parent class, but after a short period of time, I rewrote everything back. Here is a small example:
` class Base { protected param: Param; protected param1: Param1;
constructor(injector: Injector) { this.param = injector.get(Param); this.param1 = injector.get(Param1); } }
class Child extends Base { constructor(injector: Injector, private childParam: ChildParam) { super(injector); } } `
When we use the injector(in your case is a "inject()") as a service locator, we violate the encapsulation, we also violate the segregation of interfaces. In general, the service locator is an anti-pattern. Based on that, don't you think it's the same thing? Because now it is not clear what dependencies are needed to make this class work.