In last week\u2019s episode of this unexpected series, I said, \u201cGo ahead and use Service Locator, but make sure each Locator contains only one type of object. This condition of restraint will keep a single locator from becoming a menace.\u201d (I recommend \u201creal\u201d dependency injection containers as the preferred inversion-of-control mechanism; try the Aura.Di container.)
\nThe \u201conly one type of object\u201d constraint generated some discussion regarding factories and registries. On Reddit, teresko commented:
\n\n\nI don\u2019t think I have ever seen a use of Service Locator where it adhered to this rule. Hell \u2026 I am not even sure that you can call it \u201cService Locator\u201d then, because it is just a smarter sounding name for Registry pattern.
\nWhen you apply this rule, what you get instead is a factory, which enforces uniqueness of an instances, that it creates.
\n
On the blog itself, Adrian Mu asked:
\n\n\nIn the case of the Aura\u00e2\u0080\u0099s filter package am I wrong to interpret the \u00e2\u0080\u009crule service locator\u00e2\u0080\u009d as a \u00e2\u0080\u009crule factory\u00e2\u0080\u009d? If no, what is the difference between a factory and a service locator as you describe it? If yes, where?
\n
And on Twitter, Taylor Otwell asked a similar question:
\n\n\nthat \u201cone type\u201d of service locator is just a \u201cfactory\u201d, right?
\n
The differences between factories, registries, and containers (both service locators and dependency injection containers) can be subtle and hard to grasp at first. Here\u2019s how I keep them straight:
\na Factory creates and returns an object, but does not retain the created object for future use;
\na Registry retains an object instance by name for repeated use, but does not create that object;
\na Service Locator contains a named object (a \u201cservice\u201d) and creates it if it
\nhas a definition for that service; the creation logic might itself be a Factory, and the retention logic might itself be a Registry.
By way of example, I have put together an example service locator implementation along with an embedded test case. It has only two methods: set() and get():
The set() method takes an object name as its first argument, and
\na factory (in this case, a callable). The factories are retained in a registry (in this case, a plain-old PHP array).
The get() method looks in a registry of instances for the requested object by name and returns it. If the object is not there, it uses the factory for that object name and retains it in the instance registry.
Here\u2019s an example use:
\n<?php\n// create the service locator\n$locator = new PmjonesServiceLocator;\n\n// add a factory; this can be any callable, whether\n// a closure, an object with an __invoke() method,\n// a function name, a static class method, an object\n// instance and method name, etc.\n$locator->set('my_object', function () {\n return new VendorPackageClassName;\n});\n\n// get back an object instance; the locator\n// will create and retain it the first time\n$one = $locator->get('my_object');\n\n// the next and subsequent times, the locator\n// return the same instance\n$two = $locator->get('my_object');\nvar_dump($one === $two); // true\n?>\nThat should help illustrate the difference between a factory, a registry, and a service locator.
\nAgain, I must stress: Service locators can easily get out of control. If you can avoid using a service locator, you should. Instead of service locators, use dependency injection proper as much as possible, even though it is more work up front. If you must use a service locator: place only one type of object in it, use multiple locators if necessary, and inject each locator instead of using static calls for access.
\nIn Aura, we use dependency injection everywhere, all the time. In the rare cases that a service locator makes sense, that locator follows the \u201conly one type of object\u201d rule, and the locator itself is injected via the DI container. This makes the codebase very clean and a lot easier to test.
\nIf you like clean code, fully decoupled libraries, and truly independent packages, then the Aura project is for you. Download a single package and start using it in your project today, with no added dependencies.
\nRead the Reddit discussion about this post here.
\n" }