Ну строительные кирпичики разные бывают, есть мелкие совсем, как в банде четырех описаные. А есть же паттерны для работы с БД вроде unit of work или active record, тоже кирпичики, хотя чуть крупнее. Или вот MVC совсем большой паттерн, определяющий дизайн на верхнем уровне. Про последние два непонятно, например, что изменится, если язык еще и ФП умеет. И насколько, дотустим, теже active record применимы в чистом функциональном языке и что в замен тогда?
Дело не в «функциональных языках», а в сложности домена самого по себе. Нет referential transparency, данные сами себя мутируют повсюду? Получите огромные проблемы и крайне неэффективный defensive copying повсюду, распишитесь. Либо ад с локами, дидлоками и прочим contention. Поэтому люди отказываются от самоизменяющихся объектов (объектов в ООП-стиле), берут иммутабельные структуры и чистые функции. События внезапно начинают поступать со всех сторон, а не только от пользователя? Между компонентами M, V и C появляется лаг в секунды? MVC разваливается, код начинает выглядеть как лапша из коллбеков и хаков. Люди пытаются использовать штуки вроде FRP и прочих Rx. Полная синхронизация на записи в БД становится невозможной? CRDT, vector clocks и прочая содомия ждут прямо за углом, споры о «какой бы ORM выбрать, чтобы поменьше писать?» вызывают максимум нервный смех. И так далее
( ... )
>Дело не в «функциональных языках», а в сложности домена самого по себе. Про какой именно домен идет речь? Потому что из описанного ниже, я этого не понял. Дальше идет несколько сумбурная критика ОО. При этом, понятно, какие профиты несут в себе чистые функции и неизменяемые объекты, но что делать с тем, что требования могут радикально меняться и, внезапно, противоречить уже имеющейся логике?
>акцент на reusability себя не оправдал, потому что «фреймворки» быстро превращаются в диких монстровЯ где-то вычитал интуитивное определение разницы между фреймворком и библиотекой. Там говорилось, что основное различие в том, что фреймворк сам вызывает твой код, а код библиотеки ты должен вызвать сам. Я думаю, что это близко к истине. И если отталкиваться от такого определения, то вполне понятно, почему фреймворки между самой плохо сочетаются - каждый из них хочет сам владеть потоком управления
( ... )
я вот не считаю, и вот почему: если уж кодить на языке, который умеет только ООП, но не ФП, то вполне можно использовать паттерны как "кирпичики".
С другой же стороны, строго DO. NOT. WANT. кодить на таких языках.
Reply
Reply
Reply
Про какой именно домен идет речь? Потому что из описанного ниже, я этого не понял. Дальше идет несколько сумбурная критика ОО. При этом, понятно, какие профиты несут в себе чистые функции и неизменяемые объекты, но что делать с тем, что требования могут радикально меняться и, внезапно, противоречить уже имеющейся логике?
>акцент на reusability себя не оправдал, потому что «фреймворки» быстро превращаются в диких монстровЯ где-то вычитал интуитивное определение разницы между фреймворком и библиотекой. Там говорилось, что основное различие в том, что фреймворк сам вызывает твой код, а код библиотеки ты должен вызвать сам. Я думаю, что это близко к истине. И если отталкиваться от такого определения, то вполне понятно, почему фреймворки между самой плохо сочетаются - каждый из них хочет сам владеть потоком управления ( ... )
Reply
Речь про сложность доменной логики, иначе говоря про сложность предметной области самой по себе.
Reply
Leave a comment