[PRL] TheServerSide.com - Examining the Validity of Inversion of Control

John Clements clements at brinckerhoff.org
Thu Feb 17 11:15:58 EST 2005


On Feb 15, 2005, at 11:04 PM, Mitchell Wand wrote:

> Here's another design pattern that seems to be getting some attention. 
>  Anybody here know about this one?
>
> --Mitch
>
>
> Inversion of Control (IOC) through injection also known as Injection 
> IOC has not been a designer or programmer friendly pattern. Many 
> question its validity and the validity of IOC in general. IOC seems to 
> be a contradiction to the fundamental concept of object encapsulation. 
> Context IOC is a new approach that attempts to capture Inversion of 
> Control as a pure design pattern to demonstrate that IOC is indeed a 
> very powerful concept.
>
> <http://stage.theserverside.com/articles/article.tss?l=IOCandEJB>

It looks like these people are reaching toward Units (in the mzscheme 
sense) with contracts.  It appears (from a very brief reading of this) 
that there are (at least) two things they haven't thought about hard 
enough:

1) the possibility of more than one "top level".  That is, the 
components are not bound tightly, but are instead connected "at the top 
level."  As compound units show, there doesn't need to be just one "top 
level."   On the other hand, it's true that the later you bind the 
components, the more flexibility you have.

2) This page describes the late-connection model as being "less 
abstract" (if I'm reading this correctly).  While it's true that this 
model of programming exposes the contracts of small components to the 
top levels, it is in fact _more_ abstract, in the sense that the 
authors of the small components can depend only on their stated 
contracts in their interactions with other components.

Thanks for the pointer,

john
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2169 bytes
Desc: not available
Url : https://lists.ccs.neu.edu/pipermail/prl/attachments/20050217/16768329/smime.bin


More information about the PRL mailing list