Hide class dependencies from end user instantiating it (PHP)

Question

Hi,

My situation is essentially this: I have a class called Foo which has dependencies A and B, all of which are internal to a library. Instances of Foo will be created by user of the library, and they should not require knowledge of the dependencies.

Internally of course I would like Foo to remain decoupled from the concrete implementations of A and B. I had considered a simple static factory class, however it would be necessary to configure this somehow for the dependencies (say Factory::$_staticAttr = x) and this seems wrong as it would essentially mean my static class has a state.

I've also been thinking some XML or otherwise configured dependency injection container, however it then raises the question of how to make the configured DIC's instance accessible without something messy like having it in a registry object.

I'm striving for some trivial method for the end user to generate an instance of Foo with everything injected, while keeping all the details of dependencies etc hidden within the library.

I've read around and the solution has not really made itself obviously to me as yet, so I'd appreciate any input :).

Thanks in advance, James

Answer 1

I myself use a dependancy injection container (a static factory) for these things. Consider reading this post: http://www.potstuck.com/2009/01/08/php-dependency-injection/

I'm striving for some trivial method for the end user to generate an instance of Foo with everything injected, while keeping all the details of dependencies etc hidden within the library.

I would definitely go for a factory in that case.

UPDATE

That's what static classes are for. They represent a certain state, as in this case. You only need one db adapter (per application|class|package), so you can reuse the same one again and again. Using global would be a lot more hackyish ;)

Answer 2

Thanks for your reply.

Mm, I read that article yesterday infact. My only issue was:

`Factory::$_database = $ourDatabaseVarForDB1;`

Though convenient, this sort of implementation strikes me as a bit of a hacky way to do it?

It does however tick the other boxes, so if there's no better case it'll need to be this way.