Nothing wrong with a lot of classes with only a few polymorphic messages. Many of the design patterns leverage this.
I would get the behavior over to the instances. So your examples would look like: anAction requires: Modifypermission new and aUser hasPrivilege: AdminRole new If you are worried about creating too many Role or Permission objects and then simply throwing them away, you can share them. Note that this qualifies as an optimization. You should really only optimize after you've proven that you need to optimize. The Singleton design pattern is the best known sharable but you could also use a pool dictionary or some other well known object. I avoid class side behavior like the plague. Instances for objects, classes for making objects. Exceptions rare! On 6/26/07, Norbert Hartl <[EMAIL PROTECTED]> wrote:
Hi, I'm thinking right now about some role and permission stuff for my webapp. But I'm asking myself what will be a good approach for this. At first I created a lot of classes like AdminRole, MemberRole, CreatePermission, ModifyPermission etc. I used the class objects for this. These only carry some state like index, label. The role objects also carry a set of permissions. But at the moment I doubt this is a good approach. I'll end up with a lot of classes that have only two mehods. And second (I dislike most) is to use class side initialization for populating the objects at first. The good thing about it is that I'm able to use something like anAction requires: Modifypermission and aUser hasPrivilege: AdminRole What would be a usual approach to solve something like this?? thanks in advance, Norbert _______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
_______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners