По этому адресу находится статья, где описывается новый подход к программированию, называнный концептно-ориентированным:

http://conceptoriented.com/papers/csjm_05/csjm05.html

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

Для чего это нужно и как это использовать описано в статье, но коротко идея состоит в следующем. Концепты используются вместо классов, т.е. вместо одного класса объекта можно (но не обязательно) определить также класс ссылки. В результате объекты в концептно-ориентированной программе представляются с помощью ссылок в любом желаемом формате. Соответственно, доступ к ним выполняется опосредованно через процедуры, написанные самим програамистом. Например, myObject.myMethod() может вызвать довольно сложные скрытые функции. Мы никогда не знаем где объект находится и как к нему выполняется доступ, когда пользуемся им.

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

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

Вот пример определения концепта:



Этот метод дополняет новую модель данных, которая называется также концептно-ориентированной. Больше информации может быть найдено на сайте:

http://conceptoriented.com

Было бы интересно узнать различные мнения по этому делу.

Материал о том же из Википедии (рус.): http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%...%B5%D0%BB%D1%8C

Это описание концептно-ориентированной модели данных, что видимо не соответствует теме данного форума, но тоже является частью предлагаемого подхода. Концептно-ориентированное программирование основано на тех же общих (филосовских) принципах, но отличается в целях и средствах их осуществления.

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

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

Цель КОП в этом смысле состоит в том, чтобы иметь возможность в самой программе описать эти промежуточные действия (как часть программы, а не среды выполнения). Например, мы можем описать свой формат ссылок. В результате формат ссылки myObject из нашего примера может включать несколько полей, скажем, дату создания объекта, уникальную строку, идентификатор создателя и т.п. Зачем это нужно? Как мы уже отметили, цель состоит в том, чтобы описать промежуточные пространства с их границами и промежуточными действиями, которые будут выполняться неявно во время доступа. Смена парадигмы: теперь мы разрабатываем не конечные объекты, а промежуточные функции (в дополнение к конеченым объектам).

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

--
http://conceptoriented.com

Это сообщение отредактировал(а) savinov - 5.3.2006, 20:10

Вот еще пару статей про КОП:

http://ru.wikipedia.org/wiki/Концептно-ори...рограммирование

http://ru.wikipedia.org/wiki/Концепт_(конц...ограммирование)

Это сообщение отредактировал(а) savinov - 6.3.2006, 13:40

Это, как я понимаю, возможно смоделировать в ООПе, обращаясь к свойствам всегда через методы, которые проверяют, к какому "пространству" относится свойство. (Я бы сформулировал более гибко и многомерно - каким набором признаков обладает свойство.) Аналогичную функцию параллельно выполняет контроль ошибок в операциях - если данные неправильны, вызывается обработчик ошибки. Т.е. концепт - это приписывание дополнительных исполнительских функций данным, чтобы не писать одновременно с ними вызовы процедур. Кроме этого, есть ли что-то принципиально новое?

Основная цель концептно-ориентированного программирования (КОП) состоит в предоставлении средства опосредованного представления и доступа. В ООП мы не знаем как представляются объекта и как к ним осуществляется доступ. В КОП программист может все это явно описать, причем в форме, которая совместима с ООП. Например, одни классы будут представляться целыми числами, другие именем компа и идентификатором и т.д. Объекты в КОП всегда живут внутри иерархии, которая повторяет иерархию концептов (обобщение класса). В ООП как известно объекты теряют информацию об иерархии классов во время выполнения. Доступ в КОП это потенциально сложная процедура, т.е. myAccount.getBalance() может привести к довольно сложным операциям, поскольку это объект может находиться где угодно, например, на Марсе, а доступ к нему будет выполняться с помощью специальных процедур, определенных программистом.

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

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

Вот здесь можно найти простые примеры концептно-ориентированных программ:

http://conceptoriented.com/faqs/cop-faq.html