Talk:Requests for comment/Dependency injection

Discussion regarding the older proposal now at Requests_for_comment/Dependency_injection/2014

The DI mechanism is a detail

Inversion of control is very important, and things such as constructor and setter injection can be used to achieve it. Applications then need to be able to construct their object graphs, and can do so in various ways, including by using a Dependency Injection Container (which seems to be what this RFC is about). The only part of the application that should know about the DI container is the part near it's entry points responsible for construction. A common thing that goes wrong in projects when they introduce a DI system is that it gets pulled in from all over the code and talked to directly, since people find that more convenient than actually requiring the depenedencies via constructor injection. (This is not an objection against proceeding - it's definitly good to proceed, one should just be careful about this pitfall.)

-- Jeroen De Dauw (talk) 20:55, 12 August 2014 (UTC)

Good point! --AGreen (WMF) (talk) 13:49, 21 August 2014 (UTC)

Good or bad?

I don't get the following statement which seems to contradict itself. --Nikerabbit (talk) 12:31, 15 August 2014 (UTC)

With regard to using RequestContext as a central registry, it seems that that does make sense since RequestContext appears throughout Mediawiki code, so using it would increase coupling, not loosen it.

Woops! Yeah, there's a "not" missing. I just fixed it. Thanks much! --AGreen (WMF) (talk) 13:50, 21 August 2014 (UTC)

IFooBar

I hate to knit pick but the whole IFooBar pattern fell out of favor in the Java community (where I come from) a while ago and seeing it here is sad. This is there a reason we need an interface at all? Java stopped needing it when we got better mocking. Is that not a thing in PHP?

I added this comment a few days ago and thought the tool would sign this for me. You know, like Flow and LiquidThreads do. Sorry for the unsigned post.NEverett (WMF) (talk) 15:01, 9 September 2014 (UTC)

Thanks for this!! I guess you're talking about JMockit? (Yeah, in my Java days—not that long ago, really—I only got as far as Mockito.) I think that separating out interfaces is not a requirement for DI or a DI framework, and it's not a requirement for mocking with PHPUnit. Also, BTW, are there viable mocking frameworks that can intercept new in PHP? If so, I think it can be a game changer. Though it seemed that PHPUnit might go in the opposite direction and removing static mocking. :) --AGreen (WMF) (talk) 19:21, 10 September 2014 (UTC)

Discussion regarding the current proposal at Requests_for_comment/Dependency_injection

"Hard-coded" service locator?

The distinction you make between a "hard-coded" service locator and a "configurable" service locator makes it sound like you're thinking the getDatabase() method would be hard-coded to return a new DatabaseMysqli. Most of our existing service objects are already easily configurable, so I doubt that's what you meant. Anomie (talk) 14:32, 3 November 2015 (UTC)