Здравствуйте, buriy, Вы писали:

B>>>Фреймы Мински что-ли? Я из этого описания отличий не вижу...

S>>Насколько я понимаю, фреймы задумывались для представления знаний, тогда как КОП это подход к программированию, так что особой связи не вижу (хотя и не могу исключать, что таковая имеется).

B>Ладно, давай тогда по программированию.

B>Во многих динамически-типизированных языках (напр. Python, Ruby, Smalltalk) есть возможность естественным образом делать действия перед вызовом метода объекта и перед использованием атрибута объекта. Во многих главным-образом-статически-типизированных языках есть возможность при необходимости использовать proxy вместо объектов (напр. Java, C#). Делаем вывод, что в большинстве языков уже реализованы возможности концептно-ориентированного программирования, но они просто так не называются. ВОпрос, нужно ли этим возможностям такое громкое название? Или это лишь мелкая фича, не заслуживающая рассмотрения?

Зачатки подхода безусловно существуют. В частности, сильно развиты средства перехвата доступа. Вот чего точно нет:

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

Собственный означает, что я сам определяю его в своей программе для обслуживания своих объектов. Это аналогично введению собственной системы адресации. Например, я не хочу пользоваться почтовым адресом в виде Город-Улица-Дом, а хочу что-то свое, скажем, свою адресацию внутри свой организации. Так же и в программе, зачем мне использовать универсальные ссылки Явы, если я знаю, что объекты какого-то класса живут только 5 минут, занимают не более 10 байт памяти и имеют еще какие-то спец. свойства? Ясно, что нужны особые средства обозначения и управления такими объектами. Можно сделать это вручную, но можно автоматизировать с помощью КОП. Результат: объекты этого (и других выбранных) классов будут использоваться как обычно, т.е. myObject.myMethod(), но на самом деле система позаботится о том, чтобы они обозначались правильными ссылками и правильно доступалсиь.

Прокси имеет два главных недостатка. Во-первых, это никак не решает проблему с произвольным форматом ссылок. Во-вторых, прокси заточен под один целевой класс. В любом случае, прокси знает о целевом классе и его функциях. В результате в программе мы используем непосредственно сам прокси: myProxy.myMethod(). Нам же надо все наоборот: мы хотим использовать целевом объект, а перехватчик должен встревать незаметно для глаза. Вахтер не должен знать, что происходит внутри здание и его функции. Его задача ограничивается функциями проверки, маршрутизации и т.п., а бизнес-логика уже будет выполнена другими объектами внутри здания (которые не должны быть связаны с функциями вахтера).

B>p.s. Похожий вопрос, что нового дает этот подход, уже поднят тов. Voblin'ом в соседней ветке, так что если ответишь там, то здесь можешь не отвечать.

Коротко: мы можем моделировать не только объекты, но их представление с доступом. (ссылки и их функции)

Например, как понимается следующий вызов:

myAccount.getBalance()

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