OR
надо кароче тащить интерфейсы в TC39 чтобы принимали в JS
исключено же))
Size: a a a
2020 March 03
GS
А решение через абстрактный класс - сильно плохое?
DZ
ну просто тебе надо наследоваться а не имлеменировать что как бы разное
DZ
кароче нет интерфейсов - нет проблем)
OR
А решение через абстрактный класс - сильно плохое?
нормальное, но до тех пор пока ты не захочешь экстендиться от двух абстрактных классов)
а ну вот выше Дмитрий тоже самое написал
а ну вот выше Дмитрий тоже самое написал
DB
использование абстрактного класса вместо интерфйса так себе совет, классический пример: два высокоуровневых сервиса требуют каждый от своей зависимости определенной сигнатуры методов, каждый описывает интерфейс для зависимости, низкоуровненвый сервис отвечающий за определенный домен может одновременно имплементить оба интерфейса, как ты на абстрактном классе это сделаешь? никак
А что тебе мешает заимплементить два абстрактных класса?
DZ
кстати не ругается
DZ
в таком случае можно на абстрактных классах реал вместо интерфейсов попробовать
MV
Есть тут те, кому удалось
Вроде есть у них пример но не получается генерацию заставить работать, не видит связи и в логах очень мало информации, чтобы понять что он хочет.
typeORM c миграциями many-to-many заставить работать?Вроде есть у них пример но не получается генерацию заставить работать, не видит связи и в логах очень мало информации, чтобы понять что он хочет.
DB
Я юзал абстрактные классы пару раз, но так и не понял зачем они нужны) Хватало не абстрактных и интерфейсов чтобы их имплементить
Абстракктные классы просто не актуальны, если ты пишешь серверный бэк, либо фронт. Когда ты пишешь библиотеку какую-нить, это просто маст-хэв. Их отличие от интерфейсов в том, что они могут содержать в себе реализацию.
Поэтому если у тебя есть какая-нить базовая сущность, от которой экстендится много других сущностей, но базовая сама по себе не может иметь инстанс - то это абстрактный класс
Поэтому если у тебя есть какая-нить базовая сущность, от которой экстендится много других сущностей, но базовая сама по себе не может иметь инстанс - то это абстрактный класс
Ti
Абстракктные классы просто не актуальны, если ты пишешь серверный бэк, либо фронт. Когда ты пишешь библиотеку какую-нить, это просто маст-хэв. Их отличие от интерфейсов в том, что они могут содержать в себе реализацию.
Поэтому если у тебя есть какая-нить базовая сущность, от которой экстендится много других сущностей, но базовая сама по себе не может иметь инстанс - то это абстрактный класс
Поэтому если у тебя есть какая-нить базовая сущность, от которой экстендится много других сущностей, но базовая сама по себе не может иметь инстанс - то это абстрактный класс
У меня возникла проблема с тестированием реализации)
Ti
Как раз потому что нельзя инстанс сделать
DB
У меня возникла проблема с тестированием реализации)
Ты не должен тестировать абстрактный класс, потому что он по своей природе не должен иметь инстансов, так как реализация в нём не закончена.
Если у тебя законченная реализация, значит это не абстрактный класс
Если у тебя законченная реализация, значит это не абстрактный класс
OR
А что тебе мешает заимплементить два абстрактных класса?
неплохое замечание, не знал что можно имплементить абстрактный класс, пример: https://www.typescriptlang.org/play/?ssl=5&ssc=8&pln=5&pc=7#code/IYIwzgLgTsDGEAJYBthjAgggg3g0kM8CAZgPZkAUAlAFwIBuZAlgCYIC+AUFwdHIhRoMAIVz5w-YiGBQa9AHYBXALYgAplE48h6BAGEEzFQAdk6leoUQMmADQIxeclWriOCGXLd4o6iEpQCggADJzaQA
но все равно как по мне это неверное использование абстрактного класса как интерфейса
но все равно как по мне это неверное использование абстрактного класса как интерфейса
DZ
Ну можно попробовать
DZ
DZ
Если нест проглотит
DZ
То и проблема решена
OR
Скинь пример плиз если заведется