On 06/27/2015 03:30 PM, Ashley Sheridan wrote:
On 27 June 2015 19:05:18 BST, Larry Garfield <larry@xxxxxxxxxxxxxxxx> wrote:
On 06/20/2015 08:00 AM, Jesse Schalken wrote:
Also also, I've never quite figured out why "dependency injection
containers" exist. Dependency injection just means you pass through
to a
class/method the things it needs, rather than letting it instantiate
them
itself, so the caller can decide how those dependencies are
implemented. If
lots of things need the same set of dependencies, then just wrap them
all
up in another class that has properties or getters for each. It's not
hard.
What you describe is a service locator. Which is basically the same
thing as a dependency injection container that you pass into the object
you're using. Google "service locator bad" for why you shouldn't do
that. :-)
--Larry Garfield
I do think in some circumstances it's the responsibility of the class itself to ensure only one instance of itself exists.
Consider a class that loads in file excerpts on a loop, and stores them in the object structure to avoid repetitive disk reads that aren't necessary. If the class is set up as a Singleton, it can't be misused by other code. Dependency injection won't solve that.
That's totally easy to do with caching in the service object itself.
Having a "read twice" guard is fine, and often good. But the object
should not be its own guard. That makes unit testing it, or using it in
cases where you may not want the guard, or using it in pretty much any
situation other than the very specific one you coded it for, much harder
or impossible.
Complecting together multiple different responsibilities (loading file
off disk, caching, and a guard) is very very easy to do. It's also a
trap. Sustainable code requires active, conscious effort on the part of
the developer to avoid inadvertently complecting responsibilities together.
--Larry Garfield
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
