OOP原理和方法名称

Question

class Boxer:

    def punch(self, punching_bag, strength):
        punching_bag.punch(strength)


class PunchingBag:

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

boxer = Boxer()
punching_bag = PunchingBag()

boxer.punch(punching_bag, 2)

毫无疑问，对于拳击手来说，punch是一个很好的方法名。但是punch这个名字也适用于袋装的方法吗？在这两种情况下，我指的是作为命令的打孔(即做打孔)。

Answer 1

一个很好的经验法则是，方法名称应该是动词或谓词，这样调用它们的对象(标准Python约定中的self，大多数其他语言中的this )就成为了主题。

按照这个规则，file.close是错误的，除非您使用这样的心理模型:文件关闭，或者file对象表示的不是文件本身，而是文件句柄或某种代理对象。

一个沙袋从来不会打自己，所以punchingBag.punch()是错误的。be_punched()在技术上是正确的，但很难看。receive_punch()可能会工作，或者handle_punch()。另一种在JavaScript中非常流行的方法是将此类方法调用作为事件来处理，而这里的约定是使用以'on‘为前缀的事件名称，因此这将是on_punched()或on_hit()。或者，您可以采用过去分词表示被动语态的约定，根据该约定，方法名将仅为punched()。

另一个需要考虑的方面是，沙袋是否真的知道是什么击中了它:无论你用棍子打它、用棍子打它，还是用卡车撞它，都有什么区别吗？如果是的话，有甚麽分别呢？你能把分歧归结为一场争论吗?或者，对于不同的惩罚，你需要不同的方法吗？一个带有泛型参数的方法可能是最优雅的解决方案，因为它保持了较低的耦合度，这样的方法不应该被称为punched()或handle_punch()，而是更通用的方法，比如receive_hit()。有了这样一种方法，您就可以实现所有类型的演员，可以击中出气筒，而不改变沙袋本身。

Answer 2

我认为这是一个概念性的问题(我们如何看待世界)。可以这么说：

• 看，门要关上了。door.close()
• 哇，这张纸是自己折叠的。paper.fold()
• 见鬼的是什么？！桌子上的文件刚关了，没人在。file.close()

奇怪的是：

• 健身房里的那个沙袋刚刚打到了自己。bag.punch()

首先，它需要有一些东西来打自己(例如手臂)。你可能会说：

• 沙袋已经开始自行移动，就像有人会打它一样。punching_bag.move()

编程对象可以做其他人通常对它们做的事情(在“现实世界”中)。但我想，至少应该有一点道理，那就是这件事是对它自己做的。您应该能够轻松地想象它，而不会变得模糊(例如在punching_bag的情况下)。

Answer 3

您的方法最终将导致非常耦合的代码。

概括地说，埃里克·利珀特，理想的在这里，你会希望拳击手能够打很多东西。将出拳袋作为拳击手函数的签名意味着拳击手是在立即了解所有人(即可穿孔)的情况下创建的。另外，给予一拳和接受一拳是两件非常不同的事情，因此他们不应该有相同的名字。

我更愿意将其建模为创建一个打孔(另一个包含冲头的属性力、触点、方向等的对象)的拳击手。

该打孔袋采用onPunch等方法，接收该打孔对象，可以计算出冲头对其自身的影响。

记住这一点，事物的名称非常重要。它必须符合你对这种情况的心理模型。如果你发现自己试图解释某些事情是如何发生的--乍一看是没有意义的，或者如果你遇到了最困难的时刻，那么你的模式可能是错的，需要改变。

在你开始的时候很难改变一个模型，人们通常倾向于扭曲现实来适应这个模型。这方面的问题是，当你弯曲东西以适应(比如可以打孔的沙袋)，你正在创造的世界变得越来越复杂，交互变得越来越难实现。您最终将达到这样的地步:添加即使是最琐碎的东西，也会成为更改和bug的噩梦。这种概念性的技术债务可能有一个非常昂贵的价格，即使最初的成本在当时被认为是最便宜的事情。