3 ms·

hey! Thanks for replying! I just looked up the service lookup pattern and your right! I'll need to update the documentation accordingly. Would you mind sharin

hey! Thanks for replying! I just looked up the service lookup pattern and your right! I'll need to update the documentation accordingly. Would you mind sharing your thoughts on why it's an anti-pattern? Multiple companies I have worked with have all come up with their own solution for the issue of swapping out different services without requiring to touch the implementation code itself.

0xcoffee 5y ago
Sorry for late answer. I can give my perspective only from C# OOP perspective, which is my primary language. Dependency injection for me means, the constructor determines the dependency, and the injector will resolve what the constructor requires. The advantages of this are: 1. Writing unit tests, I know exactly what I need to mock, enforced by the compiler. I don't ever run tests and get an error because I forget to setup a service. 2. (In my opinion) It provides hints that a class has too many responsibilities and should be broken up. I can run a linter based on amount of constructor parameters that it is probably doing too many things. I strongly hold the opinion that the constructor defines everything needed by a class. At my company we use a mix of DI and service lookup because 'thats how its always been done', and it really makes testing unnecessarily harder. They decided when a constructor had over 3 services, to remove all the parameters and just pass a service locator because it 'looks nicer'. So that is my experience.
- yasserf 5y ago
  Thanks for the input! Makes a ton of sense. Services themselves are passed in other services on the constructor. The reason it isn’t done in the APIFunction is because of a uniform use / functions are called via a fixed interface. However I think there’s a decent middle ground with typescript where it can figure out what objects are being used and then only require your tests to mock those. That way you get better typescript safety. Thank you for the feedback!

0xcoffee 5y ago

Sorry for late answer. I can give my perspective only from C# OOP perspective, which is my primary language. Dependency injection for me means, the constructor determines the dependency, and the injector will resolve what the constructor requires. The advantages of this are: 1. Writing unit tests, I know exactly what I need to mock, enforced by the compiler. I don't ever run tests and get an error because I forget to setup a service. 2. (In my opinion) It provides hints that a class has too many responsibilities and should be broken up. I can run a linter based on amount of constructor parameters that it is probably doing too many things. I strongly hold the opinion that the constructor defines everything needed by a class. At my company we use a mix of DI and service lookup because 'thats how its always been done', and it really makes testing unnecessarily harder. They decided when a constructor had over 3 services, to remove all the parameters and just pass a service locator because it 'looks nicer'. So that is my experience.

yasserf 5y ago
Thanks for the input! Makes a ton of sense. Services themselves are passed in other services on the constructor. The reason it isn’t done in the APIFunction is because of a uniform use / functions are called via a fixed interface. However I think there’s a decent middle ground with typescript where it can figure out what objects are being used and then only require your tests to mock those. That way you get better typescript safety. Thank you for the feedback!