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 <
[hidden email]> 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
>
[hidden email]
>
http://lists.squeakfoundation.org/mailman/listinfo/beginners>
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Locked
