Simon Strandgaard 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
···
On Saturday 04 September 2004 22:57, Jamis Buck wrote:
--
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."