应该在类层次结构中的哪个位置编写实例方法？

Question

这是我用于模拟模型的类“层次结构”的一部分（我的代码使用 Python，但我认为我的问题与语言无关）：

class World:
# highest-level class, which "knows" everything about the model
# most likely will have just one instance
# contains (e.g., in a dictionary) references to all the instances of class Agent

class Agent:
# each instance represents an agent
# an agent can, among other things, move around according to certain rules
# movement depends on the internal state of the agent,
# but also on the terrain and other information not stored in the Agent instance

问题：move 实例方法应该放在哪里？

我认为我应该将class Agent 的依赖限制在层次结构中低于自身的类（即，其实例包含在Agent 实例中的类）。但这意味着move 方法不能在class Agent 中，因为它创建了对描述地形等的类（至少是接口）的依赖——所以我不妨在Agent 中添加对（因此依赖于）World。从软件设计的角度来看，这可以吗？

另一种方法是将方法move 放在class World 中，它不会导致任何额外的依赖关系。但是，class World 将完成几乎所有的工作，在我看来，这将违背 OOP 的主要思想（我理解为不是将所有功能都集中在一个地方，而是将其包含在相关类）。

性能方面的考虑只是次要问题（而且我认为这两种方法的性能不会有所不同）。

编辑：我误用了上面的“类层次结构”一词。我指的不是继承层次结构，只是指一组实例相互包含的类。

Answer 1

将 move 方法放在有意义的地方，World 不能移动，Agent 可以。

如果您希望能够访问世界级功能，请给您的构造方法一个参数并传入世界实例。

world = World()
agent = Agent(world)

这使您的代理可以显式访问世界，而不是假设某种层次结构。

您可以更进一步，要求世界中的所有游戏对象都将世界作为参数。您可以通过创建您的代理和其他游戏对象继承的基本 GameObject 类来强制执行此操作。

class GameObject:
    def __init__(self, world):
        self.world = world

class Agent(GameObject):
    def __init__(self, world, startX, startY):
        # don't forget to call the super and pass the world to it
        super(Agent, self).__init__(world)
        self.startX = startX
        self.startY = startY

    def move(self):
        print 'I can see the world'
        print self.world

编辑：进一步扩展我的解释，如果你有一个 Enemy 类并且敌人也有一个 move() 方法，那么你可能希望敌人向代理人。但是，您不希望敌人向世界询问代理的位置，相反，您可以将代理的引用存储在敌人内部，因为它是“目标”，并在需要时随时检查它的位置。

class Enemy(GameObject):
    def __init__(self, world, target):
        super(Agent, self).__init__(world)
        self.target = target

    def move(self):
        if self.target.x > self.x:
            self.x += 5

Answer 2

我会将move 放入Agent 类中。如果不需要，Agent 应该不知道整个世界，而只知道他需要移动的相关信息。不过，如果他真的了解整个世界，那也不算太糟糕。以下是一些原因：

1. 如果您将move 方法放在World 类中，您将如何移动单个代理？是否要将 Agent 的实例传递给该方法？这看起来很丑陋。
2. 如果您希望单个代理执行某项操作，从 OOP 的角度来看，最好在实例方法中执行此操作。
3. 您还可以从另一个类的实例调用 move 方法，该类不知道世界，但知道具体的代理。

但是，如果您的所有代理同时移动并且您不希望单个代理移动，则可以将一种方法 moveAllAgents 放入世界级，然后遍历代理列表并移动所有这些代理。这样您就不需要 Agent 类中的 move 方法了。

Answer 3

但这意味着 move 方法不能 在类代理中，因为它创建了一个 依赖于（至少是接口 of) 描述地形等的类

代理必须了解他的周围环境。这意味着代理必须使用描述地形的接口，是的。不过，我不会称其为“依赖”。假设实现 ITerrain 的类实际上遵循 ITerrain 接口并没有错。 :-)

所以你把 .move() 放在代理上。然后 move() 方法将检查周围环境并尝试根据移动规则在它们之间移动。

Answer 4

不太了解您的应用程序，您也可以允许代理“了解”您世界的某个部分（可能定义为可以执行移动的最大区域，受您实施的有关多远的一些规则的限制代理可以在对 .Move 的任何一次调用中移动）。因此，代理可能包含对更大世界的“剪辑区域”的引用（这个概念是从 .net GDI+ 图形对象中使用的“剪辑矩形”中窃取的）。

在更一般的意义上，我同意其他人的观点：在代理类上定义 Move 方法是完全有意义的，并且代理类拥有对其周围环境的感知是可以接受的。

虽然 OOP 倾向于最小化不必要的依赖关系，但当它有意义时，它就有意义了。现实世界中的人知道他们的周围环境，并且能够发起在这些环境中从一个位置移动到另一个位置所需的动作。

Answer 5

您需要考虑的是Single Responsibility Principle。基本上，每个类都应该负责一个“事物”，并且应该完全封装那个责任。你应该只继承责任延伸的地方。您应该始终能够说扩展类是父类的 100% 甚至更多（在特定意义上更多）。您永远不应该遇到孩子是父母的子集并且“更少”的情况。因此，扩展世界的人并不是一个好的设计，因为世界的某些方面与人无关。

因此，如果我们看一个示例，您可以将实例方法置于该特定类的角色所规定的级别上。所以，让我们更明确地看一个例子：

class Person:
    name: ""
    birthDate: ""

class PoliceOfficer extends Person:
    badgeNumber: ""

显然这是伪代码，但它演示了正在发生的事情。

现在，您将在哪里添加 move() 方法？我们可以将它添加到PoliceOfficer，但是我们会破坏Person 的封装，因为人也可以移动。

class Person:
    def move(world):

但是，我们应该在哪里添加issueTicket() 方法？广义的Person 不能开票，所以如果我们将它添加到Person 类中，我们将打破它的责任。因此，我们将其添加到 PoliceOfficer，因为这是有意义的地方。

至于创建依赖，你应该always favor composition over inheritance。所以从这个意义上说，可以有尽可能多的依赖关系，因为它们都是软依赖关系（嗯，有点）。由于move() 采用world 的实例（或具有世界接口的对象），因此依赖项被推出类并进入调用代码。这样一来，您的班级代码就可以保持相当开放和无依赖，同时仍然保持高效。

硬编码依赖项通常被视为不好的做法。但是注入它们（通过依赖注入或组合）通常被视为一件好事。

总结：将实例方法放在合理的地方。