naming the classes for users of my app, and users who manage the app

Question

Naming things is hard but naming them properly is really hard. We are working on an app, that analyzes the data of multiple apps and creates some reports.

And we are hitting our heads against walls with the infamous User class problem.

We have used User class in different parts of the app to mean totally different people. In some cases it refers to the User who is currently logged in to our app to make a report or read a report.

In other parts another User class exists that represents the user who actually signed up to use a service and our app is generating a report of that user's shopping history.

Yet there are another representations of the user who are both using the app and also subscribers of the services being analyzed.

A complete mess.

Right now we are going though a refactoring phase and we are considering to completely eliminate and ban the generic name user throughout our app.

Here are some thoughts on renaming the user classes.

AppUser [this name still sounds weird though] A user who is using the app after logging in to view or make reports. [DomainUser, OfficeUser or StaffUser as alternates]

CustomerUser a user who actually bought something and we want to make a report for her history. [can it be called a ClientUser , SubscriberUser or a ServiceUser]

Rather than getting name suggestions only (which is definitely welcome) I am more interested in getting an insight on the techniques to handle this kind of situations in development.

Answer 1

The problem is that a User is by definition Someone which uses a very broad and generic terminology.

So I would ask, what are these Users actually?

In some cases it refers to the User who is currently logged in to our app to make a report or read a report.

This would be what classically a User is considered to be. So keeping them as User kinda makes sense. There are better justifications, I point one out below.

In other parts another User class exists that represents the user who actually signed up to use a service and our app is generating a report of that user's shopping history.

Hmm... There is a give-away in your sentence. Let me zoom in on it...

that user's shopping history.

Wow, so these aren't just any old Users they are more specifically Shoppers.

Unless you have an overwhelming reason to not refer to them as Shoppers, I would call them just that.

---

The technique is a simple one, or at least it sounds simple - Its very difficult to do right when you are 5cm away from the problem.

1. Get say 5 people to write a paragraph about what the Object is. When it is used, and for what purpose.
2. Look for words that stick to that purpose.

What you will find is that someone writing about a User of your own application, will tend to refer to them as Users, because there really isn't a tighter term that fits them broadly across your application.

ie. A user reports from our system about shopping behaviours, and must administer a list of those services, and verify histories.

You could argue that Administrator is a better fit here. It certainly would work if you substituted it in for user. But you probably already have some form of Administrator in your system, even if its not an explicitly named class, and we are trying to avoid name clashes.

Similarly for the second type of User you might describe it alternately as:

ie. A user is the person who signs up to a service, and buys stuff through that service. We report on their shopping behaviour.

In this sense a Shopper can be substituted in for User without disrupting the meaning.

eg. A shopper is the person who signs up to a service, and buys stuff through that service. We report on their shopping behaviour.

Yep, that fits. You could also say Buyer, ServiceUser, or even Servicee. But I think Shopper fits better.

Answer 2

It is often helpful to have User and Role as separate concepts. The User class contains identity and authentication information (username, password, real-life identity, e-mail), and the Role class which might have concrete subclasses such as Buyer, Admin, etc. contains information about the interaction of the user with the application, such as purchase history or areas of administrative authority. Users can have multiple Roles although there might be conflicts of interest which you need to handle.