-3

In my project, I found one of the project's classes reusing the same name as an official one.

For example:

from django.db import models


class Model(models.Model):
    class Meta:
        abstract = True

    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

I had learnt from the senior and my experiences that I should use AbstractTimestamp because:

  1. Less hassle since the name is clear and reflects what that class is doing
  2. Auto-complete will be pop-up with single choice to choose
  3. When we talk to people in the project we don't need to mention about header
  4. Less bug in the header part

Given that:

  1. Why do people keep reusing superclass names in their subclasses?
  2. Are there any benefits from this?
  • 1
    What do you mean by "header"? – jonrsharpe Aug 20 at 9:09
5

Generally there are two schools of thought on this:

  1. Multiple types with the same name are fine if the name makes sense for them all. Differentiate them via a package/namespace/module etc name.
  2. Avoid multiple types with the same name as one then has to reply on the package/namespace/module etc name to differentiate them, which can be confusing.

As a general rule, neither of these is "correct" and neither is "wrong". It depends on circumstance. If I provide a library with different implementations of a model, I might choose to call them both Model, clarifying their difference via different module names, eg myLib.mutable.modelProvider and myLib.immutable.modelProvider.

However, what I'd regard as a serious code smell would be to have a base class, Model and to then add loads of extra features to it via a child class and to still call the latter, Model too. That's just laziness. You've added to Model, so give it a name that describes those additions.

And this seems to be what you are describing:

class Model(models.Model):
  class Meta:
    abstract = True

  created_at = models.DateTimeField(auto_now_add=True)
  updated_at = models.DateTimeField(auto_now=True)

is extending Model with timestamps. So call it something like TimestampedModel. This avoids confusion over the name and provides a description of the additions.

I've never come across someone reusing the superclass name in their subclasses in this way before. The only benefit I can see to this is it saves putting any effort into coming up with a new name. Sure, naming is hard; but "it's hard" is not an excuse for being lazy.

  • I typically use BaseModel for situations like this. Yes, you can make the argument that you can always clarify with a package/module, but that becomes problematic as soon as you do something like from myproject.models import Model. Someone who is reading through the code later on shouldn't have to rely on reading the import statements to resolve ambiguities. – Jesse Aug 20 at 14:49

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.