Декларативное программирование пример

5 августа 2020 года

Декларативное программирование может помочь вам быстрее создавать ценность для бизнеса.

5 августа 2020 года


Если вы знакомы с разработкой приложений. Вы, вероятно. Слышали о декларативных языках программирования или декларативной инфраструктуре раньше. Для многих это просто модные словечки. Но декларативные концепции программирования достаточно сильны.

В этом посте мы рассмотрим:

  • Что такое декларативное программирование?
  • Декларативное программирование против императивного программирования
  • Преимущества декларативного программирования
  • Недостатки декларативного программирования

  • Примеры декларативного программирования
  • Декларативная инфраструктура
  • Как декларативная инфраструктура упрощает управление контейнерами

Что такое Декларативное программирование?

Цель декларативного программирования-описать желаемый результат. Не диктуя (напрямую). Как его получить.

Если вы исследовали эту тему раньше, вы, возможно, наткнулись на простые примеры, такие как:

order = sorted(filter(fruit.all(), [is_ripe. On_sale]), by=price)

Затем последовала общая банальность: “Все так просто!” Да. Декларативный стиль иногда может способствовать более удобочитаемому коду. Но эти детали должны откуда—то взяться-часто они абстрагируются в повторно используемые компоненты.

Однако декларативность не является синонимом интуитивности. И последствия декларативного дизайна могут повлиять на гораздо большее. Чем просто читабельность.

В сторону о побочных эффектах

Обычно цитируемый аспект декларативного кода заключается в том. Что он не “производит побочные эффекты”. Которые формально описываются как “ссылочная прозрачностьСсылочный прозрачный код полагается только на вход процедуры при определении выхода. Чтобы программа обладала этим свойством. Вы должны иметь возможность заменить любое выражение его результатом.

В качестве примера ссылочной прозрачности рассмотрим функцию. Которая суммирует два числа. Заданные в качестве входных данных. А затем возвращает их сумму:

итог = добавить(42, 19);

печать(всего); // выход: 61

Если операция “добавить” действительно референциально прозрачна. Мы можем заменить первое утверждение следующим:

итого = 61;

Формально это единственное требование декларативного программирования. Другие свойства либо являются производными от этого. Либо разделяются с императивным программированием. Что делает ссылочную прозрачность основным различием между двумя парадигмами.

Декларативное программирование против Императивное программирование

Различие между “декларативным” и “императивным” может показаться поверхностным или педантичным. Но использование соответствующих приемов в данной ситуации принесет ощутимую пользу. Там, где декларативное программирование предпочитает описание целевого состояния. Императивное программирование детализирует действия. Которые должны быть выполнены для получения этого результата. Давайте рассмотрим это различие более подробно.

Часто декларативное программирование описывается просто как “не императивное”. Что не является особенно точным или полезным определением.

Кроме того, многие объяснения предполагают. Что декларативное программирование описывает “что”. В то время как императивное программирование описывает “как”. Опять же, это может быть интуитивно верно. Но это не дает нам много новой информации. Если читатель уже не знает. Что это значит. Подобно этим определениям. Декларативный стиль программирования опирается на некоторые предварительные знания. Которыми обладают программа. Программист или оба. Возвращаясь к нашему фруктовому примеру выше. Предполагается. Что операции “фильтр” и “сортировка” определены в другом месте. Что означает. Что они должны, по сути. Быть императивно реализованы. По крайней мере. На некотором уровне абстракции.

Чтобы попытаться изобразить это различие более конкретно. Давайте рассмотрим музыкальное произведение. Написанное для фортепиано. В этом случае традиционные ноты могут представлять собой “декларативный код”: мелодия кодируется и передается музыканту с помощью предварительного знания нотной записи. Гипотетическая императивная версия может вместо этого диктовать начальное положение рук музыканта на клавишах. А затем давать последовательность инструкций. На какие пальцы нажимать. Как и когда менять положение рук вверх и вниз по клавишам.

Преимущества декларативного программирования

“Статический” код полагается на некоторые данные (состояние) за пределами входных данных процедуры при определении результата. Вспомните исходное положение рук музыканта в примере с императивным фортепиано. В качестве побочного эффекта запуска он может изменять это состояние. А это означает. Что последующие выполнения могут привести к другому поведению. В качестве примера кода с сохранением состояния рассмотрим функцию. Которая возвращает следующий уникальный идентификатор для новой записи базы данных. Увеличивая счетчик при каждом ее вызове.

Методы декларативного программирования избегают взаимодействия с состоянием везде, где это возможно, сводя к минимуму факторы, которые могут повлиять на поведение части кода; только входные данные функции должны влиять на выходные данные, а не на то. Что происходит в других частях программы (или происходило в прошлом).

Декларативное программирование способствует неизменности. Когда это возможно. То есть состояние объекта не может быть изменено. О неизменных объектах легче рассуждать.

Как только начальное состояние установлено. Оно не изменяется—оно не подвержено побочным эффектам. Совместное использование неизменяемых объектов между потоками исключает возможность изменения данных “из-под” процедуры. То есть условия гонки. Кроме того, эта гарантия может обеспечить существенные преимущества в производительности.

Недостатки декларативного программирования

Избегая зависимостей от внешнего состояния. Декларативный код по своей сути более самодостаточен. Поведение каждого раздела программы определяется только прямыми входными данными; поэтому. Пока “строительные блоки” функционального конвейера понятны. Инженер может следовать локализованным процедурам. Не требуя полного овладения более широким контекстом программы.

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

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

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

Декларативные Языки программирования

Декларативный язык программирования отдает приоритет декларативному стилю над императивными методами. Либо используя синтаксис и языковые особенности. Чтобы сделать предпочтительный стиль естественным. Либо в некоторых случаях даже навязывая предпочтение. Отвергая императивный код. “Чисто функциональные” языки запрещают использование императивных процедур программирования. Которые вызывают побочные эффекты и манипулируют внешним состоянием.

Пример Списка Декларативных языков программирования 

  • Пролог
  • Семейство языков Lisp (Common Lisp, Scheme. Clojure и др.)

  • Хаскелл
  • Миранда
  • Эрланг

Этот список далеко не исчерпывающий. И многие разработчики уже используют преимущества декларативных концепций и методов за пределами этих конкретных декларативных языков программирования. SQL-один из ярких примеров. С которым работали большинство разработчиков приложений. Структура SQL — запроса по своей сути декларативна. Предоставляя описание результирующих данных. Например: создайте все записи. Где мое условие выполнено. Вместо того чтобы диктовать фактическую реализацию запроса (которая будет существенно различаться в разных базах данных). SQL используется для описания результата.

Популярная парадигма Широко используемые инструменты. Такие как Terraform и AWS CloudFormation. Принимают эту конфигурацию в качестве входных данных (а не списка шагов для запуска) и отвечают за согласование желаемого и фактического состояния.

Инфраструктура как (Декларативная) Код

Декларативная инфраструктура использует концепции. Которые мы только что рассмотрели для написания программного обеспечения. И применяет их к инфраструктуре или созданию среды для работы программного обеспечения. Здесь мы можем вернуться к статусному против апатридного.

Если мы полагаемся на состояние системы (сервера, кластера. Базы данных и т. Д.) и что-то выходит из строя. Мы теряем целостность этого состояния и. Скорее всего. Попадаем в беду. Однако, если мы описываем нашу систему безгосударственным образом. Мы действительно ничего не теряем. Если что-то ломается. Вместо этого мы можем воссоздать его в соответствии с заранее определенным

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

С помощью декларативной инфраструктуры мы можем позволить приложению определять. Какие ресурсы ему нужны. В то время как уровень оркестровки управляет тем. Как эти ресурсы подготавливаются. Таким образом. Приложение становится менее связанным со специфическими деталями среды. А это означает. Что разработчики могут сосредоточиться на бизнес-логике.

Контейнеры и декларативное программирование

За последнее десятилетие популярность контейнеров резко возросла. Отчасти благодаря успеху инструментов оркестровки контейнеров. Таких как Kubernetes. Но решения по управлению контейнерами могут быть сложными для внедрения и управления в масштабах предприятия. На самом деле, когда дело доходит до использования и внедрения облачных контейнеров, 65% технологических лидеров сообщают. Что они обратятся к сторонним платформам для управления контейнерами. Те же основные понятия. Которые используются в декларативном программировании. Помогают питать эти решения.

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

Поскольку организации быстро переходят к контейнеризации приложений и внедрению инструментов управления контейнерами. Они могут обнаружить. Что некоторые вещи верны:

  • Существует нехватка талантов: многие команды должны быстро нанимать разработчиков с опытом работы в Kubernetes. Которые пользуются высоким спросом и нехваткой предложения. По оценкам Forbes. Опубликованным в мае 2019 года. К 2027 году в мире будет добавлено более 5 миллионов ИТ-рабочих мест. Согласно исследованиям платформы поиска талантов DICE. Kubernetes входит в топ-2 запрашиваемых навыков из этих 5 миллионов открытых ролей.
  • Установка среды становится намного проще: контейнеры могут быть развернуты из одного файла с управляемым исходным кодом. Содержащего среду. Конфигурацию и спецификации доступа для вашего приложения. Приложения, состоящие из нескольких микросервисов. Каждый из которых использует индивидуальный образ из реестра. Могут быть легко разработаны и развернуты.
  • Ресурсы вашей организации уже перерасходованы. Независимо от того. Какую облачную среду может выбрать команда. Такие ресурсы. Как процессоры. Оборудование. Хранилище и IP-адреса. Как правило. Являются дорогостоящими и пользуются большим спросом. Быстро становится трудно управлять масштабированием вверх и вниз в зависимости от спроса. Поскольку все больше приложений работают на одной и той же инфраструктуре.

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

  • Настройка и управление конфигурацией контейнеров
  • Обеспечение инфраструктуры
  • Балансировка нагрузки

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

В Capital One мы создали собственный контейнерный инструмент. Работающий поверх Kubernetes с учетом декларативной инфраструктуры. Critical Stack-это простая и безопасная платформа оркестровки контейнеров, созданная для того. Чтобы сбалансировать то. Что хотят разработчики. С потребностями нашей организации. Сочетая улучшенное управление и безопасность приложений с более простой оркестровкой и интуитивно понятным пользовательским интерфейсом. Мы можем безопасно и эффективно управлять контейнерами в больших масштабах.


Кайл Трэвис, Ведущий инженер-программист

Кайл Трэвис-ведущий инженер-программист в команде разработки продуктов Critical Stack. Где в настоящее время он сосредоточен на создании инструментов Kubernetes. Расширяющих возможности разработчиков. Он окончил Орегонский университет по специальности Вы можете связаться с ним через LinkedIn (www.linkedin.com/in/kyle-travis) или GitHub (github.com/ktravis)


ЗАЯВЛЕНИЕ О РАСКРЫТИИ ИНФОРМАЦИИ: © 2019 Capital One. Мнения-это мнения отдельного автора. Если не указано иное в этом посте. Capital One не является аффилированным лицом или одобренным ни одной из упомянутых компаний. Все товарные знаки и другая интеллектуальная собственность. Используемая или отображаемая. Являются собственностью их соответствующих владельцев.

Связанный Контент

статья |4 декабря 2019 г.

статья |16 января 2019 года

статья |19 декабря 2018 г.