Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
class Boxer:

    def punch(self, punching_bag, strength):

class PunchingBag:

    def punch(self, strength):
        print "Punching bag punched with strength", strength

boxer = Boxer()
punching_bag = PunchingBag()

boxer.punch(punching_bag, 2)

No doubts that punch is a good method name in case of a boxer. But is name punch also good for the method of punching bag? In both cases I mean punch as a command (i.e. do punch).

share|improve this question

7 Answers 7

up vote 11 down vote accepted

A good rule of thumb is that method names should be verbs or predicates such that the object you call them on (self in standard Python convention, this in most other languages) becomes the subject.

By this rule, file.close is kind of wrong, unless you go with the mental model that the file closes itself, or that the file object doesn't represent the file itself, but rather a file handle or some sort of proxy object.

A punching bag never punches itself though, so punchingBag.punch() is wrong either way. be_punched() is technically correct, but ugly. receive_punch() might work, or handle_punch(). Another approach, quite popular in JavaScript, is to treat such method calls as events, and the convention there is to go with the event name, prefixed with 'on', so that would be on_punched() or on_hit(). Alternatively, you could adopt the convention that past participles indicate passive voice, and by that convention, the method name would be just punched().

Another aspect to consider is whether the punching bag actually knows what hit it: does it make a difference whether you punch it, beat it with a stick, or run into it with a truck? If so, what is the difference? Can you boil the difference down to an argument, or do you need different methods for different kinds of received punishment? A single method with a generic parameter is probably the most elegant solution, because it keeps the degree coupling low, and such a method shouldn't be called punched() or handle_punch(), but rather something more generic like receive_hit(). With such a method in place, you can implement all sorts of actors that can hit punching bags, without changing the punching bag itself.

share|improve this answer
@Artur: yes and no. Files can (conceptually speaking) close themselves when asked; arrays can sort themselves; but punching bags do not punch themselves. –  tdammers May 4 '13 at 9:05
Okay, if our punching bag hits the wall at insane speed, is it the wall that punched it, or was it punching bag experiencing hit on itself and by actually itself? –  user79302 May 4 '13 at 9:16
@tdammers: Your suggestion to generalize could also lead to an interface called Hitable. –  Jens Piegsa May 4 '13 at 9:48
@Artur: I think this is where the OOP assumption that every sentence has a natural subject, and that this idea is applicable to programming, breaks down. –  tdammers May 4 '13 at 9:48
So the main question is. If files can close themselves, arrays can sort themselves, etc., why punching bags cannot punch themselves? Is there any real difference or is it just that in the first case, we are used to it and in the second, we are not? –  clime May 4 '13 at 11:02

I think it is a conceptual issue (how we think about the world). It's alright to say:

  • Look, the door is closing. door.close()
  • Wow, the paper is folding on its own. paper.fold()
  • What the hell?! That file on the desk has just closed, nobody being around. file.close()

It is weird to say:

  • That punching bag in the gym has just punched itself. bag.punch()

It would need to have something to punch itself with in the first place (e.g. arms). You would probably say:

  • The punching bag has started moving on its own like somebody would have punched it. punching_bag.move()

It's alright for programmatic objects to do things that normally others do to/with them (in the "real world"). But I guess it should always make at least some sense that the thing is doing it to/with itself. You should be able to imagine it easily without getting obscure (as in case of the punching_bag).

share|improve this answer

It is matter of taste, I think. Punching bag's punch() method is at least consistent with file.close() or frame.move() in sense of experiencing action on itself. Greater question would be, why Boxer does have punch(something) method at all?

share|improve this answer
I like your point about file.close(). That was something I was getting at. Maybe boxer has punch method because there is also a coach training the boxer. Well, in fact, I was just trying to give some example of an action (message) being passed through several objects with the last one being "object of an action". I have slight problem with list.append(4), account.deposit(50), file.close(), paper.fold() vs. boxer.punch(), dog.bark(), logger.log() etc. –  clime May 4 '13 at 0:45
When passing through several objects, there are 2 cases: you use bound context (self), and you don't. If you do, your methods should be Coach.sayPunchToBoxer(), Boxer.punchNearestBag() and Bag.punch(). Otherwise you have to guess what will happen every time you call Coach.punch(). General rule is: if object that experiences action is not specified in method name, then receiver is that object. –  user79302 May 4 '13 at 9:06
Well, i think this is also allright: coach.say_punch(boxer, punching_bag), boxer.punch(punching_bag). i.e. receiver is not in the method name but in parameters. –  clime May 4 '13 at 9:29
Sure, I meant that action receiver should be guessable from call statement. –  user79302 May 4 '13 at 9:37

You have two different messages: one to command an object to punch and one to inform an object that it was punched. Consider that a Boxer object is likely going to need to respond to both. Differently. That's a really good reason to give them different names.

My inclination would be to keep punch(boxer, object, strength) and rename the opposite method to punched. You could call it handle_punch or something like that but then it's still ambiguous whether it's to handle a punch command or the notification that it got punched.

share|improve this answer
A good point about Boxer needing both punch and something like handle_punch (would be defend in this particular case). But punching bag is never going to be bidirectional like that. And there is already this file.close()... –  clime May 4 '13 at 9:36
defend is a command. It is one possible action that an object could take in response to punched, but you wouldn't want other objects to invoke defend directly. –  user2313838 May 4 '13 at 14:52

I agree that "punch" is a good method name for the Boxer class, as (with some tweaking) it could be reused against other objects. It also accurately describes that an object of a class is doing an action on another object. Though, I would rename the method to "doPunch", to more clearly demonstrate the relation.

For the PunchingBag class however, I find the method name to be either too vague or a little inaccurate of what is happening in the method. When I see "punch", I think that something is punching something else. However, in here, the PunchingBag object is reacting to a punch from an object (in this case, a Boxer object). So, I would rename the method here to "isPunched" to illustrate that the object is reacting to a punch.

Though, this is my interpretation of how I would name the methods. It's all a matter of taste and which standards you are following.

share|improve this answer
isPunched is really misleading (more or less, depending on framework naming scheme). –  user79302 May 4 '13 at 0:17
It is usual that method is applied to that object, on which it is called. What's wrong with just punch()? –  user79302 May 4 '13 at 0:18
Well, I totally understand that need to specify the action direction but I think there is something about OOP and its philosophy that makes this unnecessary. Some kind of abstraction that is connected with that famous explanation that objects "send messages" to each other. –  clime May 4 '13 at 1:06

hmmmm. i'm questioning punching bag as a class, because you dont really care about the punching bag -- you care about the impact and strength of the Boxers fist. so the methods should be about whatever is measuring and reporting the punch impact. even if this is coming from the 'punching bag', the naming should still reveal the responsibility - like punchImpactMeter etc.

share|improve this answer

The boxer punches the punchingbag -> boxer.punch

The punchingbag gets punched by the boxer -> punchingbag.get_punch

share|improve this answer
this doesn't seem to offer anything substantial over points made and explained in prior 6 answers –  gnat Mar 22 at 9:45

protected by gnat Mar 22 at 9:44

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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