Re: Copland an IOC Containers in Real Use

Carsten Eckelmann wrote:
> Hi,
> 
> every so often I go and read the wonderful stuff, that Jamis has put 
> together for copland (http://copland.rubyforge.org). Everything makes 
> sense to me so far and the examples are simple enough to follow how it 
> works.

I'm so glad to hear that the documentation is readable. :)

> Still I just don't get it. I still can't grasp what it is that I get, 
> when I use copland. So my question to you, fellow rubyists: Is someone 
> out there actually using it for a real world project? Would care and 
> enlighten me why you chose copland and how it improves your project?

This is a common complaint that I hear about IoC containers in general, 
and Copland specifically. Especially in Ruby. Given Ruby's dynamic 
nature, I will confess that an IoC container does not buy you as much 
functionality as in a language like, say, Java. However, I have found 
that for large projects, Copland *can* make life easier. I'll say it 
again: *for large projects, Copland can make life easier.* Copland will 
buy you very little for small projects, and can in fact overcomplicate 
things if the project is of insufficient scope.

One more caveat before I launch into my use case: everything I use 
Copland for, can *definately* be done in another way in Ruby. I just 
know I'm going to get someone saying "but you can do that in Ruby by 
doing X, instead of using Copland!" 'Tis true. However, Copland brings 
together lots of interesting features in one place, and implements them 
for you. Why not take advantage of an existing project, instead of 
reinventing the wheel? :)

So, on to my use-case:

I'm (off-and-on) working on a personal finance manager, written in Ruby, 
using ActiveRecord for the OR mapping and some to-be-determined 
WEBrick-based front-end. This is one of the larger-scale apps I've 
implemented (by myself--for work I fry much larger fish, but on a team). 
For me, in this app, Copland fills the following niches:

1) Debugging. By using logging interceptors, Copland will automatically 
log whenever a method of a service is invoked, what it returned, and 
whether it threw an exception or not. This removes a lot of boilerplate 
code from my app. What is more, the interceptors are "attached" to 
services via configuration files, which means I can easily remove them 
(or reattach them) without the possibility of accidentally deleting 
crucial LOC. :) I've done it before... it hurts.

2) Delayed Instantiation. This is of dubious usefulness. I like it, 
others may not. What it means is, a service is not instantiated until a 
method is actually invoked on it. For services that are expensive to 
instantiate, this can save some cycles, especially if the service your 
request may not actually be used for some paths through your code. (I 
should note: the delayed instantiation feature is configurable. You can 
define services in such a way that they will always be instantiated 
immediately, if you prefer.)

3) Dependency Injection. By putting most of my functionality in various 
Copland services, I no longer have to explicitly instantiate 
dependencies between these services in code. Instead, I just specify the 
dependencies in the configuration files, and Copland "magically" 
determines the dependencies at instantiation time. It will instantiate 
dependant services, assign properties, etc, etc, all behind the 
curtains. This may make some people nervous, but it cleans up your code 
a lot more than you'd think. And clean code, is maintainable code.

Let me elaborate on #3 a bit more, since that's the one that took me the 
longest to grasp. Specifically, take the "Server" service in my PFM. It 
is simply a WEBrick server instance. In my configuration file, I specify 
that when the service is instantiated, it should be magically "hooked 
up" to a "Servlet" service. (The servlet is the WEBrick servlet that 
implements the front-end for the app.) The servlet service, in turn, may 
depend on other services, such as a "template" service for parsing and 
rendering templated data.

Copland, in this case, would process the dependency graph, and determine 
that it needs to first instantiate the "template" service, followed by 
the "servlet" service. Then it would assign the "template" service to 
some property of the servlet (as defined in the configuration file), or 
perhaps pass the template service as a parameter to the servlet's 
constructor. Once the servlet has been instantiated, Copland will 
instantiate the server.

When delayed instantiation is thrown into the mix, this becomes a bit 
muddier, since (for instance) the template service will not actually be 
instantiated until the servlet service tries to render a template...and 
the servlet service may not actually be instantiated until the server 
service tries to pass a request to it... But from the developer's 
perspective, it really doesn't matter (usually) when a service is 
instantiated, so long as it is instantiated in time to do what it is 
asked to do. And Copland makes sure that all happens.

> 
> Yes and thanks to Jamis for making such a nice Product even if it's way 
> over my head :)

You're welcome. :) Thanks for asking the question: the fact that it 
needed to be asked just shows that there remain some pretty significant 
holes in my documentation. *sigh* ;)

-- 
Jamis Buck
[e-mail]
http://www.jamisbuck.org/jamis

ruby -ropenssl 
-e'k="01234567";p((c,c.padding,c.iv,c.key=OpenSSL::Cipher::BF.new,0,k,k*2)[0].decrypt.update("1A81803C452C324619D319F980D5B84DBB45FC0FE2BAA045".scan(/../).map{|n|n.to_i(16).chr}.join))'