Паттерны проектирования для ОО-функциональных гибридных ЯП

imageУвлёкшись некторое время тому объектно-ориентированно-функциональными гибридами (вроде Scala), спустя некоторое время у меня появилось желание собрать каталог лучших практик и архитектурных решений для подобных языков программирования. У меня не было практики работы с функциональными языками до того, потому первым делом я ознакомился с некоторыми паттернами для таких языков. Кроме того, в процессе изучения Скалы многие классические паттерны GoF оказываются частными случаями конструкций языка, потому в них попросту отпадает необходимость. Возможно, дело в том, что на самом деле паттерны проектирования — это слабость современных яп, но это уже тема для другой статьи.
В этой статье я хотел бы вкратце рассказать о том, как обстоят дела с паттернами проектирования для языков вроде Скалы. В дальнейших статьях я расскажу о самых интересных (по моему мнению, конечно же) из них, и постараюсь составить некоторый каталог таких паттернов.


Со своими идеями я заглянул (конечно же) на StackOverflow. Оказалось, что паттерны для языков вроде Скалы вот уже год разрабатываются и совершенствуются в скала-комьюнити. В основном — самим автором языка, Мартином Одерски (несколько примеров в его работе «Scalable Component Abstractions») и его соавтором по книге «Programming In Scala» и автором фреймворка ScalaTest, Биллом Веннерсом (две публикации: «Stackable Trait» и «Selfless Trait»). Похожая проблема также поднимается в работе «Independently Extensible Solutions to the Expression Problem».

Также в эту коллекцию вполне подходят паттерны, которые применяются для систем, построенных на взаимодействии Actor'ов. Почти все паттерны из книги Боба Мартина «Enterprise Integration Patterns» можно легко перевести на язык Actor'ов.

О монадных паттенах в ближайшее время можно будет почитать в новой книге «Monadic Design Patterns for the Web» автора Грега Мередита. А кому не терпится почитать уже сейчас, можно ознакомиться с уже написанными главами тут.

Некоторые паттерны в более-менее сформулированном виде можно также найти в этом каталоге. Там же есть некоторые классические паттерны, реализованные на Скале. Почитать об особенностях реализации некоторых паттернов можно: Observer, Builder.

Эмулирование Type Classes из Хаскелля также можно считать паттерном проектирования. Об этом статья Мартина «Poor Man's Type Classes».

Ну и наконец, многие замечают, что конструкцию с несколькими списками аргументов, последний из которых состоит из одного аргумента типа Unit также вполне можно считать паттерном:

def command(expr: T)(block: => Unit) {...}

command (expr) {
   block
}

Но для этой конструкции пока не придумано имя. Возможно у хабрасообщества есть идеи по этому поводу?

В этой статье я лишь поделился ссылками на англоязычные источники по теме. Так как ссылок было много, собрать из них ссылочный пост, который бы поместился в 500 символов у меня так и не получилось. Надеюсь, НЛО будет благосклонно.
Если тема окажется интересной, в дальнейшем я обязательно классифицирую и упорядочу информацию из этих источников в виде удобоваримого каталога с блэкджеком и UML'ками. Очень интересно услышать отзывы сообщеста.


UPD: перенёс в новенький, сверкающий блог о Скале. Спасибо администрации хабра за его создание.
+43
1 июля 2010, 16:55
52
folone 57,4

комментарии (19)

+4
Quiz #
«Папа, а ты с кем только что разговаривал?» — Приблизительно такая реакция будет у 80% прочитавших. =)
Лично мне любопытно для расширения кругозора. Но таких, как я, вряд ли наберётся очень много.
+1
folone #
Да мне не количество важно :)
На самом деле, я точно знаю, что на хабре есть люди, которые пишут на скале.
0
Quiz #
Есть, но их мало.
Было бы у меня чуть больше свободного времени… эх… =(
+4
kosiakk #
Есть! огромное спасибо за подобрку!
0
webus #
конечно пишут! напрашивается идея создания русского скала комьюнити.
+3
folone #
+1
Ojow #
Мы — есть, да! Почти все ссылки уже читал, могу добавить:
— старенькая уже страничка, но есть весьма полезные моменты: Scala design patterns
— (от создателя MVC, Trygve Reenskaug): The DCI Architecture: A New Vision of Object-Oriented Programming

Спасибо, ждём продолжений.
+8
braintorch #
Ничего, 80% могут и про iВантузы почитать.
+1
vlsergey #
Паттерны ради паттернов — это глупость, ИМХО.

Паттерны, _имхо_, это стандартный способ записи кода, делающего стандартную вещь, который, по недоразумению, можно записать более чем одним способом (включая названия переменных). Переформулируя, паттерн это то, используя что, два человека, имеющие одинаковый _алгоритм_ «на входе» запишут его одинаково (если на одном и том же языке программирования).

Поэтому в приведённом примере единственная «паттернизация» — это договорённость о том, что блок будет command(), а не, скажем, action() или procede().

0
Lazin #
В целом согласен. Однако вы забываете о том, что паттерны — хороший способ описания своих решений. Если у меня есть какой-то класс, то человек, который будет разбираться в моем коде будет вынужден изучить его реализацию. Но если я напишу в комментарии, что это адаптер, выполняющий определенные ф-ии — реализацию можно даже не смотреть. 99% кода должны быть скучными, как справочник по бухгалтерии.
+1
vlsergey #
Для этого класс должен называться, например, HabrahabrAdapter
Это и будет использование паттерна. После этого комментарий можно и не читать.
0
chiaroscuro #
> 99% кода должны быть скучными, как справочник по бухгалтерии.

Скорее, этих 99% кода быть не должно.
0
Lazin #
Ну почему не должно? Просто если выбирать между — хитрым кодом, и скучным/обычным кодом, как правило следует выбирать второй. Хитрый код должен быть только там где это сильно оправдано, а таких мест действительно мало. Поэтому я и написал о том, что 99% должны быть скучными.
+2
folone #
Да ладно. Паттерн — это кусок архитектуры, удачное решение, которое к коду никакого отношения не имеет (кроме того, что его можно с помощью этого кода реализовать). К тому же, паттерны дают разработчикам некоторый «жаргон» для описания архитектуры. Попросите при приёме на работу разных кандидатов на одном и том же языке описать даже не кусок логики («алгоритм», как вы его назвали), а один конкретный паттерн, и вы увидите, насколько разным будет код.
В приведённом примере паттернизацией является тот факт, что последний аргумент — функция, что позволяет клиенту писать более ёмкий и понятный код (нежели если бы эта функция была в первом списке параметров).
+1
folone #
По поводу последнего дополню: что вам приятней читать:
command (expr) {
   block
}

или
command (expr, (_ => block))

?
0
nail84 #
command (expr) {
block
}
0
folone #
bingo!
0
chiaroscuro #
«Монадические паттерны» — прям не знаешь, радоваться или пугаться. :)
+1
corristo #
Обязательно продолжайте цикл статей :)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.