Simon Strandgaard wrote:
> On Saturday 04 September 2004 22:57, Jamis Buck wrote:
> [snip]
> 
>>That works, too. :) Frankly, it isn't until you ramp up to some fairly
>>complex applications that IoC really starts to buy you anything. (The
>>text editors that have recently been announced have seemed in my mind
>>prime candidates for IoC.) And for really small projects, it can just
>>get in the way. It's also not something you use "ad-hoc"--it requires a
>>fair bit of thought and design "up-front" to really take advantage of.
> 
> 
> 
> Text editor.. hmm..  im working on an editor, so now you have woken my 
> interest. I have looked at copland + the documents you link to, but im 
> affraid I don't understand what it is..  

Well, I've never written a text editor. (Sascha, feel free to nail me on 
that.;) However, I've written an ebook reader, so I think I have some 
*minor* idea of how such a beast might go together. I'll give my opinion 
of how something like a text editor might be architected using IoC.

I think you'll find that the architecture isn't very different from what 
you might already have.

Basically, look at the subsystems (and the sub-subsystems, and so 
forth). You might have a VFS subsystem, a command subsystem, a rendering 
subsystem, and so forth. The VFS subsystem might be further broken down 
into a zip abstraction, an FTP abstraction, and an abstraction for a 
conventional file system.

Once you have an idea of what all the pieces are (and how they relate to 
each other--that's important!) you then arbitrarily change their name 
from "subsystem" to "service", and you're halfway to Copland. The 
remainder of the trip involves changing your way of thinking from "the 
VFS instantiates the zip abstraction, et. al." to "the VFS has a 
dependency on a list of file system abstractions". The VFS _doesn't 
care_ what those abstractions are, and has no code for instantiating 
them. Instead, it just expects some other entity to give it that list at 
some point early in its lifecycle.

That's where the container comes in. You tell the _container_ explicitly 
what those dependencies are (the term that Copland uses is 
"configuration point") and then when Copland is asked to instantiate a 
VFS service, it will go out and follow the dependencies and instantiate 
all dependent services for you. Once they are all instantiated, it then 
gives the list of file system abstractions to the new VFS object, and 
returns that new VFS object to the caller, you.

The benefit here is that if you want to add another abstraction, you add 
the relationship between it and the VFS to a configuration file instead 
of code. This means that any third-party abstraction that fulfills the 
necessary contracts can be painlessly plugged into your application 
without needing to modify any code.

Notice, too, that your services are just plain-old Ruby objects, but 
where they used to instantiate their dependencies themselves, now they 
have setters for those dependencies, and expect to be given them at 
creation time. This has benefits for unit testing, too, since you can 
easily assign mock objects to any property of a service!

Is this a new idea? No. Are you already doing something like this? 
Probably. It's just good design, to minimize coupling between 
components. All an IoC container does is generalize that into a reusable 
framework that you can take advantage of repeatedly and consistently.

Admittedly, most IoC containers give you more than just "dependency 
injection" (which is more or less what I just described). Copland, for 
instance, provides some AOP-like functionality via "interceptors", which 
allow you to add code that is executed before and after (and around) 
method invocations on designated services. But the dependency injection 
(DI) pattern is the strong point of IoC containers.

> 
> Martin Fowlers document about what IoC is.. is too long..   I learn stuff by 
> looking at lots of examples. The 3 links you have on your page that should 
> explain its concept.. I don't understand them at all.. sorry.

Well, I hope the above wasn't too long. :) I agree, though--I haven't 
ready completely through Fowler's article, either, though I've skimmed 
most of it. I encountered it after I had a general idea of what IoC was 
all about, though.

I'll work on getting some more comprehensive examples out.

> 
> Copland looks interesting to me.

That alone is a promising statement. Now if I can just get you to 
_adopt_ it... ;)

> --
> Simon Strandgaard

- Jamis

-- 
Jamis Buck
jgb3 / email.byu.edu
http://www.jamisbuck.org/jamis

"I use octal until I get to 8, and then I switch to decimal."