tl;dr: Contra my previous opinion,\ncontrollers are Service objects; my understanding of a \"Service\", regarding\nDI/SL Containers, was incorrect. However, I do continue to opine that it is\nbetter use a Factory to get new Controller instances, rather than getting them\nfrom the Container directly in a non-Factory object. All that and more in this\nfollowup post.
\nMy previous post generated\na great discussion on Reddit\nbetween myself and\n/u/ahundiak, which I suggest you read\nin its entirety. To summarize:
\nI thought of Services in a Container as objects that are retained for reuse\nthroughout the application; e.g. a PDO instance, a logger, etc.
\nahundiak disagreed, and pointed to the Symfony explanation of a Service as\n\"objects that do something\", even when not shared throughout the system.
\nI found that explanation unsatisfying and not well-defined.
\nHowever, ahundiak also said \"Symfony only creates service definitions for\nobjects which are actually injected somewhere.\" That piqued my interest,\nbecause it got closer to the heart what I was trying to express.
\nFrom there we ventured a bit further afield.
\n\n\n\nBased on that conversation, I did a couple hours' of research, using variations\non \"what is a service object\" (and you get some unexpected search results in a\ncouple of cases). In the end, though, I found myself at the Misko Hevery article\nTo new or not to new.
I have taken Misko's advice before, particularly from his article on\nHow to Think About the \u00e2\u0080\u009cnew\u00e2\u0080\u009d Operator with Respect to Unit Testing;\nI believe I refer to it in MLAPHP. In that\narticle, his final summary point is that your classes should either have\napplication logic in them, or have new operators, but not both.
The idea is that object construction is a concern to be separated from object\nuse. The end result is that you put all object construction into Factories,\nand anything that needs to create an object uses the Factory instead of the\nnew operator.
In his later article on \"To new or not\", Misko lays out definitions around\ntwo distinct groups of objects within any application. Lightly edited for\ncomprehension and emphasis, he says:
\n\n\n
\n- \n
\n\"Injectables\" are objects which you will ask for in the constructors and\nexpect the DI framework to supply. ... All external services are Injectables.\n... Sometimes I refer to Injectables as Service Objects, but that term is\noverloaded.
\n- \n
\nThere are a lot of objects out there which DI framework will never be able\nto supply. Let's call these \u00e2\u0080\u009cNewables\u00e2\u0080\u009d since you will be forced to call\n
\nnewon them manually. ... Newables are objects which are at\nthe end of your application object graph. ... Sometimes I refer to\nNewables as Value Object, but again, the term is overloaded.- \n
\nIt is OK for Newable to know about Injectable. What is not OK is for the\nNewable to have a field reference to Injectable.
\n
Now that is something I can wrap my head around. To a first approximation,\nNewables/Values are leafs on the object graph; everything else on the path to a\nNewable/Value is an Injectable/Service.
\nI think that very nicely backs up ahundiak's reference to Symfony's explanation\nabout Service objects, with some additional and welcome rigor.
\nMisko goes on to define some rules-of-thumb around Injectables/Services and\nNewables/Values. Paraphrasing and summarizing:
\n\n\n\n
\n- \n
\nAn Injectable can ask for primitives (int, float, string, etc.) and other\nInjectables in its constructor, but never a Newable.
\n- \n
\nConversely, a Newable can ask for primitives and other Newables in its\nconstructor, but never an Injectable.
\n
Based on Misko's definition (which is obviously better than my prior one)\nControllers are Services that a DI container can provide. Mea culpa.
\nHowever, I continue to stand by a corollary opinion I expressed in the previous\narticle: that you should not retain a Controller instance for reuse inside the\nContainer. Instead, you should use a Factory to create the Controller instance.\nFurther (and I did not say this explicitly) you should typehint on that\nFactory instead of the Container itself.
\nNow, it is well within the proper scope of a Container to be used as a Factory.\nA Container plays two roles: that of Factory (to create new object instances)\nand of Registry (to retain already-created instances for shared use). So in a\nDispatcher, for example, you could do this to run a Controller based on Route\ninformation:
\nclass Dispatcher\n{\n protected $container;\n\n public function __construct(Container $container)\n {\n $this->container = $container;\n }\n\n public function dispatch(Route $route)\n {\n $class = 'App\\Http\\Controller\\\\' . $route->getController();\n $object = $this->container->new($class);\n $method = $route->getAction();\n $params = $route->getParams();\n return $object->$method(...$params);\n }\n}\nThat's not bad -- by calling new() on the Container, you can tell the\nContainer is being used as a Factory, not a Registry. (Some Containers will\nallow you to configure certain types always to be new instances, so that calling\nget() will always return a new instance, but I am not a fan of that idiom.)
However, if you you consider\ntypehints as communication,\nthen typehinting on Container communicates \"the Dispatcher will need to create\nor locate anything the Container can provide.\" It's using the Container as a\nService Locator, and in general we ought to prefer Dependency Injection.
As an alternative, we might typehint on a ControllerFactory instead. That kind\nof typehint communicates a narrower requirement: \"the Dispatcher will need to\ncreate new Controller instances.\"
Putting together a ControllerFactory is easy enough ...
\nclass ControllerFactory\n{\n protected $container;\n\n public function __construct(Container $container)\n {\n $this->container = $container;\n }\n\n public function new(string $suffix) : Controller\n {\n $class = 'App\\Http\\Controller\\\\' . $suffix;\n return $this->container->new($class);\n }\n}\n... and then the Dispatcher can depend on that, instead of the Container:
\nclass Dispatcher\n{\n protected $controllerFactory;\n\n public function __construct(ControllerFactory $controllerFactory)\n {\n $this->controllerFactory = $controllerFactory;\n }\n\n public function dispatch(Route $route)\n {\n $object = $this->controllerFactory->new($route->getController());\n $method = $route->getAction();\n $params = $route->getParams();\n return $object->$method(...$params);\n }\n}\nOf course, the ControllerFactory itself now depends the Container -- the\ndependency on the Container just moved, it didn't disappear. Even so, this\narrangement is less objectionable for a couple of reasons:
\nThe \"creation of objects\" concern remains separated, per\nHevery's guideline\n\"to have either classes with logic OR classes with new operators.\"
The Controller instances being created really are likely to need a wide range\nof many different object injections, including shared objects from the\nContainer. The typehint of Container is an accurate communication here.
As often happens, the answer leads to more questions. In this case, I begin to wonder\nabout the kinds of objects that belong in a Container, per Misko's definitions.\nFor example, is an HTTP Request object something that ought to be created and\nretained within a Container? I can think of no Request implementations that\ndepend on Injectables; it seems more like a Newable, per Misko, in that it\nexists as a leaf on the object graph.
\nWell, I will leave that for another day. Many thanks to ahundiak for correcting\nme, or least leading me to correction, on this topic.
\nSee the Reddit conversation on this post here.
\n" }