Design a model for a user

Question

There has been a change in the project I am working on. Until today, there was only one type of user in the system. From the moment you logged in, you had all the information about the user.

The new change we need to make is to support several types of users. Some types of users have information about them, and some don't. And there is a type of user that sometimes has information about him and sometimes doesn't. Also, each user can have different access (read/write) And additional permissions to see certain screens or not.

For example:

Member: is a user with all kind of information and have a full access

Associate Parent: is a user with minimal information and cannot access certain screens.

Former member (with kids): is a user with all kinds of information but cannot access certain screens.

Former member (without kids): is a user with all kinds of information but fully blocked

And there are 3 more types with similar combinations.

My question is:

One possible solution is to split each type of user into a different class Maybe with similar properties or conforming to an identical interface. But by the end, all the types are conforming to the User interface which is a very basic and generic protocol with very few properties.

Pros:

• The client only gets the properties that the type has and doesn't need to check for the type before accessing it.
• There is a separation between each type, and changes of a type will be easier to make in the future.
• As a client, I can demand a specific type to instantiate a module with, or block a screen for a specific type of user.

Cons:

• There are many classes and duplicated properties.
• It adds complexity on the client side.

Another solution can be to use only one class of User The user will contain a property representing the type. And the user may or may contain one single property that represents all the information about him.

Pros:

• There is only a single class to use.
• There are fewer files and complexity. Cons:
• There is no separation between the user's objects.
• The clients can access properties that the user does not have.

I would like to get your opinions about both approaches, which is preferred, and if there is another recommended solution I would like to know.

Answer 1

It is a little difficult to understand if you are talking about database table modelling or class design. These are related topics, but I will focus on database design.

The use case you may have ignored is "what happens when a user changes role?". A simple example is a Member becomes Former Member. Obviously you will want to retain history and not create a new User, as that would lose their earlier activity.

From the database perspective, I recommend:

1. Create a User table that contains only information pertinent to the user - e.g UserId, name, contact details, password hash.
2. Create a Role table. This will have only a dozen or so records (e.g Member, Former Member, Associated Parent... This table will likely have boolean fields that control access to various screens.
3. Decide whether you need to keep history of role allocation. For instance do you need to handle queries like "all Admin users during 2016 that approved a payment of $100 or more", or can you get away with the simpler design that says "user fred currently has the Admin role". If you keep history, you need a UserRole table that contains foreign keys to the User and Role tables, plus start and end time fields. Otherwise a simple foreign key from User to Role table will suffice.

Finally, spend a good amount of time on data modelling. Talk to as many subject matter experts as you can find. Fixes during the modelling phase are generally easy. Work hard on making your database design reflect the way you do business. Fixes later become difficult and lead you into "technical debt" programing that wastes time and drives you slightly crazy.