面向对象编程视角下Point与Line类的distance和midpoint方法归属探讨

嘿，这个问题其实是OOP里特别常见的「职责边界」困惑，我来给你拆解几种方案的合理性，帮你理清思路～

OOP里方法归属的核心逻辑很简单：这个行为是不是这个对象本身就该具备的能力，而不是“谁会用到这个方法”。

方案1：distance()归Point类，midpoint()可灵活选择 #

先聊distance()：一个Point天然就应该知道「我和另一个Point之间的距离」——就像你问“我离你有多远”，每个个体都能自己算出来。这种设计不仅符合直觉，还能省去冗余的getter方法，直接用自身属性计算：

class Point:
    def __init__(self, x: float, y: float):
        self.x = x
        self.y = y
    
    def distance(self, other: 'Point') -> float:
        return ((self.x - other.x)**2 + (self.y - other.y)**2)**0.5

再看midpoint()：这里有两种完全合理的思路：

• 放在Point类：设计成midpoint(self, other: 'Point') -> Point，意思是「我和另一个点的中点」，逻辑上完全通顺——毕竟中点是两个点共同决定的，让Point来实现没毛病。
• 放在Line类：既然Line是两个Point的集合，「求这条线段的中点」也是线段的天然属性，业务场景如果中点总是和线段绑定，放这里也很合适。

方案2：两个方法都归Line类 #

这种方案技术上可行，但会让Point类变成一个“纯数据容器”——只有属性没有行为，违背了OOP「对象是数据+行为的结合体」的设计思想。而且如果之后需要计算两个不属于同一条Line的独立Point的距离或中点，你还得先构造一个Line对象，反而增加了不必要的复杂度，限制了Point的复用性。

方案3：提取成通用工具类（灵活的补充方案） #

要是你实在不想纠结归属，还可以把这两个方法抽成独立的几何工具类/函数，比如：

class GeometryUtils:
    @staticmethod
    def distance(p1: Point, p2: Point) -> float:
        return ((p1.x - p2.x)**2 + (p1.y - p2.y)**2)**0.5
    
    @staticmethod
    def midpoint(p1: Point, p2: Point) -> Point:
        return Point((p1.x + p2.x)/2, (p1.y + p2.y)/2)

这种方式适合当你有大量通用几何计算，不想把方法绑定在某个类上的场景，尤其是多个类都需要调用这些计算的时候，通用性拉满。

• 优先选**distance()归Point，midpoint()根据业务场景二选一**：如果你的业务里中点更多和线段关联，就放Line；如果经常需要计算任意两个点的中点，就放Point。
• 尽量避免把两个方法都放Line类，会让Point的复用性大打折扣。
• 工具类方案适合复杂的几何计算场景，是个很灵活的补充选项。

内容的提问来源于stack exchange，提问作者Alex