Design Pattern for restricting access to methods in Java

Sabyasachi Mukherjee

I have an User class like this:

public class User
{
    public double userId;
    public Role userRole;
    ....
}

Role is an enum like this:

enum Role
{
    ADMIN,
    REGISTERED,
    UNREGISTERED 
}

I have a class called UserActions, which is like this:

public class UserActions
{
    private User user;
    
    public UserActions(User user){ this.user = user; }

    public void Create(){...}
    public void Read(){...}
    public void Update(){...}
    public void Delete(){...}
}

Now, obviously, whether an user is able to use Create, Read, Update or Delete depends on their role. The naive way to do this is to use Guard clauses in all the methods based on user.role, but that is definitely not elegant, and it pollutes the business logic.

What I want to do is something like this:

public class UserActions
{

   private User user;
   public UserActions(User user){ this.user = user; }
   
   public ArrayList<Lambdas> allowedActions() { return a list of allowed actions for the user which they can then invoke}

   private void Create(){...}
   private void Read(){...}
   private void Update(){...}
   private void Delete(){...}
    
}

Is there a way to return an array of methods the user can call based on their roles in Java?

oleg.cherednik

Look at following approach. I think you're almost there for the solution, just use Function instead of inline methods. I think it should work.

class UserActions {

    private final Function<Context, Result> create = context -> Result.NULL;
    private final Function<Context, Result> read = context -> Result.NULL;
    private final Function<Context, Result> update = context -> Result.NULL;
    private final Function<Context, Result> delete = context -> Result.NULL;

    private User user;

    public UserActions(User user) {
        this.user = user;
    }

    public List<Function<Context, Result>> allowedActions() {
        // TODO read credentials and provided allowed actions here
        return List.of(create, read, update, delete);
    }

    public static final class Context {
        // TODO add action's input data here
    }

    public static final class Result {

        public static final Result NULL = new Result();
        // TODO read action's result here
    }

}

I think that client should identify different methods, then instead of List you can provide a Map with unique key for each action, e.g. CREATE, READ, UPDATE and DELETE.

Collected from the Internet

Please contact [email protected] to delete if infringement.

edited at
0

Comments

0 comments
Login to comment

Related

From Java

Decorator design pattern java overriding methods question

From Java

Java: Strategy pattern with access to superclass' fields and methods?

From Java

Java design pattern for two classes sharing identical and similar but different methods

From Dev

Java Class variables are not immutable despite restricting access

From Java

Transition methods in state design pattern

From Dev

C#, ASP.NET - Restricting Access to Controller Methods

From Java

RAII design pattern in Java

From Dev

Name of java design pattern

From Dev

Inheritance in Java (design pattern)

From Dev

Factory Design Pattern - defining methods in subclasses

From Java

Design pattern for logging entry and exit of methods?

From Dev

Which design pattern to use (Active and passive methods)?

From Dev

Best Design Pattern for Large Data processing methods

From Dev

Is there any Design Pattern for calling object methods statically

From Java

Design Pattern for Data Structure with Methods to Populate It?

From Dev

OO design pattern: How to add methods dynamically?

From Dev

Design pattern with methods that return modified parent

From Dev

Delegation design pattern with abstract methods in python

From Dev

Design pattern for class with more than one methods

From Dev

design pattern: how to add optional params for methods?

From Dev

How to deal with additional methods in MVC design pattern

From Dev

Restricting Access to Edit in SugarCRM

From Dev

restricting EKS user access

From

Restricting access to CloudFront by IP

From Dev

Restricting access to Index with cancan

From Dev

Restricting Access to local PouchDB

From Dev

Restricting Hard Drive access

From Mysql

Restricting ticket access to user

From Dev

Restricting user access on sorcery

Related Related

  1. 1

    Decorator design pattern java overriding methods question

  2. 2

    Java: Strategy pattern with access to superclass' fields and methods?

  3. 3

    Java design pattern for two classes sharing identical and similar but different methods

  4. 4

    Java Class variables are not immutable despite restricting access

  5. 5

    Transition methods in state design pattern

  6. 6

    C#, ASP.NET - Restricting Access to Controller Methods

  7. 7

    RAII design pattern in Java

  8. 8

    Name of java design pattern

  9. 9

    Inheritance in Java (design pattern)

  10. 10

    Factory Design Pattern - defining methods in subclasses

  11. 11

    Design pattern for logging entry and exit of methods?

  12. 12

    Which design pattern to use (Active and passive methods)?

  13. 13

    Best Design Pattern for Large Data processing methods

  14. 14

    Is there any Design Pattern for calling object methods statically

  15. 15

    Design Pattern for Data Structure with Methods to Populate It?

  16. 16

    OO design pattern: How to add methods dynamically?

  17. 17

    Design pattern with methods that return modified parent

  18. 18

    Delegation design pattern with abstract methods in python

  19. 19

    Design pattern for class with more than one methods

  20. 20

    design pattern: how to add optional params for methods?

  21. 21

    How to deal with additional methods in MVC design pattern

  22. 22

    Restricting Access to Edit in SugarCRM

  23. 23

    restricting EKS user access

  24. 24

    Restricting access to CloudFront by IP

  25. 25

    Restricting access to Index with cancan

  26. 26

    Restricting Access to local PouchDB

  27. 27

    Restricting Hard Drive access

  28. 28

    Restricting ticket access to user

  29. 29

    Restricting user access on sorcery

HotTag

Archive