Design pattern for a class that works on a collection of other objects?

Question

I have a User model that can hold 1-n UserGroup models, each of which holds data about the user's relationship with a specific group (for example, if they're the admin of the group, when they joined the group, etc.).

I'd like to provide some helper methods like isGroupUser() and isGroupAdmin() that work on the entire set of UserGroup models stored in a User model. Right now these methods are in the User model, but they just about double the size of the model.

Does it make sense to push the code that works on the UserGroup models into its own class? So then the User model would contain a single instance of this "interface" class, which would also now contain the UserGroup models to work on. I feel like this keeps related code nicely separated and the User model from becoming overwhelming.

Also, is there a design pattern for this sort of thing? It seems like a class that works on a collection of other objects would be pretty common.

Thanks for your insight!

Answer 1

Iterator: Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. [GoF, p257]

Visitor: Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates. [GoF, p331]

If you are new to design patterns a quick overview is available at http://www.vincehuston.org/dp/

Answer 2

I suppose the other big benefit of doing it that way pushes all of this UserAccessControl or UserPermissions into a nice reusable setting or object.