OOP way to design a manager of groups of users

Question

Alright. I have this pattern to model that comes in two variations that are very much the same. I have a class which can be considered an "entry point" which will call a few manager classes depending on the user interaction. We can probably liken it to a controller class.

This class should allow the user to manage either groups of users or users themselves. In both cases the operations are quite similar, you can add, modify, remove, view groups and users. Groups have one more operation which is to add users inside them. That's where I am stuck on:

My original idea was to model it this way:

1. class User,
2. class Group,
3. class GroupManager,
4. class UserManager,
5. class IManager

However this has the problem of not being able to model the fact that groups need to be able to add users to them. If I put it inside IManager then it is available to UserManager which makes no sense and I put it as a specific method of GroupManager then I am cannot have a single "interface" which is less clean. That led me to skipping entirely the IManager class altogether and only have both managers but then it seems clunky and repetitive.

Is there a proper design pattern to apply here ?

TLDR: What is the proper design pattern where all methods to manage a group or user should have the feel of a "common interface" but still be able to model the fact that groups should be able to add users to themselves.

Answer 1

Putting a method like AddUserinto the IManager class is not really a problem as long as the implementation of that method in UserManager just throws an exception (or does some other kind of error signaling.

But if groups and users are very similar from the "managers" point of view, why not introduce a common base class for Group and User (lets say IGroup, since a user can be seen as a group of just one person), and replace the two different manager classes by a single one which operates on IGroup objects in a more or less generic manner? Of course, IGroup will need an AddUser method, too, and the implementation in User should throw an exception (like in my suggestion above).

I also agree with @Frank that the name XXXManager may be chosen better, but I guess in reality you have a more expressive name and you chose that here just because of keeping your question general.

Also related (but maybe oversized for your case, when you don't have "groups of groups":) the composite pattern.

Answer 2

This seems to be a problematic design for a few reasons:

• FooManager is often a bad idea. See this question about how it may be a sign of bad design. After all, a UserManager is a class that does something with User objects.. but what exactly means managing here?
• Single reponsibility principle - The S in SOLID is something you violate with anything that manages a group or user. By the very nature of doing this or that your component/manager no longer has a single responsibility, but at least two of them.
• You already said that "Groups have one or more operation[sic.] which is to add users inside them", so you have a very natural understanding that these operations/methods belong to the Group class. You should first provide an argument of why this simple straightforward approach is not feasible in your case, before you start complicating your design.

What is the reason behind your idea that methods, which do two different things, should have a "common interface" anyways? Apart from their nature being very intuitive and everyone understanding that you can add a user to a group, everything else you design on top of that is something others will not as readily understand. So why even bother?

Finally, if you really really need to define that common interface you may take a look at the Facade pattern. It's intended for larger bodies of code (like whole packages) and again looks like overkill for a User and a Group class.