Парадигмы программирования
Написание программы как кулинарного рецепта - не единственная возможная форма программирования.
На самом деле с самого начала работы в сфере информационных технологий изучались различные высокоуровневые формы программирования, что приводило к реализации. Императивный режим интуитивен, упрощает написание алгоритма и легко переводится на машинный язык, поэтому он наиболее популярен, но повышенная мощь компьютеров позволяет рассматривать компиляторы для языков, которые позволят лучше выражать человеческое мышление.
Высоко - уровень
Программирование на высоком уровне не всегда было само собой разумеющимся. Некоторые оспаривали его полезность. Сам изобретатель компьютера фон Нойманн, когда ему подарили язык Фортрана, получил такую удивительную (в наши дни) реакцию:
Ответ: Цель - приблизить язык программирования к тому, как программист думает, а не думать в зависимости от процессора. А практическое преимущество - сократить количество инструкций для выполнения операции.
Но эволюция языков позволяет идти дальше, и может заключаться в программировании по объектам, в том числе в предоставлении инструкций, облегчающих перевод проблемы в компьютерную обработку, или в представлении реальной деятельности на формальном языке, который может быть обработан компьютером.
Несмотря ни на что, какую бы форму ни приняла программа, ее код всегда придется компилировать на машинном языке, который есть у нее, императивный. Поэтому все режимы возвращаются в императивный режим, и их цель - передать часть задачи программиста компилятору. Чем выше уровень языка, тем больше должен быть разработан компилятор. Мы должны потерять производительность и повысить производительность.
Структурированное программирование
Это ранжирование кода, создание блоков команд, которые не зависят ни от одного другого блока инструкций.
Она была инициирована Никлаусом Виртом в ответ на код BASIC и его инструкции goto, которые склонны производить код «спагетти». Впервые он реализовал её в 1968 году в ALGOL W. Это не помешало гото распространиться на персональных компьютерах 80-х годов. Они знали только язык BASIC, который проще всего реализовать.
Язык Паскаля был создан, чтобы реализовать структурированное программирование и сделать его обязательным. Даже если он оставил место для других языков, принцип структурированного программирования остался приобретенным и стал нормой .
Императив и процедура
Императивный режим такой же, как и тот, который следует при применении рецепта приготовления пищи, поэтому он навязался и широко используется: Череда простых или итеративных операций, которые меняют состояние ингредиентов до окончательного состояния, которое мы ищем. Инструкции изменяют состояние программы через переменные и объекты .
Процедурное планирование является обязательным, но оно добавляет процедуры, которые можно использовать повторно. Иногда проводится различие между двумя парадигмами, но они практически неотличимы: за исключением языков низкого уровня, императивный код всегда содержит процедуры (подпрограммы в BASIC, функции в другом месте) и является процедурным.
Декларативная
Она описывает элементы лечения, которые должны выполняться, не описывая при этом порядок выполнения инструкций по их цепочке. Поэтому в ней нет ни условий, ни структур контроля.
Это подходит для описания интерфейсов, которые ассоциируются с событиями с клавиатуры или мыши.
SQL декларативен так же, как HTML, XML и множество производных диалектов, включая RSS. Регулярные выражения имеют форму, подходящую для поиска и преобразования текста. Модели системы с математической формой являются частью этого, как и логическое программирование.
Но реактивное программирование - единственный вариант, который может подойти для любого вида лечения.
Логика
Это форма декларативного программирования. Она меняет смысл лечения, задавая результат и определяя его с точки зрения утверждения. Работа по подтверждению результатов толкователем, оценивая утверждения, которые влечет за собой заключение, приводит к проведению обработки.
Ориентированная - объекты
Для моделирования было придумано программирование объектов. Она представляет объекты реального мира в виде классов и класса при атрибутах, собственных переменных, представляющих свойства реального объекта, и методов, собственных функций. Объекты программ можно получить, объявив экземпляры класса. Поэтому класс представляет все объекты с одинаковыми атрибутами и методами.
Концепции ПОО были сформулированы в конце 50-х годов (так, за 20 лет до появления Basic, C). Первый язык OO - Симула 67 (язык симуляции). Он имел классы, экземпляры и объекты, наследство, виртуальные методы (которые можно переопределить в унаследованных классах).
Язык Smalltalk, реализованный через несколько лет после того, как Алан Кей был чисто OO. Именно он придумал термин «Программирование ориентированного объекта». Он ставит на первый план концепцию сообщений, рассматривая ход программы как обмен сообщениями между объектами .
Это концепция, которая приобретает новый интерес в 2014 году к WebSocket, о чем позже будет рассказываться об архитектуре клиент-сервер.
Некоторые современные программисты на высокоуровневых языках не видят смысла в предметно-ориентированном программировании (OO) или каких-либо других улучшениях такого рода в своей области - системном программировании. См. Статью о языке C. Возможно, текущие языки OO не подходят для высокоуровневого системного программирования?
Наследование или композиция
Это субпарадигма предметной ориентации. Принцип наследования заключается в определении одного класса как производного другого с новыми атрибутами и методами. Состав заключается в определении черт или миксов, с атрибутами и методами, и их определении (в отличие от интерфейсов), которые можно объединить с характеристиками любого объекта.
Если C++ сначала опирался только на наследство, и это один из тех, кто предлагает множественное наследство. но впоследствии композиция была добавлена вместе с «чертами». Язык Go выбрал композицию в одиночку.
Состав можно считать выше простого наследования, так как он позволяет определять абстрактные классы объектов и объединять их, что позволяет реализовать контексты нескольких пользователей в одной программе. Для этого один модуль заменяется другим, с одним и тем же API, поэтому одни и те же интерфейса, но разные операции. Множественное наследие эквивалентно, но приводит к путанице.
Актеры
Такая конструкция программирования была описана в 1973 году. Он был реализован не как язык, а как расширение других языков. Она похожа на предметную ориентацию с той разницей, что все актеры работают в конкуренции, а не последовательно. Сообщения отправляются между участниками и принимаются асинхронно. Управление сообщениями отделено от управления объектами: каждое сообщение содержит источник и получателя, а runtime поддерживает их и направляет с момента их создания .
Ориентированные события
Операции программы инициируются событиями. Это сообщения от таких устройств, как клавиатура или мышь, или от сенсоров. Runtime отвечает за управление событиями, в то время как программист присоединяет их к таким объектам, как элементы графического интерфейса, например, в JavaScript и HTML.
У большинства языков есть расширение для обработки событий (иногда ошибочно называемое «реактивными расширениями»).
Ориентированные на аспекты
ПОА (АОП на английском языке) стремится облегчить повторное использование кода путем разделения видов использования и соответствующих видов. Для этого объявляются классы и функции, которые могут взаимодействовать с разными процессами. Она используется не в простой программе, а в системе, предназначенной для управления глобальной деятельностью. Каждый аспект изменяет работу системы. Таким образом, один аспект может быть заменен другим, чтобы получить тип обработки, пригодный для решения конкретной проблемы, при сохранении тех же баз данных и классов и функций.
Этот принцип разрабатывается компанией Palo Alto с 1994 года .
Java имеет внешне ориентированное расширение, FacpentJ, датированное 2001 годом .
Функциональная
Функциональный язык описывает обработку как оценку функций, каждая из которых зависит только от своих параметров. Функция не имеет доступа к глобальным переменным, эффект края не виден.
Этот вид эксплуатации является старым и датируется Лиспом (1958), Эрлангом (1986), Хаскеллом (1990). Он никогда не был популярным до появления Скалы (2001), которая смешивает функциональное программирование с другими парадигмами, такими как объекты.
Реактивное программирование
Что такое PR, я подробно описал в статье Реактивное программирование и его реализация. Итак, я возвращаюсь к описанию, которое дал.
В ПР, когда пишется:
a = b + c
Это не означает, что в императивном программировании получается сумма значений b и c, а результат присваивается переменной a. Это означает, что значение a соответствует сумме значений b и c в течение всей функциональности программы. Таким образом, когда b или c будут изменены позже, автоматически будет также. Обновление переменных в зависимости от зависимостей является обязанностью времени выполнения.
Реализация была выполнена INRIA в 1988 году в Reactive-C, препроцессоре на C, который переводит код в императивный код. Существуют расширения для разных языков, но если они не позволяют описать систему с точки зрения взаимодействий, они скорее относятся к программированию по событиям.
Реактивное программирование для программы командной строки позволяет запускать электоральные устройства. Для автоматического обновления переменных на рабочем столе требуется такая панель управления, как электронная таблица. поэтому она уступила место императивному стилю в первые десятилетия IT, Но она стала новым центром интереса программистов с 2010 года, так как хорошо подходит для JavaScript-фреймворков. Язык скриптола поддерживает реактивное программирование, встроенное в императивный код.
Функциональное реактивное программирование
Она направлена на объединение пиара с ПФ и для этого делает последнее менее строгим, позволяя функциям больше зависеть только от их параметров.
Функциональная программа описывается в виде взаимосвязи, как и реактивное программирование, что делает ее реактивной в зависимости от внешних функций.
Тогда функции могут ссылаться на глобальные переменные, но не так, как в императивном режиме, функции пересчитываются при изменении значения этих переменных.
Роли или МНН
Программирование по ролям - идея Trygve Reenskaug , которая разрабатывает эту концепцию на протяжении нескольких десятилетий и считает, что она нашла свое кульминацию в BabyUML. Она хочет сделать акцент на взаимодействии между объектами, а не на результатах, которые может дать каждый.
Рядом с описанием классов описана связь между объектами с помощью наборов методов.
Разница с программированием по аспектам заключается в том, что объекты не изменяются для адаптации к контексту, они адаптируются к контексту, добавляя роль, то есть интерфейс. Можно подумать, что для этого может использоваться сочетание по интерфейсам, реализуемое Go, но автор более амбициозен и хочет, чтобы мы разработали чистый, не зависящий от программы интерфейс для описания системы как комплекса взаимодействий.
В статье Язык контекстного программирования более подробно описывается архитектура PCI, реализующая роли.
Клиент-официант
Серверная клиентская архитектура, поскольку веб-программирование распространяется на локальное программное обеспечение в автономном режиме, а также с использованием веб-технологий на локальном компьютере, становится новым способом разработки программ. Например, Node.js в бэкенде и HTML для описания интерфейса, программа может работать через обмен сообщениями между интерфейсом и бэкендом, или между различными модулями через бэкэнд-сервер. Так работают Advanced Explorer и Light Table. Это дает ему больше возможностей, чем другим издателям, таких как изменение программы в процессе работы.
Можно представить себе реализацию этой архитектуры на языке программирования, при котором обмен сообщениями был бы основой ее работы.
Денис Суро 29 января 2014 года.