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.

  • 1
    It is called the composite pattern and you address your problem by making the Add method in the base class protected and "surfacing" it only in the classes that need to be able to have stuff added to them. Jul 18, 2013 at 6:43
  • composite sounds reasonable here. can a user belong to more than one group?
    – Ray Tayek
    Jul 18, 2013 at 7:23
  • @MarjanVenema: "Composite" is only the right thing if groups can contain other groups as well. As I wrote in my answer, this pattern is related, but I suspect it will be overengieneering here.
    – Doc Brown
    Jul 18, 2013 at 13:49
  • Wow how could I not think about Composite ! Thanks ! Indeed it might be overengineering but I think it might be ok in this case since this is for a software engineering class. Also yes there is the possibility of having groups of groups (not in the case of users but in the case of components).
    – ApplePie
    Jul 18, 2013 at 16:00
  • Why the downvote ?
    – ApplePie
    Jul 18, 2013 at 16:43

2 Answers 2


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.


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.

  • I don't understand why you think the SRP is violated in the original design. "GroupManager" seems to be responsible for groups, and "UserManager" for users.
    – Doc Brown
    Jul 18, 2013 at 15:55
  • Indeed.. I misinterpreted that as being one manager. While the SRP bullet holds as it is it may not be applicable directly to the question though.
    – Frank
    Jul 18, 2013 at 17:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.