[ProgClub list] What is IoC?

Asher Glynn asher.glynn at gmail.com
Wed Oct 12 02:35:46 AEDT 2011

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

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.

Interested in other perspectives.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.progclub.org/pipermail/list/attachments/20111011/497c7f8f/attachment.html>

More information about the list mailing list