у каждого писателя своё определение каждого конкретного паттерна, которое может быть как-то соотносится с определениями других писателей.
в пределах одной команды они убалтываются
никакой ризонинг о паттернах и построение абстракций поверх паттернов невозможен по причине чудовищного протекания таковых попыток.
Это как проблема двух византийских генералов: невозможно в теории, на практике решено.
совершенно не исполняется
Я даже не знаю чем контрить такие аргументы.
в паттерны не заложена ни soundness, ни completeness, ни composability,
Composability дело наживное, насчет первых я могу поспорить что оно никому не впилось, на практике.
Самый простой и банальный пример — перестановка F[G[_]] в G[F[_]] aka метод сиквенс, в скале это ровно один def в котиках, в ооп — каждый раз переизобретается в точке использования.
1. Не пишите ооп.
2. Вы описываете реализацию паттерна в частном контексте фп подхода и языка. Как это противоречит тому, что я написал?
в силу отсуствия культуры построения теорий не смогли сделать из них что — то стоящее
Они описали часто используемые шаблоны и использовали популярную на тот момент джаву с целью создания общей системы метафор для прикладного аспекта. Я сомневаюсь что кто-то пытался сотворить из этого науку. И да, на данный момент шаблоны и архитектуру изучают как в классической среде, так и на стыке с теорией функций, ибо дажеесли второе дает строгость и саунднес и прочее, эволюцию первого не реализовать без какой-нибудь номенклатуры и теоретических, пусть и куцых, систем.
Вот так и живем, один хитровымороченный однострочник заменяет джава класс вместе со всеми тестами и ценой поддержки
боюсь от тестов (в одном или ином виде) не убежать, и у ФП цена поддержи и когнитивная цена далеко не нулевая.
sound теоркат,
Если вы собрались гнобить 90% индустрии по строгости, то я бы не упоминал soundness и TS в одной ветке.
Так-то стратегия будет обычной функцией, фабрики и декораторы так используются, chain of responsibility вшит в ивенты, паб саб тоже повсеместно. Это все тот же ГОФ, только без рецептов для джавы. Вся суть паттернов в узнаваемости их при общении, а не в форме исполнения
Меняй профиль на линкеде на Haskell Developer, даже бандюки знают что эти под мостом бомжуют.
В redux-thunk есть третий параметр extraArgument, который может быть объектом с ссылками на сервисы и он инжектится в каждый thunk. В redux-saga есть контексты, которые так же позволяют инжектить. Но это все имеет смысл если вы держите бизнес-логику вне компонентов. Если пишите без стейт менеджмента, то context provider + простенький хук а-ля useServiceLocator примерно ту же роль исполнят
Давай не будем приписывать мне слова. Я говорил именно про саунднесс и комплитнес, а не про типизацию. Тот же тс позволяет типизировать не будучи саундным, и при это закрывать 99% дыр.
Я тоже умею сравнивать дерьмо с одной стороны и конфетку с другой
Я и так этим не занимаюсь
чтд
опять крайности против конфетки
Перечитай. Я не против фп, я лишь говорю, что это лишь форма имплементации шаблонов. В чистом фп коде тоже буду шаблоны, пусть и свои. Я не знаю че ты как с цепи сорвался на джаву, хоть я ее и не упоминал. Отрицать плюсы шаблонов в общении, особенно когда мы даже не близко к смене парадигмы, крайне недальновидное занятие.
Я пожалуй прекращу спорить после этих крипто переходов на личности