cfis : Rails' Unusual Architecture

Comment on Rails' Unusual Architecture by Jim Cropcho

Wed, 05 Sep 2007 07:14:13 -0600

Oh, so that’s how the hell Rails works. It really is an interesting implementation, caveats and all. Great post!

Comment on Rails' Unusual Architecture by Jeff

Wed, 05 Sep 2007 08:32:53 -0600

Great post. Can I ask a question?

Why do they do this:

ActionController::Base.class_eval do
  include ActionController::SessionManagement
end

instead of simply re-opening the class?

class ActionController::Base
  include ActionController::SessionManagement
end

Is there a difference or is it just a question of style?

Comment on Rails' Unusual Architecture by Peter Williams

Wed, 05 Sep 2007 08:40:48 -0600

To be fair I think it is a bit stretch to say that the architecture of SIAS was a chain of responsibility. We were certainly influenced by that pattern but in practice it turned out to be extremely difficult (to the point of impossibility) to make a pure chain of responsibility work as the basis for a web application framework.

If you are looking for a pattern to base a web application framework on I think decorator would be a much better choice. In fact, not that I think about it that is the pattern you are describing, not chain of responsibility.

Comment on Rails' Unusual Architecture by choonkeat

Wed, 05 Sep 2007 10:08:27 -0600

@jeff: Thanks for asking. It made me wonder.. I went searching, and the best answer I found is at http://r1.sharedcopy.com/k8lgi#shcp1

Comment on Rails' Unusual Architecture by Jacob

Wed, 05 Sep 2007 10:25:52 -0600

the problem with re-opening a class is that is may not have been loaded yet. If this happens:

class ActionController::Base
  include ActionController::SessionManagement
end

and ActionController::Base is not already defined then a new class will be defined and the logic that runs on self.included may run and not find a process method for alias_method_chain to work on. (in which case you’d get an exception)

Whereas if you do:

ActionController::Base.class_eval do
  include ActionController::SessionManagement
end

You are asserting that ActionController::Base is already defined before you open it. (if it’s not, rails const_missing will find and load it) Thus forcing it to be fully loaded before you go and change it.

Comment on Rails' Unusual Architecture by James Britt

Wed, 05 Sep 2007 11:16:46 -0600

Could you explain how Java manages to support AOP, yet Ruby does not?

Comment on Rails' Unusual Architecture by Alan Shutko

Wed, 05 Sep 2007 15:26:34 -0600

There’s been a lot of tricky work done on Java to make it support it. The original AOP work had a precompiler you needed to turn your source into Java source. Spring has a more limited form of AOP built in which relies on dynamic proxies (or building proxy byte code at runtime with cglib). It’s hidden from the user, but requires a lot of work behind the scenes, and you have some strange situations where it doesn’t work as you’d necessarily expect (like when an method calls another method on the same object).

It seems to me that Ruby’s made it easy enough to modify behavior that nobody has needed to build out the machinery for “full” AOP.

Comment on Rails' Unusual Architecture by Ezra

Wed, 05 Sep 2007 15:43:33 -0600

alias_method_chain is evil. Not only does it make it very hard to extend a feature that has already been aliased but it just adds additional method call overhead(which is expensive in MRI) and it deepens the stack for no beneficial reason.

Down with alias_method_chain!

Comment on Rails' Unusual Architecture by charlie

Wed, 05 Sep 2007 17:15:20 -0600

Peter,

Here is the Decorator pattern.

I have to admit I don’t see much difference between the two patterns. Why do you think it is so much better?

Comment on Rails' Unusual Architecture by charlie

Wed, 05 Sep 2007 18:10:06 -0600

James - Its done by modifying Java byte code - see http://www.eclipse.org/aspectj/doc/released/progguide/implementation.html.

Alan - Thanks for the info about AOP and Java.

There has been some work on adding more AOP features to ruby - including an RCR, AspectR and Aquarium.

Comment on Rails' Unusual Architecture by charlie

Wed, 05 Sep 2007 18:11:52 -0600

Choonkeat - Nice link, thanks!

Comment on Rails' Unusual Architecture by Peter Williams

Wed, 05 Sep 2007 20:18:37 -0600

The main difference between the chain of responsibility and a decorator patterns are the end point.

In a pure chain of responsibility the first thing that was able to handle the request would do so and the rest of the chain would not be executed at all.

In a pipe and filter pattern, which is structurally very similar to a chain of responsibility, the entire chain would be execute with each step doing one thing and then passing the request/response on to the next filter. So the request starts at the first element of the chain, and ends at the last element. Control never returns to a step after it has been executed.

(req/resp) -> init_session -> controller_action -> (req/resp)

In a decorator pattern each step wraps the steps below it. So handling a request would start at the top decorator and it would finish when that method returned. The decorator pattern is a more direct match to the way alias_method_chain works in that you can do work before and/or after, or even modify the results of, the step below you.

Comment on Rails' Unusual Architecture by charlie

Wed, 05 Sep 2007 20:42:34 -0600

Hi Peter,

Ah. Just reread the Gang of Four:

The first object in the chain receives the request and either handles it or forwards it to the next candidate on the chain, which does likewise.

So yup, its the decorator pattern. Although Chain of Responsibility sounds so much better.

Comment on Rails' Unusual Architecture by Justin George

Thu, 06 Sep 2007 00:07:02 -0600

It’s funny you should reference design patterns with regard to ruby. There was an interesting article pointing out that most of them (iirc all but 3) were hacks to get around things that modern languages should have by default.

Ruby does, in fact, have those defaults (well, if you consider blocks and lambda to be fully first class functions), and thus talking about it is probably not the time to be citing GoF as gospel.

Comment on Rails' Unusual Architecture by Dean Wampler

Thu, 06 Sep 2007 08:00:10 -0600

Great post!

FWIW, Aquarium effectively uses the Decorator pattern to chain “advice” calls. There is a type of advice called “around” advice (in addition to the more intuitive “before” and “around” advice…), where you wrap a method call and you must explicitly invoke the wrapped method. If you don’t, then it behaves like Chain of Responsibility ;)

Aquarium doesn’t yet provide a way to insert advice between already chained advices, but the pieces are there already. Another thing you would like to do (which AspectJ provides) is the ability to prioritize execution of advices acting on the same method. For example, maybe authentication should always be first!

Comment on Rails' Unusual Architecture by Dean Wampler

Thu, 06 Sep 2007 08:38:19 -0600

Uh, I meant “before” and “after” advice…

Comment on Rails' Unusual Architecture by http://kurtstephens.com

Thu, 06 Sep 2007 09:14:00 -0600

This coding pattern is common in Rails and Ruby. This is a great way to package functionality into reusable units.

But, this is not AOP, Decorator or Chain of Responsibility.

It is an exercise in first-class modules and module delegation, which Ruby supports very well. It is a chain of methods packaged in modules, not objects collaborating; i.e. composition of class and module singletons, versus instantiated behavioral objects. The latter is far more flexible.

There are no Decorator objects being created. There is no Chain of Responding objects. It is not AOP because the advice is not specified orthogonally, outside the subject class.

The Ruby gem aquarium looks like a good AOP framework. Found it just after I wrote my own method advice package. :(

Trackback from anothr user: Anothr feed track -cfis on Rails' Unusual Architecture

Thu, 06 Sep 2007 10:35:09 -0600

One new subscriber from Anothr Alerts

Comment on Rails' Unusual Architecture by Rick

Thu, 06 Sep 2007 12:34:05 -0600

You mention that ruby has limited support for AOP, which is true, but you fail to mention that, generally, intended effect of AOP is to implement cross-cutting-concerns. In this capacity ruby is incredibly adept. It utilizes it’s trademark feature, the closure, to add functionality (such as logging, auth, even the decorator pattern) It accomplishes this in a much more elegant fashion than standard AOP practices, IMO. Interesting article by the way.

Comment on Rails' Unusual Architecture by charlie

Thu, 06 Sep 2007 12:53:00 -0600

Hi Justin,

Yes, its a bit of a meme that dynamic languages reduce the need for many design patterns. Do you have a link to that article?

However, that doesn’t mean that all design patterns are useless. And in this case particularly, they help understand some of the possible approaches to building a web framework. Using a more functional approach(blocks/lambda), like you mention, would also work. But I would guess it would end up fairly un-Ruby like. So if you’d prefer that approach its probably better to use a functional language.

Comment on Rails' Unusual Architecture by charlie

Thu, 06 Sep 2007 12:54:37 -0600

Hi Dean,

Thanks for the info on Aquarium. Do you use it often, and are you a developer on the project? Looks like a very interesting project, I’ll have to give it a try.

Comment on Rails' Unusual Architecture by charlie

Thu, 06 Sep 2007 13:05:27 -0600

Hi Kurt,

Great comments.

It is a chain of methods packaged in modules, not objects collaborating; i.e. composition of class and module singletons, versus instantiated behavioral objects. The latter is far more flexible.

Yes, that is an excellent way of putting it. I should added a paragraph explicitly calling out that difference.

There are no Decorator objects being created. There is no Chain of Responding objects.

Agreed. The effect is similar, the implementations are very different.

It is not AOP because the advice is not specified orthogonally, outside the subject class.

That is an interesting point. Including the modules into a base class is sort-of-kind-of outside the subject class. But of course you have to do it via class_eval.

Comment on Rails' Unusual Architecture by charlie

Thu, 06 Sep 2007 13:09:20 -0600

Hi Rick,

generally, [the] intended effect of AOP is to implement cross-cutting-concerns…It utilizes it’s trademark feature, the closure, to add functionality (such as logging, auth, even the decorator pattern)

Sort of. You still have to add in the code to hook in the functionality (such as Benchmark) versus AOP where that is done orthogonally (as emphasized by Kurt).

But I agree that Ruby does give you the tools to make that less painful than many other languages.

Comment on Rails' Unusual Architecture by Charlie Hubbard

Mon, 10 Sep 2007 08:43:52 -0600

Chain of Responsibility and Decorator are so similar they’re almost the same. Their difference only lies in the implementations not the architecture of the pattern. Decorators can behave like Chain of Responsibility (COR for short) because they can always choose not to forward a request onto it’s delegate.

In web frameworks sometimes you want to stop processing a request due to some condition. Consider, error handling, authentication, etc. In these cases your request is processed more like a COR rather than Decorator. A decorator pattern is equivalent to COR and vice a versa.

I have found it very difficult to figure out what’s actually happening in the Rails code by looking at the source. The use of adding dynamic methods is very hard to track down who’s calling whom. Being able to view the method decoration at runtime would be really cool. Maybe using something like this could help:

At runtime you could instantiate a controller object that acts like a camcorder, and at the end would print out all of the methods processed to HTML. Maybe turn it on with a ViewHelper: <%= request_method_chain %>.

Comment on Rails' Unusual Architecture by JB Brown

Mon, 10 Sep 2007 20:30:19 -0600

This seems more like a Pipeline/Pipes-and-Filters pattern than Decorator or CoR. You’ve expressed the consequences of the Pipeline/Pipes-and-Filters pattern in your post along with what I believe are misplaced frustrations about things you’d expect to be in a Decorator pattern implementation but aren’t.

An early post stated that pipleine doesn’t augment behavior before and after; but rather only before. I’d say this is a limited view of Pipes-and-Filters and that it really depends on the diretionallity of the intended Pipe; in, out, or in-and-out. Pipeline / Pipes-and-Filters can be for returning a response to a request just as well as it’s coloquial description of processing a request.

http://jb-brown.blogspot.com/2007/09/cage-match-decorator-pipeline-chain-of.html

Comment on Rails' Unusual Architecture by JB Brown

Tue, 11 Sep 2007 02:08:33 -0600

After further understanding the alias_method_chain implementation I agree that in OO patterns this is most acurately described as the Decorator pattern. I was misguided with my Pipeline view. I’ve updated my blog with the same.

Trackback from Quicklinks: links for 2007-09-11 on Rails' Unusual Architecture

Tue, 11 Sep 2007 05:17:15 -0600

Rails' Unusual Architecture (tags: programming rails)...

Trackback from Blog do Urubatan: Rapidinhas sobre Ruby e Rails on Rails' Unusual Architecture

Tue, 11 Sep 2007 10:38:44 -0600

Primeiro, eu realmente queria escrever algo sobre java agora, mas realmente não estou fazendo nada de interessante (pelo menos não que possa ser comentado sem que eu seja processado), e não vi nada de muito novo na web que valesse a pena um com...

Trackback from The Plan A: Dynamics finders in ActiveRecord using AOP. on Rails' Unusual Architecture

Mon, 24 Sep 2007 18:19:35 -0600

Yesterday, I have been playing with Aquarium, an AOP framework for ruby. I decided hack a little bit. I try to refactor the dynamics finders of ActiveRecord, using an AOP approach. First lets try to understand what are and how dynamics finders wor...

Comment on Rails' Unusual Architecture by Michael Schuerig

Fri, 01 Feb 2008 02:19:42 -0700

There is one very big advantage in the way Rails implements the decorator pattern: It keeps the sense of self intact. The classic GOF-decorator, implemented as one decorating object wrapped around another object, suffers from schizophrenia. When a decorated method is called from the outside, it goes through the decorator; when the same method is called from within the inner object, it goes straight to the original implementation, bypassing the decoration.

The Rails implementation, using method chaining, avoids splitting the meaning of self by keeping everything to a single object.

See my other, earlier musings on self-conscious decoration in Rails.

Comment on Rails' Unusual Architecture by Charlie

Sun, 03 Feb 2008 12:44:42 -0700

Hi Michael,

That is an interesting point that I hadn’t considered - and thanks for the link to your earlier blog post that I had missed when I orginally wrote this.

In the case of Rails, I’m not sure it matters since the method being decorated tends to be process. But I can see how it would be important in other cases.