If the concept of these particular roles is required in the domain model, and is actively used by code (such as the client of User which is invoking administrator?), then I feel they should be represented directly in the code, possibly as an enumeration (and then these convenience methods could be defined by iterating over the enumeration). Of course this then begs the question of why Roles, now of fixed values from an enumeration, would be in the database at all.

If, on the other hand, they are in the database because they are configurable, then it is probably better to not have these convenience methods at all - but rather to provide a single is? or inRole? method that takes a Role object (not a role name). The client that does care about particular Roles, like administrator, can then obtain the Role object it wants, and then invoke the is? method with that role. This allows the failure to find a particular role in the data to be indicated at precisely the point where the code is dependant on that role existing.

I have recently been looking through a lot of code, all which can be ‘figured out’. I keep on thinking that it would be so nice if for each class there was some sort of human readable description that told me in general terms what the class does. Ah-HA! Documentation!!

If you were to provide a one or two sentence description of what the clever code does in human readable terms, then you have gained both cleverness and readability.

One thing I would be worried about with the above code is name collisions. For example, what if you add a role called foo and then a method called “foo?”. you might run into some strange errors that are difficult to debug. Maybe make the auto_generated methods like user.role_customer? to avoid that?

The area where I get really worried about having to much magic in the code is when you have some random code off in some other file that adds methods to a class.