Книга «Реактивные шаблоны проектирования»

    image Эта книга задумывалась как исчерпывающее руководство по реактивным системам, которое поможет понимать и проектировать их. Поэтому в ней обсуждаются не только сам манифест реактивного программирования, но и причины, которые привели к его появлению. Основная часть книги представляет собой собрание шаблонов проектирования, которые олицетворяют множество аспектов реактивной архитектуры. При этом даются отсылки на углубленный материал для дальнейшего изучения. И хотя представленные шаблоны составляют единое целое, их перечень не полон — он и не может быт быть таковым. Однако общие сведения, содержащиеся в книге, позволят читателю определять, вычленять и развивать новые шаблоны, если это потребуется.

    Для кого эта книга


    Книга создавалась для всех, кто заинтересован в реализации реактивных систем.

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

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

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


    Многие из приведенных решений и большинство исходных проблем не новы. Разделение архитектуры разных компонентов программы является одной из задач информатики с момента ее возникновения и обсуждается в технической литературе со времен публикации знаменитой книги «Шаблоны проектирования»1. По мере проникновения компьютеров в повседневную жизнь программирование стало получать заслуженное внимание со стороны общества и превратилось из искусства, практикуемого учеными, а позже молодыми фанатиками в гаражах, в массовое прикладное ремесло. Рост общего числа компьютерных систем, установленных за последние два десятилетия, привел к формализации проектирования, а заодно определил набор рекомендуемых методик и расширил количество освоенных областей. В 2003 году вышла книга «Шаблоны интеграции корпоративных приложений»2, рассматривающая обмен сообщениями между компонентами и определяющая шаблоны взаимодействия и обработки сообщений, которые, например, реализованы в проекте Apache Camel. Следующий шаг назывался сервис-ориентированной архитектурой (service-oriented architecture, SOA).

    По мере чтения данной главы вам будут встречаться элементы предыдущих стадий, такие как сервисы и ориентированность на передаче сообщений. В связи с этим возникает естественный вопрос: что может предложить эта книга такого, что не было подробно рассмотрено ранее в других изданиях? Особенно интересным выглядит сравнение с определением SOA, которое дается в книге Арнона Ротем-Гал-Оза «Шаблоны SOA» (SOA Patterns. — Manning, 2012): «Сервис-ориентированная архитектура (SOA) — это стиль проектирования для построения систем на основе взаимодействия слабосвязанных, обобщенных и автономных компонентов под названием “сервисы”. Каждый сервис использует для предоставления процессов и поведения контракты, состоящие из сообщений, которые можно обнаружить по заданным адресам (конечным точкам). Поведение сервиса определяется правилами, которые определяются за его пределами. Контракты и сообщения используются внешними компонентами, которые называются потребителями сервисов».

    Данное определение относится к высокоуровневой архитектуре приложения, на что указывает требование обобщенности структуры сервисов. Это вызвано тем, что методика SOA подходит к проблеме с точки зрения бизнес-требований и абстрактной программной архитектуры, что, вне всяких сомнений, полезно. Но, как мы уже утверждали, по техническим причинам сервисы становятся все мельче и требуют, чтобы на смену таким абстракциям, как синхронное блокирующее сетевое взаимодействие, пришло ручное моделирование обмена сообщениями, лежащее в основе базовой системы.

    Управление сложностью


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

    • неотъемлемая, присущая предметной области;
    • побочная, создаваемая исключительно самим решением.

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

    Адекватное решение оставляет на виду неотъемлемую сложность предметной области, позволяя справляться с ней так, как того требует конкретная ситуация, и не обременяет пользователя побочными проблемами, которые являются результатом несоответствия выбранной абстракции и внутренней реализации.

    Это означает, что по мере того, как эволюционирует ваше понимание предметной области (например, вы можете увидеть необходимость в распределенных вычислениях на более низком уровне, чем раньше), вам приходится пересматривать имеющиеся абстракции в плане охвата неотъемлемой и добавления побочной сложности. Результатом будет применение решений, которые могут повлиять на выбор характеристик, нуждающихся в абстракции и вытягивании наружу. Одним из примеров этого является проектирование реактивных сервисов, которое делает устаревшими такие концепции, как синхронное строго согласованное связывание компонентов. Соответствующее понижение уровня абстракции компенсируется определением новых абстракций и шаблонов, что сродни перекладыванию строительных блоков поверх перепланированного фундамента.

    Новый фундамент — это ориентация на обмен сообщениями, и чтобы соорудить поверх него масштабное приложение, нужны подходящие инструменты. Шаблоны, рассмотренные в части III, являются сочетанием комфортных проверенных временем методик, таких как шаблон «предохранитель», и недавно возникших концепций, полученных в результате использования модели акторов. Но шаблон проектирования — это не просто описание прототипа решения, он характеризуется проблемой, которая решается с его помощью, а это более важно. Таким образом, главной задачей данной книги является обсуждение реактивных шаблонов проектирования в свете четырех принципов манифеста реактивного программирования.

    Делаем модели программирования ближе к реальному миру


    Заключительный комментарий по поводу реактивного программирования относится к направлениям, которые уже рассматривались в предыдущих разделах. Вы уже знаете, что желание создавать автономные экземпляры программного обеспечения, которые предоставляют быстрые и надежные услуги своим пользователям, привело к созданию архитектуры, лежащей в основе инкапсулированных, выполняемых независимо друг от друга вычислительных модулей. Отсеки, разделенные переборками, формируют изолированные пространства для сервисов, которые взаимодействуют исключительно с помощью сообщений, выполненных на языке высокого уровня.

    Эти архитектурные ограничения были взяты из реального мира и из нашего общества: люди тоже кооперируются для работы над чем-то масштабным — каждый человек выполняет отдельную задачу самостоятельно, общаясь с коллегами на высокоуровневом языке. Это позволяет визуализировать абстрактные программные концепции с помощью хорошо знакомых, привычных образов. Проектирование можно начать с вопроса: «Как бы я это сделал на примере человеческого коллектива?» Разработка программного обеспечения является чрезвычайно молодой областью в сравнении с организацией труда в обществе на протяжении последнего тысячелетия, но мы можем использовать уже приобретенные знания, чтобы облегчить задачу разбиения систем на модули, совместимые с принципами распределенной автономной реализации.

    Конечно, не следует злоупотреблять антропоморфизмом: такая терминология, как master/slave (дословно «хозяин/раб»), постепенно исчезает из обихода, поскольку при ее интерпретации не всегда учитывается технический контекст. Но даже ответственное использование подобных метафор может придать пикантности потенциально скучной работе: например, компонент, отвечающий за сохранение журнальных записей на диск, можно назвать Scribe (рус. писарь). Реализация этого класса даст вам ощущение того, что вы создаете маленького робота, который будет выполнять ваши команды и с которым можно немного поиграть, — кто-то называет такое занятие написанием тестов, произнося это словосочетание с кислой миной. Реактивное программирование позволяет взглянуть на это с другой стороны и осознать: это весело!

    » Более подробно с книгой можно ознакомиться на сайте издательства
    » Оглавление
    » Отрывок

    Для Хаброжителей скидка 20% по купону — Reactive Design Patterns
    • +11
    • 6,2k
    • 2
    Поделиться публикацией
    Комментарии 2
    • 0
      Сразу оговорюсь, по работе я с реактивным программированием не сталкиваюсь, и это отзыв человека, который просто любит читать «про всякое умное». Так вот, с этой точки зрения «Реактивные шаблоны проектирования» произвели на меня приятное впечатление. Во-первых, понравился доходчивый язык, которым написана книга (но тут, думаю, стоит сказать спасибо и переводчикам). Во-вторых, для меня, как для новичка в предмете, было важно, что обсуждение темы начинается с самых основ: с подробного разбора манифеста реактивного программирования. Причём теория щедро сдобрена практическими и жизненными примерами, отчего не утомляет. Собственно же шаблоны просто демонстрируют, как можно воплотить обсужденные ранее тезисы. Расписываются они подробно, но лично мне понимать код немного мешало то, что я не знакома со Scala. Авторы же всячески котируют фреймворк Akka, хотя, надо отдать им должное, рассказывают и о возможных альтернативах. Ещё один плюс — это то, что в книге не забыли рассказать о тестировании реактивных приложений (само собой, с примерами). Ну и стало приятным сюрпризом, что кроме повышения общей эрудиции, я вынесла из «Шаблонов» несколько моментов, полезных для моей работы: например, идеи «Наблюдателя» и «Простого компонента». Так что я считаю, что не зря потратила время на эту книгу.
      • 0
        Ты серьезно? Понравилась книга? Ее невозможно читать на русском.На каждой следующей странице ты забываешь о чем читал на предыдущей.
        Расписываются они подробно, но лично мне понимать код немного мешало то, что я не знакома со Scala.

        Примеры там на разных языках.Бессмысленно толкать это как «ещеоднакнигапоscala».

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

      Самое читаемое