If you’re happy to unit test with hard-coded dependencies and you don’t need to change those dependencies then - yes - this pattern just adds more complexity. On the other hand, if you’re already using dependency injection, Context IOC is an interesting and arguably simpler option.

It’s always good to question anything that adds more lines of code, but I think your comparisons to plain object aggregation are missing the point.

You mention that with Context IOC we still have to actually create objects. The point is that those objects will be created in only one place and propogated down rather than being created on the fly in various places. Dependencies are still passed via the constructor, so Sony is not advocating some kind of paradigm shift.

Having said all that, this pattern certainly could be a “solution in search of a problem” (I assume that’s what Michael intended to say) in a lot of cases. But the same could be said about dependency injection and IOC in general, so I don’t think that fact invalidates the pattern. If you’re struggling with unit testing due to heavyweight dependencies, then that’s a problem for which Context IOC provides an effective and framework-free solution.

If he’s trying to make it more convenient to use mocks, then that is even worse - it just hides the smell “Too many dependencies”.