Design template for multiple combinations of a multiset (user roles)

advertisements

I am facing trouble in deciding on better design pattern for the following usecase.

There are two modules in our project,

Moduel1,Moduel2

For a user to access each module, there are two sets of four entitlements ,one set for Module 1 & other for Module2.

Now, Depending on the correct combination of the user role ,i need to perform the logic specific to each module.

I have four user roles for module 1,

Module1UserRole1 ,Module1UserRole2 ,Module1UserRole3 ,Module1UserRole4

Different combinations for this is 15.

For each of this combination i need to perform relevant logic. Each logic is completely different from one another.

I am indecisive whether it is a good approach to put each combination logic in a separate class which gives readability instead of cramming up one single class with tons of if and else conditions.

This gives me total 15 classes. (each class represents one combination of userrole)

Each of these classes will implement following interface viz. Module1UserRoles .

Given the above scenario ,

  1. Define Module1UserRoles interface
  2. pubic interface Module1UserRoles { executeModule1Logic(); }

Lets say i am entitled to Module1UserRole1 && Module1UserRole2

Then the logic for the union of the above two roles will be written in Moudle1UserRole1AndUserRole2Impl .

public class Moudle1UserRole1AndUserRole2Impl Module1UserRoles {
       public void executeModule1Logic() {
///         implement the logic relevant userrole1 and userrole2.
}
}

I am looking at various options. Any advice is highly appreciated.


I would suggest you to go the way with 15 classes, as these classes are containing different code, not related to each other (as far as I understood). You will have 15 classes, implementing a common interface. The common interface should define all the methods, that the RoleLogic classes should implement.

Use a Factory-Pattern to determine the correct RoleLogic class to use. The return type of the factory will be the interface.

In your business logic, you can either use the RoleLogic as regular object and access it, or, if you already have a class for handling role dependend operations and you want to keep the signature of that class, use the RoleLogic Class als delegate.