简化现场访问。 我应该使用反射还是Java 8解决方案？

Question

I've got the following example class:

public class MyPermission implements Permission {
    public static final String READ = "read";
    public static final String UPDATE = "update";
    public static final String DELETE = "delete";

    @Override
    public boolean isGranted(String permission) {
        switch(permission) {
        case READ: return read;
        case UPDATE: return update;
        case DELETE: return delete;
        default: return false;
        }
    }

    private boolean read;
    public boolean isRead() { return read; }
    public void setRead(boolean read) { this.read = read; }

    private boolean update;
    public boolean isUpdate() { return update; }
    public void setUpdate(boolean update) { this.update = update; }

    private boolean delete;
    public boolean isDelete() { return delete; }
    public void setDelete(boolean delete) { this.delete = delete; }
}

And I want to simplify things a bit, because there will be created much more of these classes. The schema is always the same:

• some public final static String Permissions (must be accessible inside Annotations)
• each of those Permissions has a corresponding boolean field
• method isGranted returns the value of the corresponding boolean field

As you can see in the example code: I've go to write a lot of code, to achieve this and I can't figure out how to simplify things.

There are 2 things I could imagine:

1. call super(READ, UPDATE, DELETE); inside the constructor and let the super class handle the isGranted(...) method via reflection.

2. just call super(); inside the constructor and the class will find the public static final String fields itself and create the fields and getter/setter dynamically, because I don't need them in my code - they just have to be there at runtime.

Or is there any cool new feature in Java 8, so I can do this:

public MyPermission() {
  super(new HashMap<String, GetterMethod>() {{
    put(READ, this::isRead);
    put(UPDATE, this::isUpdate);
    put(DELETE, this::isDelete);
  }});
}

So I could dynamically invoke the corresponding getter method, like:

public boolean isGranted(String permission) {
  return permissionMap.get(permission).execute();
}

(or even using the field, instead of the getter method)

It would be cool, if there's a simple and nice solution for this :)

Thanks in advance!

Answer 1

How about using Java 8 @FunctionalInterface Supplier and @FunctionalInterface Consumer ?

public abstract class Permission {
    Map<String, Supplier<Boolean>> permissionGetterMap = new HashMap<>();
    Map<String, Consumer<Boolean>> permissionSetterMap = new HashMap<>();

    public void put(String permission, Supplier<Boolean> getter, Consumer<Boolean> setter) {
        permissionGetterMap.put(permission, getter);
        permissionSetterMap.put(permission, setter);
    }

    public boolean isGranted(String permission) {
        return permissionGetterMap.get(permission).get();
    }

    public void setPermission(String permission, boolean granted) {
        permissionSetterMap.get(permission).accept(granted);
    }
}



public class MyPermission extends Permission {
    public static final String READ = "read";
    public static final String UPDATE = "update";
    public static final String DELETE = "delete";

    public MyPermission() {
        put(READ, this::isRead, this::setRead);
        put(UPDATE, this::isUpdate, this::setUpdate);
        put(DELETE, this::isDelete, this::setDelete);
    }

    private boolean read;
    public boolean isRead() { return read; }
    public void setRead(boolean read) { this.read = read; }

    private boolean update;
    public boolean isUpdate() { return update; }
    public void setUpdate(boolean update) { this.update = update; }

    private boolean delete;
    public boolean isDelete() { return delete; }
    public void setDelete(boolean delete) { this.delete = delete; }
}

This does at least save some code, but:

1. it's not much shorter than the version above, and
2. those 2 Map s will generate some overhead. (could be important, since those Permission objects will get created about 100-1000 times per second when the application is live)

Answer 2

I'd leave Java8 alone and just head for design patterns, strategy to be exact.

Either you can derive a subclass per each case or you can introduce an enum. Both are type safe, testable and you're not building another String centric application.

So you either end up with classes like

WritePermission extends BasePermission...
ReadPermission extends BasePermission...
BasePermission implements Permission...

Or with something like

public enum Permissions implements Permission {
  WRITE {public boolean isWrite{return true;}},
  READ {...}, 
  ...
  public boolean isWrite{return false;}
}

Or while you're with enums, you could resign from boolean methods at all, as you can just start comparing persmissions with enum (but that does not scale well, if you're going to do a hierarchies of permissions (eg ReadWrite). In that case classes are better