CODEWITHSUNDEEP
javaauthenticationroles
Alexss_1902
Alexss_1902

Reputation: 23

Java application with different type of users: should I use hierarchy?

I'm building a small application to learn Java that has different types of user. At first, I thought that It was a hierarchy, where user is the superclass and the other three (customer, admin and worker) subclasses. Also, this three user types have different methods and GUIs, but they all have user and password.

My problem is that I have a class called Application and the method login that returns an user object and I don't know how to see if this object is an admin, worker or customer without using instanceof. Also, all the methods are in each subclass because they don't have functionality in common, except the login (that is in another class), then if I have an object of type user I would need to cast it to another subclass, but, again, I don't want to use instanceof. Another idea that I had is to make all the methods in user class and an role enum that I would check to see If the user has permission. But, If I need to do an enum for this, I don't see the point in having subclasses.

Is there any solution to this?

Note: It's a small app, without databases or online connection, only a college project.

Upvotes: 2

Views: 636

Answers (1)

JayC667
JayC667

Reputation: 2588

From all my experience, it's quite a bad idea to have multiple classes for the User:

  1. Different instancing means different persistence (like loading from and saving to a database or file or stream).
  2. At one point or the other, some users will get other roles. Different classes will be worst to handle that transition.

Another point which has proven to make implementation harder: one enum reference for the current role. Although this is quite a good solution, think about special permissions and a mixture of roles (Set<MyRoleEnum> or Set<MyRoleClass>).

  • Here, the best approach is to be able to give the user multiple roles.
  • Roles can be enums or instances of a class, depending on how dynamic you wanna implement it.
    • Enums can (with introspection/reflection: SHOULD!!!) only be changed at compile time (means reprogram, recompile, redeploy, restart your app),
    • while you can create new instances of normal classes during runtime (though you then need to integrate some kind of administration and persistence too).
  • Remember to NOT save roles by their ordinal number! Changing the order of enums in their class will change their individual ordinal number!
    • It's better to save roles by a unique ID (like the name, provided names don't change)
  • And given the roles, you can either implement all the 'isResponsibleFor(item)' methods into your Session Manager, or into the User class, or into another class that focuses on role handling.

Facit:

  • This (user has a list/set of enum roles), so far, has proven the best, fail-safe (compile-time safe) model I have implemented up to date, for smaller projects.

    • The big Downside of using User.Set<MyRoleEnum> is that you have to recompile+redeploy the whole code for an additional role. But additional roles usually always come with new features, so the code would have to be re-compiled/deployed anyway...

  • If your project is meant to be used by thousands of users and an army of admins, go for the User.Set<MyRoleClass> implementation.

    • With that size, the project will probably have dynamic class loading, and extending enums and dynamic class loading do not mix well.
    • But this means a lot of additional work to put into instancing, persistence and administration of the MyRoleClass

Upvotes: 2

Related Questions