Naming Things

Naming a class UserManager creates a problem.

The name is vague enough to justify anything. Password hashing? Sure, users need passwords. Email preferences? Sure, users have email. Session tracking? Rate limiting? Profile photos? They all go in UserManager.

// The Dumping Ground
class UserManager {
  hashPassword() { ... }
  sendEmail() { ... }
  saveProfile() { ... }
  checkRateLimit() { ... }
}

The class grows. A hundred lines. A thousand. It becomes a God Object—the dumping ground for anything vaguely user-related. The vague name didn't just allow this to happen. It invited it.

The fix is specificity. UserManager could mean anything. PasswordHasher can only mean one thing. And a precise name creates a natural test for every new method: does this belong here? You can't talk yourself into adding rate limiting to PasswordHasher. The name won't allow it.

When you can't describe a class in a clear, specific name, you probably haven't found the right boundary yet. A name that's too broad isn't a naming problem—it's a design problem. The answer isn't a shorter word. It's better boundaries.