I have a design problem related to a public interface, the names of methods, and the understanding of my API and code.

I have two classes like this:

class A:
    function collision(self):


class B:
    function _collision(self, another_object, l, r, t, b):

The first class has one public method named collision, and the second has one private method called _collision. The two methods differs in argument type and number.

As an example let's say that _collision checks if the object is colliding with another object with certain conditions l, r, t, b (collide on the left side, right side, etc) and returns true or false. The public collision method, on the other hand, resolves all the collisions of the object with other objects.

The two methods have the same name because I think it's better to avoid overloading the design with different names for methods that do almost the same thing, but in distinct contexts and classes.

Is this clear enough to the reader or I should change the method's name?

  • If the real method names are 'm' and '_m' then yes, you should change them. Otherwise, giving a sensible answer without the real names of the classes or methods is not really useful.
    – RJ Lohan
    Oct 22, 2013 at 20:34
  • @RJLohan Thanks for the advice! I edit the question.
    – Super User
    Oct 22, 2013 at 20:42
  • If you want to avoid confusion, why not just name them Acollision and _Bcollision, or something similar?
    – Brian Snow
    Oct 22, 2013 at 20:52
  • 1
    @BrianSnow I think is not really necessary because one of the methods is private.
    – Super User
    Oct 22, 2013 at 20:59

3 Answers 3


These functions both have to do with collisions, but what they do is very different, so giving them names that more clearly describe what they actually do will make it easier for future developers to understand the difference without having to look at the logic inside.

The method that checks if the object is colliding with another object could be called checkForCollision.

The method that resolves collisions of the object with other objects could be called resolveCollisions or handleCollisions.

When two functions do almost the same thing is often the best time to give them more specific names to make their difference clear.


I'd say that there is nothing wrong with this. Method overloading is a pretty standard practice, for multiple reasons. If you have the same exact functionality, just for two different series of parameters, then using the same exact name makes perfect sense, and it also helps to clarify that the parameter list should be roughly the only real difference between the two functions. It really does make it easier to code in languages that support it.

As for having those two functions do two slightly different things (A.collision() being more general than B._collision()), in this case, it is fine for two reasons:

  1. They're not really overloaded. "collision" <> "_collision" (unless Python's doing something here I'm unaware of).

  2. They're not really overloaded. class A <> class B. Even if they did have the same basic name, other programmers should be able to distinguish between functions in two different classes fairly easily (unless one is subclassing other). Different classes obviously tend to do things differently.


In layman's words:

  1. Method names should be verbs, so both names are inadequate.
  2. When you give them appropiate names ( with a verb ), it's unlikely the two method's names will coincide.
  3. Even if the two methods had the same name, they are in different classes, and there's no way of confusing them because of their having different namespaces.
  4. There's no style (or otherwise) rules stating that two distinct classes or interfaces cannot have methods with the same name, even if they have the same signature (parameter list).

For example

// there's absolutely no problem with this totally unrelated (or related) classes:

Short answer: there's nothing wrong with it.

  • @Casey Typo fixed Oct 28, 2013 at 18:26
  • 1
    If you're writing pure functions, (and there's increasingly more reason to do so) there's no functional difference between functions and values. Subsequently, there's increasingly less reason to force method names into verbs. Oct 28, 2013 at 19:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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