Почему тип дочернего класс не совместим с родительским, не может быть назначен this?

Question

[alex4answ]

Добрый день, я так и не смог разобраться в полиморфном this и почему дочерние классы несовместимы с родительскими в некоторых моментах:

class A {
  parent: A;

  constructor(parent: A) {
    this.parent = parent;
  }
}

class B extends A {
  getParent(): this { // ERROR
    return this.parent; // ERROR
  }
}

Error: Type 'A' is not assignable to type 'this'. 'this' could be instantiated with an arbitrary type which could be unrelated to 'A'.

Да речь идет о невозможности назначить тип A полиморфному типу this

Почему?, ведь подкласс B расширяет класс A, соответственно они совместимы, в чем проблема?

Answer 1

[Alex]

В том то и дело, что он его расширяет.
Класс Б = А, но А != Б.

Вы говорите, что метод должен возвращать класс Б (со всеми расширениями) но возвращаете А, где их нет.

Рабочий вариант

Comments

[alex4answ]

Alex спасибо, я немного запутался

[alex4answ]

Alex а как разрешить возвращать this, то есть объект дочернего класса?
Например мне необходимо сделать базовый класс, и расширить его, из методах B возвращать конкретно объекты типа B, а не родительского класса ?

[Alex]

alex4answ,
Как вариант, не объявляйте что вы возвращаете. TS сам вычислит возвращаемый тип.

[alex4answ]

Alex, спасибо, я просто думал что хорошим тоном нужно объявлять вообще все типы и избегать any :)

[Alex]

alex4answ, Ну, пожалуй это так, да. Но, я например так не делаю :)
Разница в том, где вы получите ошибку.

Например, у нас была функция которая возвращала строку. Потом, её переписали и теперь она возвращает число.
Если не объявлять возвращаемый тип, то мы получим ошибку в клиентском коде
Пример

Но, если объявить желаемый возвращаемый тип, то ошибка будет в теле функции^ Пример

[Alex]

alex4answ, Лично я, указываю возвращаемый тип только в критичных местах, где сложный алгоритм функции, которая вот кровь из-носу не должна возвращать что-то другое. В остальных случаях я позволяю себе опускать типы. Но, то я )

[alex4answ]

Alex, еще раз спасибо за подробное объяснение )
Буду придерживаться такого же пути )

[Alex]

alex4answ, ну и на последок, можно написать что-то такое:

class B extends A {
  getParent(): B['parent'] {
    return this.parent;
  }
}

Так вы гарантируете себе, что метод возвращает конкретное поле, но не привязываетесь к типу этого поля.

[WbICHA]

Alex,

Например, у нас была функция которая возвращала строку. Потом, её переписали и теперь она возвращает число.
Если не объявлять возвращаемый тип, то мы получим ошибку в клиентском коде

А разве это не должно быть отловлено юнит тестами?)

alex4answ, собственно, согласен с твоим тёзкой, и ещё раз скажу: есть юнит тесты и если что-то не так с типами стало, они это должны отловить.
Да и в целом достаточно проблемно допустить такой просчёт, ведь это должен ошибится ты сам, тс должен не увидеть проблему, и, опять же, тесты должны пройти.

[Alex]

WbICHA, Юнит тесты не всегда есть, не всегда нужны и не всегда возможны.
Например проверку типов я не вижу смысла покрывать тестами, так как TS для того и нужен. Это своего рода отдельный юнит-тест.
Тестировать нужно только реализацию. Например убедится, что получаемое число это именно то число что ожидалось.

Но бывают случаи когда юнит-тесты излишни. Не в том смысле что они не нужны, а в том, что на них будет больше затрат чем выгоды.

Ну, и нельзя забывать про всякое Legacy. И даже на относительно свежей кодовой базе процесс может быть построен так, что тестирование внедрить очень сложно.

[WbICHA]

Alex, ну хз, я сейчас в проекте со 100% покрытием юнит тестами и это такой кайф... Да и поддерживать их удобно.