АО
Проблема в том, что mongoose завязан на коллбэках
Помоему Rxjs умеет оборачивать нодовские callback-и
Size: a a a
2016 August 11
R
я честно не помню в чем разница в TS между type и interface, в type можно также описать объект. Но implements SomeType не помню можно или нет
AK
я честно не помню в чем разница в TS между type и interface, в type можно также описать объект. Но implements SomeType не помню можно или нет
Так и есть. По сути, можно и так, и так
R
Просто как структуры в C++
я C++ плохо помню но разве там нету отдельно интерфейсы для классов?
АО
Интерфейсов у обьекта может быть куча. Тип - только один
VM
Интерфейсов у обьекта может быть куча. Тип - только один
Вспомни наследование и кастинг типов
AK
я C++ плохо помню но разве там нету отдельно интерфейсы для классов?
Там нет интерфейсов (по стандарту 1998 года, более поздние мне не знакомы, т.к. уже 10 лет не пишу на C++), но интерфейсы в TS — это не совсем ООП интерфейсы
AS
Модельную структуру приложения имхо проблемно строить на одних интерфейсах. Вот к примеру такая задача - есть объект Response от сервера, нужно по набору условий вытащить признак его успешности. В классах это решается геттером с условиями, а интерфейс придется внешним методом обрабатывать
AK
В том и дело, что они могут (и часто, если посмотреть родные библиотеки ng2) использу/тся именно как структуры
R
Какая книга кстати наиболее всеобъемлющая по TS? TypeScript Deep Dive показалось мало. Некоторые вещи лучше в офф доке освещены. Пока наткнулся на Mastering TypeScript
AK
На первом проекте я хотел сначала использовать логику, к которой привык на других языках — сначала объявляешь интерфейсы, потом реализации классов для них. Но когда понял, что <объект класса implements I> instanceof <интерфейс I> === false, забил на это дело, и стал использовать интерфейсы как структуры
AK
и еще была практика, когда переменная, для которой указан тип интерфейс CatalogEntity не пропускает без жесткого приведения объект класса CatalogCategory, который implements от CatalogEntity
AK
точнее не переменная, там возврат был функции
АО
Интерфейсы позволяют достичь Dependency Invertion Principle из SOLID
R
AK
Интерфейсы позволяют достичь Dependency Invertion Principle из SOLID
Я это имел ввиду, но мне кажется, в TS это не совсем работает так как например в Java
АО
Работает. Я понимаю о чем ты говоришь, много чего не доступно в TS, всяких удобных способов работы с ними нет, но интерфейсы в TS полноценные. Они выполняют свою базовую функциональость
AK
Работает. Я понимаю о чем ты говоришь, много чего не доступно в TS, всяких удобных способов работы с ними нет, но интерфейсы в TS полноценные. Они выполняют свою базовую функциональость
Возможно, ты прав. Но вот у меня был один конкретный вопрос: если я указываю в качестве результата функции или аргумента интерфейс, то почему нельзя передать ему класс-реализацию интерфейса, без того, чтобы компилятор отругался или без жесткого приведения (которое пропустит, даже если ты затупил и там оказался скаляр)? Это же ломает базовые принципы?
АО
Можно пример в студию?
DB
Возможно, ты прав. Но вот у меня был один конкретный вопрос: если я указываю в качестве результата функции или аргумента интерфейс, то почему нельзя передать ему класс-реализацию интерфейса, без того, чтобы компилятор отругался или без жесткого приведения (которое пропустит, даже если ты затупил и там оказался скаляр)? Это же ломает базовые принципы?