[ProgClub list] What is IoC?

John Elliot jj5 at progclub.org
Tue Oct 11 23:15:06 AEDT 2011


On 11/10/2011 9:31 PM, Asher Glynn wrote:
> Certainly factory
> methods seem to be a type of IoC from some descriptions?

It seems like it doesn't it?

I still don't understand what a "container" is from a client's 
perspective... it sounds very much like the client is going to have 
access to the content of the "container" which in my mind would be very 
much like it having been configured with a particular factory.

I try to avoid the keyword 'new' in all of my (non-trivial) software. I 
create static factory methods on my concrete types to obviate the need 
for new-ing types (you call the factory method instead, and it fails if 
it has to *before* the new object is created, constructors on the other 
hand run after the instance has been created). I then wrap these factory 
methods in an abstract factory, concrete implementations of which defer 
to classes' factory methods. So I have AbstractFactory calls 
FactoryMethod calls new. AbstractFactory picks an implementation (e.g. 
debug or production), FactoryMethod validates parameters, new is private 
and receives instantiation state from its factory method which has 
validated that state.

I tend also to pass in configuration in various ways. In my PHP code at 
the moment I've really been throwing up a few different approaches to 
"configuration" and in one of them I have my library code dependent on a 
static version of the config system. So when implementations need access 
to configuration information they can just access the static 
configuration object which stores and validates all configuration 
settings for the entire domain. I'm not sure if I like this approach 
however. The other approach would be to pass in (rather than have a 
static) configuration object.

As a contemporaneous and concrete example I had the Pccipher code that I 
released recently originally dependent on the "configuration" subsystem 
in the library that it was a part of. So instances of Pccipher just 
called get_config()->get_blowfish_secret() to read in the encryption key 
from a static configuration object. I needed to factor this dependency 
out however in order to release a stand-alone encryption library (that 
didn't depend on my framework services, specifically the configuration 
services). So what I did was pass the configuration information (i.e. 
the blowfish key) into the construction/invocation of Pccipher.

So in practice I tend to have an application wide factory for producing 
concrete implementations in a particular configuration and an 'ambient' 
(static) configuration system that can just be used by (and extended in) 
applications. I suspect that these two things, that is a configuration 
object and an abstract factory object, in some way fill the role of 
"container" from IoC, although Stuart hasn't explained containers yet, 
so I'm guessing.



More information about the list mailing list