1

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.

  • If the classes are typically in different problem domains, and they rarely have a lot of crossover, it may be fine to simply have them be the same name. In the cases where the classes don't intersect, the name isn't superfluous, but in places where they may overlap, you can alias them in the class to make their usage more clear. – JD Davis Jul 10 at 4:09
  • 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 sounds like a Reporter to me. User who are both using the app and also subscribers of the services being analyzed it sounds like a Customer or Consumer to me. The concept User is vague and utterly ambiguous. Between the actor and the application, there're subtle but numerous abstractions you could use to name things. Usually, a name after the main action or the main interaction between actor and system should help – Laiv Jul 10 at 7:34
  • To me, "User" sounds like UX; a la "make this button bigger so the user sees it better". Your "users" can be defined by what they are doing, e.g. administrator, manager, analyst; possibly more specific like "SalesManager". On the other end, customer, client, subscriber... and in edge cases where all those are already taken (e.g. "client" could be a server client) you can use buyer or purchaser. Sounds a bit awkward, but it's more important that it's clear what it means. PS IMHO, a thesaurus is the most underrated programming tool. – R. Schmitz Jul 10 at 10:17
1

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.

2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.