Avoiding some of the negative trade-offs in the template pattern with ruby’s dynamicism?

So my buddy Tammer’s recent post about the Gang of Four’s Template Pattern reminded me of some code I saw recently. A start-up’s greenfield project had it’s authorization done in a pretty clean way using the template pattern. Basically every object determined what could be done to it, something like this:

After continuing this approach to fully cover CRUD you make a straight-forward set of accessors that can be used to easily enforce permissions in the controller in a programmatic way (this project was using on of the inherited resourceful-controller plugins, so that was a big plus). The developer who implemented this commented that the trade-off for this simplicity was having to look in each individual model file to figure out what a user can do overall. I figured I liked everything about this scheme except that trade-off, and since ruby is so dynamic, why settle for almost. Why not just reopen each class in the authorization file and add the methods. You still get the simplicity and encapsulation of having the model able to determine it’s own permissions, based on it’s state and methods, and there is still one place to look to review/change the permissions for the whole project:

Thoughts?

Posted via web from a timocracy of one | Comment »

Notes

  1. timocratic posted this