<div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Certainly factory<br>
methods seem to be a type of IoC from some descriptions?<br>
</blockquote>
<br></div>
It seems like it doesn't it?<br>
<br>
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.<br>

<br>
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.<br>

<br>
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.<br>

<br>
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_<u></u>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.<br>

<br>
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.</blockquote>
<div><br>I've used Spring and PicoContainer with varying degrees of success, which is kind of where my crisis of faith is coming from. In Java-land (especially J2EE land) you have containers all over the place, usually not specifically IoC ones, inspite of the SpringSource chappies best efforts at doing so. I think one of the theories of containers is that they allow you to run multiple configurations with specific container based logic being applied in various places as well as managing resource lifecycle. The result isn't 100 miles away from what you are describing John.<br>
<br>Interested in other perspectives.<br></div></div>