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.

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).

Your approach will eventually lead to very coupled code.

To summarize Eric Lippert ideally here you’d want the boxer to be able to punch a great many things. Having the punching bag as the signature of the boxer function implies that the boxer is created with an immediate knowledge of All (that is punchable). Plus giving a punch and receiving a punch are two VERY different things, thus they should not share the same name.

I would rather model this as a Boxer that creates a punch (another object that contains the punch’s attribute force, reach, direction etc).

Then have the punching bag with a method such as onPunch which receives this punch object can the compute the effect of the punch on itself.

Keeping this in mind the name of things matters a lot. It must fit the mental model you have of the situation. If you find yourself trying to explain how something can happen which makes no sense at first sight, or if you hare having the hardest time naming somehting then perhaps your model is wrong and needs to change.

It’s hard to change a model after you started, people generally tend to bend the reality to fit the model. The problem with this is that as you bend things to fit (such as a punching bag that can punch things) the world you are creating becomes more and more complex and the interactions get to be more and more difficult to implement. You will eventually reach a point where adding even the most trivial thing becomes a nightmare of changes and bugs. This conceptual technical debt can have a very steep price even if the initial cost was perceived at the time as the cheapest thing to do.

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?

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.

This is the problem which I call “object/subject” confusion and it’s quite prevalent.

Sentences generally have a subject who does the verb on their target object.

Now with regard to programming the only thing that actually does things is the computer. Or virtually a process, thread or a fiber.
The objects are not animate by default. They don’t have their own threads running so they can’t really do anything.

This means methods operate on them, they are the target of the action not who does the action. That’s why we call them “objects” not “subjects”!

When you say File.close it’s not the file closes itself, it’s current running thread who closes the file.
If you say Array.sort, the current running thread sorts the array.
If you say HttpServer.sendRequest, the current running thread sends the request to the server (not vice versa!).
Similarly saying PunchingBag.punch means the current running thread punches the bag.

This means if you want the Boxer to be able to punch, then it must be a subclass of a Thread so it can do things like punching bags in its thread function.

However sometimes it also makes sense to say punching bag punches itself in the case where each object has their own thread you may want to avoid race conditions and implement method calls as message passing: you punch the bag by sending it the punch message, it’s thread punches itself then sends you back the punch successful message, but that’s only an implementation detail.

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.

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.

The boxer punches the punchingbag -> boxer.punch

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