Django中UserManager为何同时存在create_user与_create_user方法？

Great question! Let's break down why Django splits this user creation logic into two distinct methods instead of cramming everything into one function like the example you shared:

First, here's the single-method implementation you referenced for context:

def create_user(self, username, email=None, password=None, **extra_fields):
    """ Creates and saves a User with the given username, email and password. """
    now = timezone.now()
    if not username:
        raise ValueError('The given username must be set')
    email = self.normalize_email(email)
    user = self.model(username=username, email=email, is_staff=False, is_active=True, is_superuser=False, date_joined=now, **extra_fields)
    user.set_password(password)
    user.save(using=self._db)
    return user

Now, here's why the two-method approach is better:

• Single Responsibility Principle:
  create_user handles all the public-facing, user-centric work: validating required fields (like checking the username exists), normalizing input (cleaning up the email format), and setting sensible default values (like is_staff=False or date_joined=timezone.now()). Meanwhile, _create_user focuses solely on the core, repeatable mechanics of creating and saving the user to the database. Separating these keeps each method focused, easier to read, and simpler to debug.

• Reuse Across Multiple Public Methods:
  Django also provides the create_superuser method for admin accounts. Instead of duplicating all the user creation code here, create_superuser just calls _create_user with modified parameters (is_staff=True, is_superuser=True). With a single create_user method, we'd either have to repeat code or clutter the function with messy conditional logic for superusers—neither is a clean solution.

• Encapsulate Internal Implementation Details:
  The underscore prefix on _create_user marks it as an internal, private method. This lets Django's maintainers tweak the underlying creation logic (like adjusting how the user is saved, or adding new internal checks) without breaking the public API. External code that relies on create_user won't need to change even if _create_user is updated.

• Flexibility for Customization:
  When building custom user models and managers, splitting the methods gives developers more control. You can override create_user to adjust validation or default values for your specific use case, while still reusing _create_user's core save logic. Or, if you need to change how users are persisted to the database, you can override _create_user without touching the public-facing create_user interface.

内容的提问来源于stack exchange，提问作者Sahand