Частично решают же, что ты мог сломать, зато на assert не тратишься, ну и очень быстро

очень быстро - это как быстро? по сравнению с чем?

по скорости исполнения думаю snapshot test >= unit test

по скорости исполнения думаю snapshot test >= unit test

я может быть плохо понимаю как работают snapshot tests

ну то есть я знаю только о хренях в jest для фронта + в довольно удобный подход который удобен при рефакторинге и сравнении работы двух имплементаций разных но это не быстрее юнитов

Нет тестов нет проблем

Удобно)

Нет тестов нет проблем

property based же

К сожалению property по волшебству сами не появляются

К сожалению property по волшебству сами не появляются

в отличии от багов)

слушай, а не знаешь, может уже есть подборка паттернов багоделов?

ну мол распространенные паттерны приводящие к багам, интересная ж тема

и под паттернами я тут больше про поведение человека)

Хмм

Интересная постановка вопроса

Не, подборку такую вряд ли видел)

Нет тестов нет проблем

Dependent Types же, тесты это для не-тру типизированных языков ?

Ох лол

А ты пробовал их юзать?))

Почему то никто не задумывается, что кроме решения проблем, новые концепции так же несут и новые проблемы

И в данном случае только успевай ладошки подставлять

тесты и типы - это из разной оперы, ребят

?

типы позволяют писать корректный код, но они не позволяют проверить логику

код может прекрасно компилиться, но не выполнять поставленную задачу

если уж вы хотите тесты, но чтоб в математику - курите формальные методы

https://en.wikipedia.org/wiki/Formal_methods

Вот как раз с formal proofs и начинаются все эти dependent types

Просто они требуются значительно меньшему количеству людей, чем они сами думают)

тут есть большая разница

что именно ты доказываешь

что твоя программа не зависнет, скажем, или не упадет - это теория типов туда сюда

а что твоя программа делает именно то, что надо - это формальные методы

например, если ты пишешь программу для обработки какого-то IoT с кнопками, то как ты на типах проверишь, что все варианты их нажатий учёл?

например, если ты пишешь программу для обработки какого-то IoT с кнопками, то как ты на типах проверишь, что все варианты их нажатий учёл?

Через представление всех допустимых вариантов через сумму типов и доказательство корректного хэндлинга каждого из них

https://www.youtube.com/watch?v=VDfX44fZoMc

Посмотрел этот доклад и еще раз убедился что проблемы тестирования в ООП от: - Микса эффектов и логики, вроде вызова "репозиториев" (лезущих на сервер) из бизнес-логики (какое-там уж там reference-transparenty) - Размазывания стейта по куче объектов в памяти - Неиспользование всей выразительности типов (нет даже типов с явной nullability, а потом тесты на NPE пишут) те все проблеммы в самом ООП ?‍♀️

Посмотрел этот доклад и еще раз убедился что проблемы тестирования в ООП от: - Микса эффектов и логики, вроде вызова "репозиториев" (лезущих на сервер) из бизнес-логики (какое-там уж там reference-transparenty) - Размазывания стейта по куче объектов в памяти - Неиспользование всей выразительности типов (нет даже типов с явной nullability, а потом тесты на NPE пишут) те все проблеммы в самом ООП ?‍♀️

Все что ты описал проблемы плотников, а не топора/пилы/инструмента

Посмотрел этот доклад и еще раз убедился что проблемы тестирования в ООП от: - Микса эффектов и логики, вроде вызова "репозиториев" (лезущих на сервер) из бизнес-логики (какое-там уж там reference-transparenty) - Размазывания стейта по куче объектов в памяти - Неиспользование всей выразительности типов (нет даже типов с явной nullability, а потом тесты на NPE пишут) те все проблеммы в самом ООП ?‍♀️

спс за текстовое резюме)

ребят, прошу помогите плз, я уже не понимаю как правильно. В общем - есть сервис значит нотификаций. там немного TS ```public async create(data: any, templateCode: string): Promise<Notification> {```вот в этот data: any могут приходить разные модели из доменной области и я нифига не понимаю как подружить одно с другим. То ли проверять тупо на instanceof, то ли на уровне интерфейсов это сделать, то ли вообще в итоге вынести отдельный аргумент под тип

эммммм, почему телега не отформатировала кусок с исходником как исходник?...

короч есть сервис нотификаций - он берет доменную модель и имя шаблона и компилит из этого мессагу. в нем же будут мапперы которые понимают как конкретную доменную модель переводить в "единый" формат для того чтобы сервис нотификаций дальше работал как надо (это тоже спорно но сейчас не суть)

ну и короч на этом все и остановилось(

во, понял, как можно не с помощью instanceof (условно) понять какая именно модель мне приходит? и что было бы правильно

просто если брать instanceof мне придется тогда все возможные сущности предметной области выносить например в ENUM в сервисах но это вообще нихрена не гут, достаточно лишь какой-то новый класс добавить

примеры моделей доменной области - order, user, booking + нотификации могут вообще быть не завязаны ни на одной модели, а быть сами по себе (типа есть мануальная опция отправки, решит маркетолог что всем надо еб*нуть промокод потому что сейчас лето, и вызовем сразу create но в первом аргументе будет null)

ладно, я заткнулся и жду когда старожилы ответят

я один в пятницу вечеру работаю или у меня прокся в телеге тормозит?....

ты время видел?

видел, тут говорили типа в пятницу вброс делаешь и все ок))))

ну рили меня эта проблема мучает уже 6 часов и я не знаю что делать, куда еще спрашивать как ни в этот чат?...

блин, столько букв, а я пьян

да я тож)

но суть от этого не меняется

спс за текстовое резюме)

видос же не о том

Посмотрел этот доклад и еще раз убедился что проблемы тестирования в ООП от: - Микса эффектов и логики, вроде вызова "репозиториев" (лезущих на сервер) из бизнес-логики (какое-там уж там reference-transparenty) - Размазывания стейта по куче объектов в памяти - Неиспользование всей выразительности типов (нет даже типов с явной nullability, а потом тесты на NPE пишут) те все проблеммы в самом ООП ?‍♀️

- умные слова какие-то - а как-то по другому у тебя может быть? Ну вот я очень хотел бы посмотреть на реальный проект, какой-нибудь небольшой, что бы были видны преимущества. Ну или хотя бы их можно было бы объяснить. Желательно на примере каких-то изменений. - kotlin, scala, swift?

Посмотрел этот доклад и еще раз убедился что проблемы тестирования в ООП от: - Микса эффектов и логики, вроде вызова "репозиториев" (лезущих на сервер) из бизнес-логики (какое-там уж там reference-transparenty) - Размазывания стейта по куче объектов в памяти - Неиспользование всей выразительности типов (нет даже типов с явной nullability, а потом тесты на NPE пишут) те все проблеммы в самом ООП ?‍♀️

проблема в том что у всех свое ООП, у большинства это ООП на классах и это проблема)

ребят, прошу помогите плз, я уже не понимаю как правильно. В общем - есть сервис значит нотификаций. там немного TS ```public async create(data: any, templateCode: string): Promise<Notification> {```вот в этот data: any могут приходить разные модели из доменной области и я нифига не понимаю как подружить одно с другим. То ли проверять тупо на instanceof, то ли на уровне интерфейсов это сделать, то ли вообще в итоге вынести отдельный аргумент под тип

instance of будет работать только если у тебя объект был создан через new ClassName(), а интерфейсы там вообще компайл-тайм фича

блин тоже верно, и как тогда быть?

там конечно нет компиляции в полном смысле, но так или иначе

я хочу избавится от фабрик и фабричных методов, там надо на кончиков пальцев все сделать чтоб можно было если что перейти на какие-то не ООП вещи ваще

забудь про new()

я хочу избавится от фабрик и фабричных методов, там надо на кончиков пальцев все сделать чтоб можно было если что перейти на какие-то не ООП вещи ваще

А при чем фабрики и ООП?

ну как тебе сказать) как показывает практика только в ооп фабрики херачат

ну как тебе сказать) как показывает практика только в ооп фабрики херачат

Ну не скажи. В процедурном подходе тоже можно нагородить)

а то ж

да, блин, там тоже есть фабрики, там тоже есть патерны - если понимать как их делать в той парадигме - но в моем случае что делать-то?

и какого хера вообще в этом чате все спят в пт вечером в 0.20 или это блажь

instance of будет работать только если у тебя объект был создан через new ClassName(), а интерфейсы там вообще компайл-тайм фича

зависит от языка. может тебе просто не нужен instanceof? может быть это симптом проблемы?

зависит от языка. может тебе просто не нужен instanceof? может быть это симптом проблемы?

Не я спрашивал) а причина проста - там в рантайме жс со всеми вытекающими)

Не я спрашивал) а причина проста - там в рантайме жс со всеми вытекающими)

ммм.... я хз для чего ты делаешь instanceof

ммм.... я хз для чего ты делаешь instanceof

Я не делаю) В C# (мой основной язык) хотя бы статическая типизация, там можно и без этого обойтись. Просто как то столкнулся с этой штукой в тайпскрипте и запомнил как она себя ведёт. Человек спросил - я рассказал что знал по теме.

зависит от языка. может тебе просто не нужен instanceof? может быть это симптом проблемы?

Ну либо ты реплай на сообщение выше хотел сделать и мисскликнул)

Я не делаю) В C# (мой основной язык) хотя бы статическая типизация, там можно и без этого обойтись. Просто как то столкнулся с этой штукой в тайпскрипте и запомнил как она себя ведёт. Человек спросил - я рассказал что знал по теме.

в тайпскрипте с типами все вполне себе нормально и у меня вопрос - зачем instanceof. Мне лень перечитывать историю сообщений ну да хрен с ним

p.s. писал и на шарпах и на тайпскрипте - не вижу разницы что там надо instanceof а там не надо

в тайпскрипте с типами все вполне себе нормально и у меня вопрос - зачем instanceof. Мне лень перечитывать историю сообщений ну да хрен с ним

Я когда то давно учил тайпскрипт и запомнил что эта штука сугубо рантайм. А интерфейсы там компайл-тайм. Всё. Не юзал. Не юзаю. Не планирую юзать.

Я когда то давно учил тайпскрипт и запомнил что эта штука сугубо рантайм. А интерфейсы там компайл-тайм. Всё. Не юзал. Не юзаю. Не планирую юзать.

// Typescript/javascript foo instanceof Foo // C# foo is Foo

если я правильно помню

разница только в выборе кейвордов

А вот GetType в том же C# юзаю активно, чтобы метаданные о типе через рефлекшон выковыривать

и да в шарпах это тоже рантаймовая штука

А вот GetType в том же C# юзаю активно, чтобы метаданные о типе через рефлекшон выковыривать

и все это тоже рантаймовые штуки)

и все это тоже рантаймовые штуки)

Ну да) Я так хэндлеры декорирую)

CQRS все дела

CQRS не про шины и не про хэндлеры ну да ладно(

Чтобы ручками транзакции не открывать, логи не писать, вот это всё

Чтобы ручками транзакции не открывать, логи не писать, вот это всё

AOP

AOP

Во-во, оно самое

Оно довольно просто реализуется, когда у тебя не класс на трилион методов, а по классу на отдельную операцию.

Накидал атрибутов, оно в рантайме, при запуске приложения сборочки посканило, в IoC контейнере что надо - порегало.

Что то чем больше я пишу код, тем меньше я хочу его писать.

Что то чем больше я пишу код, тем меньше я хочу его писать.

пойду на ts попишу

пойду на ts попишу

Ну иди) А я подожду пока C# в браузере запустят)

Ну иди) А я подожду пока C# в браузере запустят)

уже запустили

уже запустили

Blazor, да, знаю

webassembly, хоть весь CLR запускай

Оно свирепела что, но худо бедно работает

webassembly, хоть весь CLR запускай

Да как бы не хоть.. а весь)

Но там траблы есть, что стек кучей эмулировать приходится