[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