TypeScript如何让接口/抽象类方法返回类型与实现类一致

你要实现的「父类方法返回值自动匹配子类类型」的需求，TypeScript 提供了原生的多态 this 类型支持，完全不需要在你列的三个妥协方案里选，是这类场景的标准最佳实践。

正确实现代码 #

interface XY {
    x: number;
    y: number;
}

abstract class Movable {
    abstract getPosition(): XY;
    // 直接用this作为返回类型，TS会自动绑定到实际调用的子类类型
    abstract translate(v: XY): this;

    moveTo(p: XY): this {
      const current = this.getPosition();
      const v: XY = {
        x: p.x - current.x,
        y: p.y - current.y
      };
      // 注：原示例代码这里误传了p作为参数，实际应该传入计算好的偏移量v
      return this.translate(v);
    }
}

class Point extends Movable implements XY {
    x: number;
    y: number;

    constructor(x: number, y: number) {
      super()
      this.x = x;
      this.y = y;
    }

    getPosition(): XY {
      return this;
    }

    translate(v: XY): this {
      // 这里加as this是因为TS无法在抽象类层面预判子类构造函数的返回值，属于安全的类型断言
      // 作为实现者明确知道translate返回的就是当前子类的实例，不存在类型风险
      return new Point(
        this.x + v.x,
        this.y + v.y
      ) as this;
    }
}

const p1 = new Point(5, 4);
const p2 = p1.moveTo({x: 0, y: 0}); // p2会被TS自动推导为Point类型，完全符合预期

方案优势 #

和你之前梳理的三种实现思路相比，这个写法没有任何硬伤：

• 对比「返回类型设为Movable」：完全不会丢失子类类型信息，不管是处理Movable数组做instanceof类型收窄，还是链式调用子类独有方法，TS都能正确识别类型，不存在类型降级的问题。
• 对比「显式泛型Movable<T>」：不需要子类继承时冗余写class Point extends Movable<Point>这种递归泛型声明，TS会隐式完成类型绑定，语法更简洁符合直觉。本质上多态this就是TS帮你自动处理了F-bound多态泛型的逻辑，不需要开发者手动传参。
• 对比「移除抽象类改接口、子类重复实现moveTo」：完全保留了抽象类中moveTo的通用逻辑复用，Line、Polygon等其他子类只需要实现getPosition和translate两个方法就能直接复用逻辑，不需要写重复代码。

其他子类的写法参考 #

所有继承Movable的子类写法完全一致，不需要额外配置泛型：

class Line extends Movable {
  start: Point;
  end: Point;
  constructor(start: Point, end: Point) {
    super();
    this.start = start;
    this.end = end;
  }
  getPosition(): XY {
    return this.start;
  }
  translate(v: XY): this {
    return new Line(
      this.start.translate(v),
      this.end.translate(v)
    ) as this;
  }
}

const l1 = new Line(new Point(0,0), new Point(1,1));
const l2 = l1.moveTo({x: 10, y: 10}); // l2自动推导为Line类型

只有当方法的返回值需要关联实例类型之外的其他泛型参数时，才需要用到显式泛型基类的方案，你当前的场景用多态this是最优雅的官方推荐写法。

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