Концептно-ориентированное программирование
Материал из Википедии — свободной энциклопедии
Концептно-ориентированное программирование это парадигма программирования следующего поколения, которая использует концепт в качестве основной программной конструкции. Одним из основных предположений этого подхода к программированию состоит в том, что любая система может рассматриваться как включающая два типа функций:
- Бизнес-методы (БМ) которые используются явно в исходном коде, и
- Методы представления и доступа (ПД), которые вызываются неявно при использовании бизнес-методов.
Функции ПД пронизывают всю программу и являются двойственным (ортогональными) к бизнес-методам. Другими словами, при использовании БМ путем вызова методов классов, что-то всегда происходит за сценой. Например, если вызывается метод на языке Ява, то, чтобы его выполнить, виртуальная машина должна разрешить ссылку на целевой объект. Далее, когда ссылка Явы разрешена, полученный идентификатор памяти должен быть разрешен в физический адрес в памяти. Эта процедура вложена и пронизывает многие уровни, где выполняются различные функции, например, проверка полномочий, замки, подсчет числа доступа и т.п. Этот уровень функциональности системы скрыт, поскольку его функции выполняются неявно, когда происходит доступ к объектам.
В концептно-ориентированном программировании предполагается, что функции ПД отвечают за значительную часть (и даже большинство) сложности системы. Таким образом, существует потребность в описании этих скрытых функций ПД в качестве неотъемлемой части программы. Важная цель при дизайне этого подхода состоит в сохранении иллюзии мгновенного доступа с одновременным предоставлении средств для описания что собственно происходит неявно за сценой. Например, предположим, что имеется класс A и требуется вызвать его бизнес-метод: A o; o.myMethod();. Идея КОП состоит в том, что объект o может располагаться где угодно в мире, тогда как эта строка кода будет всегда одна и та же. Именно задачей среды (а не программиста) является предоставление соответствующих функций ПД, а компилятор в этом случае должен их неявно активировать. Например, целевой объект o может находиться в основной памяти, где он представляется идентификатором, в памяти виртуальной машины Явы, где он представляется ссылкой в формате Явы, либо на другом компьютере, где он представляется удаленной ссылкой, или даже на Марсе, где он представляется неким глобальным идентификатором. Мы не знаем и нам не нужно знать где собственно хранится объект и как именно к нему происходит доступ для того, чтобы работать с этим объектом путем вызова его БМ.
Для описания такой системы, где два типа функций сосуществуют, новый подход использует концепты в качестве основной программной конструкции. Концепт состоит из одного класса объектов и одного класса ссылок, которые предоставляют средства двух типов функций системы. Идея состоит в том, что концепты используются вместо классов путем описания иерархии концептов, где каждый из них включен в некоторый родительский концепт. Промежуточные концепты предоставляют необходимые функции ПД своим дочерним концептам. Выполнение программы видится как опосредованные представление и доступ к дочерним объектам через их родительские объекты, играющие роль промежуточной среды. Один концепт может пониматься как пространство, и тогда обращения к любым БМ должны проходить через последовательность границ пространства, на каждой из которых автоматически выполняются определенные действия. Целевой БМ это только самый последний шаг в цепочке, тогда как значительная часть функциональности сосредоточена на границах промежуточных пространств. Важным свойством и целью дизайна концептно-ориентированного программирования состоит в том, что этот подход может описать всю цепочку действий (функции ПД), а не только последний шаг (БМ).
В зависимости от родительских концептов, целевой концепт будет представлен тем или иным способом. Например, если известно, что концепт или класс A производит крошечные объекты, которые часто создаются и удаляются, тогда мы могли бы разработать для них специальный контейнер, после чего включить в него концепт A: A in ContainerForTinyObjects {...}. Если позже необходимо будет сделать эти объекты постоянными, тогда целевой концепт может быть включен в соответствующий родительский концепт: A in ContainerForRemoteObjects {...}. Заметим, что эти родительские концепты разрабатываются как неотделимая часть концептно-ориентированной программы. КО программа использует концепты вместо классов и иерархию включения концептов вместо наследования. Разница состоит в том, что объекты представляются посредством ссылок, описываемых в родительских концептах. Доступ к объектам выполняется через методы, которые также определяются в родительских концептах.
