How to become an author
Search
Write a publication
Pull to refresh

Comments 10

как-то дискуссия разделилась на приватную в гмыле и публичную тут
Total votes 1: ↑1 and ↓0+1
Ты, кстати, еще не ответил. Ни в мыле ни тут :)
Total votes 1: ↑1 and ↓0+1
:) Да, давайте я сюда перекидаю реплики.


Александр Гранин
Николай, и вам спасибо, я вас услышал. И правда у меня такие мысли вертятся, и я к тому иду. Скажем, серию статей «Дизайн и архитектура в ФП» я буду продолжать писать с прицелом на книгу. Вероятно, вернусь к статьям в сентябре.

Но вообще, эту книгу можно писать коллективно, при том что материала в сети уже очень, очень много. Там и про функциональные паттерны в Scala, и про паттерны JS, и про Haskell — так или иначе говорилось. Пришло время систематизировать информацию.

Вот, например, книга "Scala Design Patterns: Patterns for Practical Reuse and Design". Уважаемые скалисты, если вы читали, — о чем там? Я не читал еще.
Есть и статьи, вот: Design Patterns in Scala.

Вопрос тут в том, о каких паттернах таки идет речь — о функциональных? или об ООП? А есть ли паттерны на стыке ФП и ООП? Как это скажется на дизайне приложений? Какие открывает новые способы программирования? Вот те вопросы, которые мне задают люди из кровавого энтерпрайза, когда задумываются над ФП в продашне.

Антон Холомьев
Некоторые из паттернов переосмысливаются в контексте ФП.
Как например Observer. В ФП предлагается вместо него использовать ФРП (реактивное программирование).
Подробнее можно почитать в статье: Deprecating the Observer Pattern with Scala.React.
Total votes 1: ↑1 and ↓0+1
Паттерны проектирования подсказывают, как можно удачно сгруппировать данные и функции, чтобы код был более читаемым, модифицируемым и удобным в использовании. Например, паттерн NULL-object заключается в группировке вместе методов, реализующих поведение сущности, когда основополагающий признак сущности не определён. Flyweight рассказывает, как сохранить качество кода при оптимизации расхода памяти.
Необходимость в паттернах проектирования возникла, потому что люди, чётко понимающие принцип ООП, затруднялись эффективно применять его на практике. Часто в одном процессе участвуют несколько объектов, и непонятно, в какой класс следует поместить метод. И тут на помощь приходит медиатор, инкапсулирующий внутри себя взаимодействие группы объектов в рамках какого-то процесса.
В ФП основная единица — функция, и тут смысл проектирования сводится к грамотному распределению кода по функциям. И если поиск сходств и различий назначений методов в ООП (для грамотного их распределения по классам) вызывает сложности даже у опытных программистов, то дробление функции на несколько более простых вызывает сложности лишь у новичков. Вполне возможно, что большинство людей, кристально ясно понимающих принцип ФП, не будут периодически сталкиваться с проблемами реализации принципа ФП на практике по причине сложности самого принципа. Соответственно, не будет сложностей при реализации — не будет и паттернов. Однако будут сложности или нет — это как гадание на кофейной гуще. Сейчас ФП не получило широкого распространения среди решений сложных промышленных задач, поэтому рано делать какие-то выводы.
Total votes 1: ↑1 and ↓0+1
Оффтопик
Очень жаль, что первоначальное обьявление прошло незамеченным. С удовольствием бы присоединился, если бы узнал раньше. Надеюсь, это не последняя конференция и в следующий раз будет чуть больше напоминаний и обьявлений. Возможно, так же стоило попросить своих спикеров разместить обьявления (хотя бы и у себя в жж). Если бы об этом написал Максим или Лев то, наверняка, я бы заметил.
Total votes 1: ↑1 and ↓0+1
Да, вы правы, стоило побольше написать.
Total votes 1: ↑1 and ↓0+1
«Design patterns are bug reports against your programming language.». Большая часть проблем которые решали классические паттерны от Gang of Four уже решена в функциональных языках в том или ином виде.
Как сказал один человек, ООП — это уменьшение сложности предметной области через декомпозицию её на абстракции. ФП — это уменьшение сложности предметной области через композицию (выделение) однотипных операций. В моём понимании, решение проблемы — это когда достижение цели не вызывает сложностей. Ваша точка зрения заключается в «нет декомпозиции на абстракции — нет проблем, связанных с декомпозицией на абстракции», или, иными словами — «нет действия — нет проблем». Эта точка зрения может быть верна лишь если мы добиваемся тех же целей другими действиями. Однако не факт, что композиция однотипных операций всегда и везде борется со сложностью столь же эффективно, как и разбиение на абстракции, имеющие состояние.
Total votes 2: ↑2 and ↓0+2
С маленькой поправкой:

«ФП — это уменьшение сложности предметной области через композицию (выделение) однотипных операций над выделенными абстракциями»
Total votes 3: ↑3 and ↓0+3
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr