Основная цель состоит в предоставлении средств опосредованного представления и доступа к объектам. Это означает, что программист имеет возможность описать не только структуру и функции объектов, но также структуру и функции ссылок, которые используются для их представления. В КОП ссылки являются таким же полноценным элементом программы, как и объекты.
Для описания объектов и ссылок предлагается новая конструкция, называемая концептом. Концепт это пара классов, состоящая из одного класса объектов и одного класса ссылок. Концепт без класса ссылки это самый обычный класс из ООП. Экземпляры класса объектов называются объектами и передаются только по ссылке (формат которой в КОП может определяться программистом). Экземпляры класса ссылок передаются только по значению и предназначены для представления объектов. В концептно-ориентированной программе концепты используются вместо классов.
Концепты связаны отношением включения, которое обобщает наследование. Объект концепта представляется ссылками его базового концепта, В общем случае объект представляется последовательностью ссылок всех своих базовых концептов. Это то же самое, что и иерархическая адресация, например, почтовые адреса. Во время выполнения объекты живут внутри иерархии, т.е. иерархии существует не только во время компиляции, но и сохраняется и поддерживается во время выполнения. В контексте каждого объекта может существовать множество дочерних объектов. В этом смысле каждый объект работает как контейнер или жизненное пространство для внутренних объектов (за которые он в ответе).
Зачем это нужно? Делается общее предположение, объекты живут в структурированном пространстве, разделенные границами. Доступ в этом случае всегда опосредован, т.е. прямого доступа не существует. Чтобы достать объект, скажем, выполнить его метод, необходимо пересечь промежуточные границы. На этих границах в процессе доступа выполняется множество важных и полезных функций. Задачей программиста в этом случае (в КОП) является описание того, как объекты представляются, и что будет происходить при доступе к ним.
Здравствуйте, savinov, Вы писали:
S>Концепты связаны отношением включения, которое обобщает наследование. Объект концепта представляется ссылками его базового концепта, В общем случае объект представляется последовательностью ссылок всех своих базовых концептов. Это то же самое, что и иерархическая адресация, например, почтовые адреса. Во время выполнения объекты живут внутри иерархии, т.е. иерархии существует не только во время компиляции, но и сохраняется и поддерживается во время выполнения. В контексте каждого объекта может существовать множество дочерних объектов. В этом смысле каждый объект работает как контейнер или жизненное пространство для внутренних объектов (за которые он в ответе).
S>Зачем это нужно? Делается общее предположение, объекты живут в структурированном пространстве, разделенные границами. Доступ в этом случае всегда опосредован, т.е. прямого доступа не существует. Чтобы достать объект, скажем, выполнить его метод, необходимо пересечь промежуточные границы. На этих границах в процессе доступа выполняется множество важных и полезных функций. Задачей программиста в этом случае (в КОП) является описание того, как объекты представляются, и что будет происходить при доступе к ним.
Фреймы Мински что-ли? Я из этого описания отличий не вижу...
Здравствуйте, buriy, Вы писали:
B>Здравствуйте, savinov, Вы писали:
S>>Концепты связаны отношением включения, которое обобщает наследование. Объект концепта представляется ссылками его базового концепта, В общем случае объект представляется последовательностью ссылок всех своих базовых концептов. Это то же самое, что и иерархическая адресация, например, почтовые адреса. Во время выполнения объекты живут внутри иерархии, т.е. иерархии существует не только во время компиляции, но и сохраняется и поддерживается во время выполнения. В контексте каждого объекта может существовать множество дочерних объектов. В этом смысле каждый объект работает как контейнер или жизненное пространство для внутренних объектов (за которые он в ответе).
S>>Зачем это нужно? Делается общее предположение, объекты живут в структурированном пространстве, разделенные границами. Доступ в этом случае всегда опосредован, т.е. прямого доступа не существует. Чтобы достать объект, скажем, выполнить его метод, необходимо пересечь промежуточные границы. На этих границах в процессе доступа выполняется множество важных и полезных функций. Задачей программиста в этом случае (в КОП) является описание того, как объекты представляются, и что будет происходить при доступе к ним.
B>Фреймы Мински что-ли? Я из этого описания отличий не вижу...
Насколько я понимаю, фреймы задумывались для представления знаний, тогда как КОП это подход к программированию, так что особой связи не вижу (хотя и не могу исключать, что таковая имеется).
В статье явным образом не описано, для решения какой проблемы предназначен этот новый подход.
В частности, модульное программирование было придумано для упрощения разработки за счёт разбивки программного текста на модули. ООП — для упрощения моделирования поведения объектов реального мира (в котором, как утветждается, всё является объектами), АОП — для упрощения добавления "сквозной" функциональности.
Всё-таки, для чего предназначен КОП? Для "предоставления средств опосредованного представления и доступа к объектам"? Извините, но мне пока непонятно, зачем мне в принципе может потребоваться опосредованный доступ.
Думаю, прежде, чем предлагать решение проблемы, имело бы смысл эту проблему обозначить. Может быть, Виндовс совсем бы не глючил и не тормозил, если бы он был написан с использованием опосредованного доступа к объектам Может быть, возможность "вклиниться" в оператор разыменования — это именно то, чего мне так не хватало?
B>>Фреймы Мински что-ли? Я из этого описания отличий не вижу...
S>Насколько я понимаю, фреймы задумывались для представления знаний, тогда как КОП это подход к программированию, так что особой связи не вижу (хотя и не могу исключать, что таковая имеется).
Ладно, давай тогда по программированию.
Во многих динамически-типизированных языках (напр. Python, Ruby, Smalltalk) есть возможность естественным образом делать действия перед вызовом метода объекта и перед использованием атрибута объекта. Во многих главным-образом-статически-типизированных языках есть возможность при необходимости использовать proxy вместо объектов (напр. Java, C#). Делаем вывод, что в большинстве языков уже реализованы возможности концептно-ориентированного программирования, но они просто так не называются. ВОпрос, нужно ли этим возможностям такое громкое название? Или это лишь мелкая фича, не заслуживающая рассмотрения?
p.s. Похожий вопрос, что нового дает этот подход, уже поднят тов. Voblin'ом в соседней ветке, так что если ответишь там, то здесь можешь не отвечать.
Здравствуйте, Voblin, Вы писали:
V>Здравствуйте, savinov, Вы писали:
S>>Неформальное введение в концептно-ориентированное программирование S>>[list] S>> HTML: http://conceptoriented.com/papers/CopInformalIntroduction-ru.html
V>В статье явным образом не описано, для решения какой проблемы предназначен этот новый подход.
V>В частности, модульное программирование было придумано для упрощения разработки за счёт разбивки программного текста на модули. ООП — для упрощения моделирования поведения объектов реального мира (в котором, как утветждается, всё является объектами), АОП — для упрощения добавления "сквозной" функциональности.
V>Всё-таки, для чего предназначен КОП? Для "предоставления средств опосредованного представления и доступа к объектам"? Извините, но мне пока непонятно, зачем мне в принципе может потребоваться опосредованный доступ.
Дело не в том, может ли опосредованный доступ понадобится или нет. А в том, что любой доступ всегда предполагается опосредованным. Другими словами, просто так достать объект невозможно, поскольку он представлен каким-то куском данных, а значит, кто-то где-то должен знать, как эти данные интерпретировать и использовать для перемещения запроса к объекту. Соответственно, вопрос состоит в том, можем ли мы из программы контролировать как представляются наши объекты и как к них осуществляется доступ. Я таких языков не знаю (хотя может они и есть).
Наверное, с тезисом, что прямого доступа не существует по определению никто спорить не будет. Тогда просто необходимо прикинуть, действительно ли это так важно. Ведь до сих пор эти задачи как-то решались (вручную). Но в этом плане сложно кого-то убедить, и каждый решает сам за себя. В КОП предполагаетя, что описание средств представления и доступа к объектам не менее важно, чем описание самих объектов. Вся программа это два мира: мир объектов и мир ссылок.
V>Думаю, прежде, чем предлагать решение проблемы, имело бы смысл эту проблему обозначить.
В простейшем виде проблема формулируется очень просто: опишите с помощью вашего любимого языка программирования свой собственный формат ссылок и используйте для пары разных классов так, чтобы этой подмены не было видно.
V>Может быть, Виндовс совсем бы не глючил и не тормозил, если бы он был написан с использованием опосредованного доступа к объектам Может быть, возможность "вклиниться" в оператор разыменования — это именно то, чего мне так не хватало?
А он и написан с помощью средств опосредованного доступа, поскольку в практически любой более или менее сложной программе надо сразу думать как будут представляться объекты и о логике доступа к ним. Далее это можно реализовать вручную, а можно как-то автоматизировать. КОП как раз и предлагает такую автоматизацию. Например, когда строят дом, то в нем делают дверь, а там сажают вахтера и нагружают его определенными полномочиями. Теперь просто так никто туда не войдет, причем независимо от цели (т.е. от вызванного целевого метода). То же самое с объектами. Я хочу контролировать доступ к объектам, чтобы никто не вломился на мой комп, в мой файл или еще куда-то. Обычно для этого при каждом доступе в 1000 мест в программе ставят проверки, но в 1001 месте забывают с печальными последствиями. В КОП поступают иначе. Мы просто вкладываем целевой класс в какой-то концепт, а далее его объекты будут представляться как нужно и доступаться как нужно. Т.е. у нас появляется вахтер, который знает, как интерпретировать ссылки и что делать при попытке доступа. Преимущество: мы используем объекты как обычно и не должны знать об этих деталях, но при этом гарантируется, что любой доступ находится под принудительным контролем.
Здравствуйте, buriy, Вы писали:
B>>>Фреймы Мински что-ли? Я из этого описания отличий не вижу...
S>>Насколько я понимаю, фреймы задумывались для представления знаний, тогда как КОП это подход к программированию, так что особой связи не вижу (хотя и не могу исключать, что таковая имеется).
B>Ладно, давай тогда по программированию.
B>Во многих динамически-типизированных языках (напр. Python, Ruby, Smalltalk) есть возможность естественным образом делать действия перед вызовом метода объекта и перед использованием атрибута объекта. Во многих главным-образом-статически-типизированных языках есть возможность при необходимости использовать proxy вместо объектов (напр. Java, C#). Делаем вывод, что в большинстве языков уже реализованы возможности концептно-ориентированного программирования, но они просто так не называются. ВОпрос, нужно ли этим возможностям такое громкое название? Или это лишь мелкая фича, не заслуживающая рассмотрения?
Зачатки подхода безусловно существуют. В частности, сильно развиты средства перехвата доступа. Вот чего точно нет:
Определение собственного формата ссылок, который далее приписывается для использования разными целевыми классами объектов с сохранением прозрачности доступа.
Собственный означает, что я сам определяю его в своей программе для обслуживания своих объектов. Это аналогично введению собственной системы адресации. Например, я не хочу пользоваться почтовым адресом в виде Город-Улица-Дом, а хочу что-то свое, скажем, свою адресацию внутри свой организации. Так же и в программе, зачем мне использовать универсальные ссылки Явы, если я знаю, что объекты какого-то класса живут только 5 минут, занимают не более 10 байт памяти и имеют еще какие-то спец. свойства? Ясно, что нужны особые средства обозначения и управления такими объектами. Можно сделать это вручную, но можно автоматизировать с помощью КОП. Результат: объекты этого (и других выбранных) классов будут использоваться как обычно, т.е. myObject.myMethod(), но на самом деле система позаботится о том, чтобы они обозначались правильными ссылками и правильно доступалсиь.
Прокси имеет два главных недостатка. Во-первых, это никак не решает проблему с произвольным форматом ссылок. Во-вторых, прокси заточен под один целевой класс. В любом случае, прокси знает о целевом классе и его функциях. В результате в программе мы используем непосредственно сам прокси: myProxy.myMethod(). Нам же надо все наоборот: мы хотим использовать целевом объект, а перехватчик должен встревать незаметно для глаза. Вахтер не должен знать, что происходит внутри здание и его функции. Его задача ограничивается функциями проверки, маршрутизации и т.п., а бизнес-логика уже будет выполнена другими объектами внутри здания (которые не должны быть связаны с функциями вахтера).
B>p.s. Похожий вопрос, что нового дает этот подход, уже поднят тов. Voblin'ом в соседней ветке, так что если ответишь там, то здесь можешь не отвечать.
Коротко: мы можем моделировать не только объекты, но их представление с доступом. (ссылки и их функции)
Например, как понимается следующий вызов:
myAccount.getBalance()
Обычно предполагается, что просто происходит вызов метода. Просто здесь означает как раз непосредственный (прямой) доступ к объекту. В КОП это не так. Ссылка myAccount вполне может быть толстой и включать кучу информации о реальном расположении объекта. В конце концов, кто сказал, что этот счет находится на моем компе в куче? Может быть это счет марсианина в марсианском банке на Марсе. Но с другой стороны, мне в общем, безразлично, чей это счет и где он находится, поскольку я хочу просто получить остаток. Соответственно, в КОП этот вызов может означать кучу промежуточных (автоматически выполненных) действий, связанных с доступом на Марс. Но суть в том, что внешне выглядит это как обычный метод, т.е. все эти детали эффективно скрыты. Кроме того, этот же механизм доступа на Марс я могу использовать и для других классов, поскольку он разрабатывается независимо от того, кого обслуживает. Действительно, космическому кораблю должно быть без разницы кого везти на Марс. Ну и еще одно свойство. Мы по-прежнему используем сам целевой объект, а не его заместителя (как в прокси).
Здравствуйте, savinov, Вы писали:
S>...Т.е. у нас появляется вахтер, который знает, как интерпретировать ссылки и что делать при попытке доступа. Преимущество: мы используем объекты как обычно и не должны знать об этих деталях, но при этом гарантируется, что любой доступ находится под принудительным контролем.
И?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, savinov, Вы писали:
E>>Очень много там всего написано и вообще складывается впечатление, что жизнь в "концептно-ориентированном программировании" бьет ключем. А реально это где-нибудь воплощено? Так сказать "в железе", в каких-нибудь языках, инструментах?
S>Нет не воплощено. И планов таковых нет. А зачем собственно воплощать? От этого только все хуже станет.
Так в чем смысл?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, savinov, Вы писали:
S>Коротко: мы можем моделировать не только объекты, но их представление с доступом. (ссылки и их функции)
S>Например, как понимается следующий вызов: S>
myAccount.getBalance()
S>... S>Соответственно, в КОП этот вызов может означать кучу промежуточных (автоматически выполненных) действий, связанных с доступом на Марс. Но суть в том, что внешне выглядит это как обычный метод, т.е. все эти детали эффективно скрыты.
Но это же тот самый прокси, который описан в GoF и знаком многим тысячам программистов!!! И зачем это называть новой парадигмой программирования?
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, savinov, Вы писали:
E>>>Очень много там всего написано и вообще складывается впечатление, что жизнь в "концептно-ориентированном программировании" бьет ключем. А реально это где-нибудь воплощено? Так сказать "в железе", в каких-нибудь языках, инструментах?
S>>Нет не воплощено. И планов таковых нет. А зачем собственно воплощать? От этого только все хуже станет.
E>Так в чем смысл?
Я не знаю. У каждого свой. Некоторые говорят, что смысла вообще нет, а есть секс, и в этом весь секс Ну а если серьезно, то конечно реализовать это было бы интересно, но просто всему свое время и для всего свои люди. У меня есть документ с дизайном и спецификацией языка, но для реализации еще рано. Есть ряд проблем, которые надо решить, ну и конечно нужны ресурсы. В общем, это совершено другая задача и для нее нужно свое, время свои люди и спрос.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, savinov, Вы писали:
S>>Нет не воплощено. И планов таковых нет. А зачем собственно воплощать? От этого только все хуже станет.
FDS> Ответ достойный форума "философия программирования". Для чего же тогда вы тогда эту тему вытащили, если только хуже станет?
Ну как для чего? С целью информирования. Мало ли, может кому-то понравится, и он захочет поковыряться в этом. Ну или где-то есть что-то подобное. В общем, без всякой задней мысли.
Здравствуйте, savinov, Вы писали:
S>Дело не в том, может ли опосредованный доступ понадобится или нет. А в том, что любой доступ всегда предполагается опосредованным. Другими словами, просто так достать объект невозможно, поскольку он представлен каким-то куском данных, а значит, кто-то где-то должен знать, как эти данные интерпретировать и использовать для перемещения запроса к объекту.
В классике предполагается, что каждый объект характеризуется OID и доступ к его внутренностям идёт после того, как этот самый объект по этому самому OID получен. Если мы говорим об экземплярах класса в C++, то адрес в памяти и является этим самым OID. Иногда, конечно, это бывает не удобно. Классический пример — программы, работающие с базой данных, где, записи, представляющие объекты, как правило уже имеют свой OID (первичный ключ).
S>В КОП предполагаетя, что описание средств представления и доступа к объектам не менее важно, чем описание самих объектов. Вся программа это два мира: мир объектов и мир ссылок.
До сих пор я думал, что вся программа — это алгоритмы и структуры данных (с) Н.Вирт
S>В простейшем виде проблема формулируется очень просто: опишите с помощью вашего любимого языка программирования свой собственный формат ссылок и используйте для пары разных классов так, чтобы этой подмены не было видно.
Всё же, всё же... Зачем мне это может понадобиться? Я даже более-менее подходящий пример придумать не могу!
V>>Может быть, Виндовс совсем бы не глючил и не тормозил, если бы он был написан с использованием опосредованного доступа к объектам Может быть, возможность "вклиниться" в оператор разыменования — это именно то, чего мне так не хватало?
S>А он и написан с помощью средств опосредованного доступа, поскольку в практически любой более или менее сложной программе надо сразу думать как будут представляться объекты и о логике доступа к ним. Далее это можно реализовать вручную, а можно как-то автоматизировать. КОП как раз и предлагает такую автоматизацию.
Мне больше нравится такая автоматизация:
Set xls = CreateObject("Excel.Application")
wb = xls.Workbooks.Open"C:\MyFile.xls"
И всем (и особенно мне) от этого ХОРОШО
S>Т.е. у нас появляется вахтер, который знает, как интерпретировать ссылки и что делать при попытке доступа. Преимущество: мы используем объекты как обычно и не должны знать об этих деталях, но при этом гарантируется, что любой доступ находится под принудительным контролем.
Это не вахтёр, а прямо профессор какой-то! Он не только досконально знает всё, что происходит в доме, но и знает всю подноготную о тех, кто в принципе туда может войти.
Здравствуйте, Voblin, Вы писали:
V>Здравствуйте, savinov, Вы писали:
S>>Коротко: мы можем моделировать не только объекты, но их представление с доступом. (ссылки и их функции)
S>>Например, как понимается следующий вызов: S>>
myAccount.getBalance()
S>>... S>>Соответственно, в КОП этот вызов может означать кучу промежуточных (автоматически выполненных) действий, связанных с доступом на Марс. Но суть в том, что внешне выглядит это как обычный метод, т.е. все эти детали эффективно скрыты. V>Но это же тот самый прокси, который описан в GoF и знаком многим тысячам программистов!!! И зачем это называть новой парадигмой программирования?
Я здесь прокси в упор не вижу. Я уже отметил и в статье и в предыдущих постах, что с помощью прокси это нельзя сделать по следующим причинам:
Невозможно описать свой формат ссылок. Вы можете описать промежуточный объект, который является объектом, а не ссылкой, а потому сам имеет какую-то ссылку и с ним возникают те же проблемы, что и с обычными объектами.
Прокси заточен под целевой класс, т.е. он явно о нем знает и не может без него существовать. Т.е. первым мы разрабатываем целевой класс (поскольку ему не нужен прокси -- он о нем ничего не знает), а потом уже прокси. Одно очень паршивое следствие состоит в том, что при каждом изменении целевого класса необходимо следить за прокси (откуда ошибки).
Нельзя использовать один прокси для многих целевых классов. Например, мы хотим разработать прокси ProxyForMarsObjects, а затем использовать его для доступа к объектам на Марсе, имеющих самый разный класс, который заранее не известен. Как это сделать? Я такого способа не знаю. Если знаете, то опишите, пожалуйста (а также см. п.1).
Ну и в программе мы хотим использовать непосредственно целевые объекты, например, myAccount.getBalance(), тогда как в прокси мы вынуждены работать с посредником: myAccountProxy.getBalance(). Чувствуете разницу? Я ведь знать не хочу сколько и какие там есть посредники. Я хочу иметь ссылку на счет и получить баланс. А прокси предлагает мне использовать какой-то другой объект. А вдруг в будущем этот счет будет представляться по-другому? Тогда в прокси-варианте я должен буду по всей программе поменять MarsProxy на LunaProxy. А в КОП я всегда работаю с целевым классов независимо от способа представления.
Разберитесь, пожалуйста, в этом списке. Он очень важен. Даже если Вам не нравится КОП, то необходимо понимать принципы и недостатки прокси. В каком-то смысле прокси это весьма кривой способ реализовать опосредование с помощью обычных языков программирования. (Я уже не говорю о том, что наличие большого числа паттернов есть признак кризиса в теории.)
Здравствуйте, savinov, Вы писали:
S>Ну как для чего? С целью информирования. Мало ли, может кому-то понравится, и он захочет поковыряться в этом. Ну или где-то есть что-то подобное. В общем, без всякой задней мысли.
Дедушка Фрейд посмеялся бы от души над этой фразой и по форме, и по содержанию.
А если серьёзно, то без всякой задней мысли даже комар не кусает. Если есть идея сделать тему диссертабельной, то рекомендуется сразу задуматься над разделами "Актуальность темы исследования", "Степень научной разработанности проблемы" и "Научная новизна и практическая значимость".
Пока нет чётко сформулированного ответа на вопрос "А зачем, собственно, всё это великолепие нужно для построения светлого коммуни... тьфу! постиндустриального будущего?", не стоит даже пытаться парить мозги уважаемым членам диссертационного совета (или как он там нынче называется?). Съедят и даже косточками не подавятся. И, по-правде сказать, будут правы!
Здравствуйте, Voblin, Вы писали:
V>Здравствуйте, savinov, Вы писали:
S>>Дело не в том, может ли опосредованный доступ понадобится или нет. А в том, что любой доступ всегда предполагается опосредованным. Другими словами, просто так достать объект невозможно, поскольку он представлен каким-то куском данных, а значит, кто-то где-то должен знать, как эти данные интерпретировать и использовать для перемещения запроса к объекту. V>В классике предполагается, что каждый объект характеризуется OID и доступ к его внутренностям идёт после того, как этот самый объект по этому самому OID получен. Если мы говорим об экземплярах класса в C++, то адрес в памяти и является этим самым OID. Иногда, конечно, это бывает не удобно. Классический пример — программы, работающие с базой данных, где, записи, представляющие объекты, как правило уже имеют свой OID (первичный ключ).
Т.е. происходит что-то вроде этого:
Lock(memHandle);
mem =Resolve(memHandle);
mem->myMethod();
Unlock(memHandle);
Такой подход имеет следующие недостатки. Один и тот же код повторяется по всей программе (а что если что-то изменится в последовательности доступа). Я вовсе не хочу заниматься какими-то вспомогательными процедурами, а просто хочу вызвать метод по ссылке. Зачем такие сложности. Ну и кроме того, получение разрешенной ссылки в контекст, где она используется это очень плохо (небезопасно). Внутреннее представление должно храниться и использоваться внутри, а извне надо использовать внешнее представление. В КОП это выглядело бы так:
memHandle->myMethod();
Преимущества. Мы просто применяем метод к ссылке. Внутренний идентификатор (адрес в памяти) не попадает к нам, и мы не можем ничего испортить. Всегда можно изменить механизм доступа без изменения того, где он используется. Например, можно добавить начало и конец транзакции.
S>>В КОП предполагаетя, что описание средств представления и доступа к объектам не менее важно, чем описание самих объектов. Вся программа это два мира: мир объектов и мир ссылок. V>До сих пор я думал, что вся программа — это алгоритмы и структуры данных (с) Н.Вирт
Так можно до Аристотеля добраться Почему бы не определить программу на компьютере как организованный набор атомов? Общее определение – зато никто не докопается.
S>>В простейшем виде проблема формулируется очень просто: опишите с помощью вашего любимого языка программирования свой собственный формат ссылок и используйте для пары разных классов так, чтобы этой подмены не было видно. V>Всё же, всё же... Зачем мне это может понадобиться? Я даже более-менее подходящий пример придумать не могу!
Вы уже описали такой пример в начале этого поста. Пусть ваши объекты хранятся в БД и имеют ключ в качестве идентификатора. Проблема: вызвать метод можно только по системной ссылке, тогда в наличии имеется только первичный ключ. Тут-то и поможет КОП. Вы описываете класс ссылки, который хранит этот самый ключ. А далее он используется вместо системной ссылки. Например,
myAccount.getBalance();
Кто сказал, что этот объект в памяти или в БД? Это м.б. вовсе не так, поскольку из этой строки это неизвестно. Способ представления объектов класса описывается в самом классе, т.е. в классе Account. Другими словами, мы объявляем в классе Account, что его объекты будут представляться по-особому (нашими ссылками в виде ключа из БД), а после этого каждый доступ окружается в промежуточный метод (который берется из класса ссылки). Этот метод загружает запись, размещает ее в памяти, после чего делает то, что вызывает целевой метод.
V>>>Может быть, Виндовс совсем бы не глючил и не тормозил, если бы он был написан с использованием опосредованного доступа к объектам Может быть, возможность "вклиниться" в оператор разыменования — это именно то, чего мне так не хватало?
S>>А он и написан с помощью средств опосредованного доступа, поскольку в практически любой более или менее сложной программе надо сразу думать как будут представляться объекты и о логике доступа к ним. Далее это можно реализовать вручную, а можно как-то автоматизировать. КОП как раз и предлагает такую автоматизацию. V>Мне больше нравится такая автоматизация: V>
V> Set xls = CreateObject("Excel.Application")
V> wb = xls.Workbooks.Open"C:\MyFile.xls"
V>
V>И всем (и особенно мне) от этого ХОРОШО
Хорошо только до определенного момента (обычно это проходит для малых или средних программ). А что, если этот объект должен находиться в БД? А если он д.б. на другом компе? А если он слишком большой для памяти? А если он слишком мелкий и их очень много? А если им может пользоваться только один процесс? Этот список бесконечен и для всех этих случаев надо писать свой контейнер, а потом вручную управлять объектами в нем. В КОП мы используем объекты точно так, как в этом примере, но при этом они могут находиться где угодно и доступ осуществляться как угодно (что описывается в данной программе).
S>>Т.е. у нас появляется вахтер, который знает, как интерпретировать ссылки и что делать при попытке доступа. Преимущество: мы используем объекты как обычно и не должны знать об этих деталях, но при этом гарантируется, что любой доступ находится под принудительным контролем. V>Это не вахтёр, а прямо профессор какой-то! Он не только досконально знает всё, что происходит в доме, но и знает всю подноготную о тех, кто в принципе туда может войти.
V>А, может быть, не вахтёр, а начальник тюрьмы?
Это государство, т.е., по определению классика, инструмент насилия. В зависимости от того, где объект родился и живет, к нему применяются разные законы. В частности, разные средства обозначения, разный жизненный цикл, разную степень открытости, разное наказание, разные ресурсы и т.п. Как раз на построение такого государства объектов и нацелено КОП. Мы описываем его структуру, законы, границы и т.п. И все это может функционировать сам по себе без объектов.
Здравствуйте, savinov, Вы писали:
S> S> Невозможно описать свой формат ссылок.
Не правда! Прокси может при своей инициализации получить что-то вроде такого:
CAbstractProxy myBalance = new CAbstractProxy("Balance", "MarsComBank", "V.Pupkin");
Сладкая парочка "MarsComBank" и "V.Pupkin" — это и есть совсем новый формат ссылки! S> Прокси заточен под целевой класс, т.е. он явно о нем знает и не может без него существовать. Т.е. первым мы разрабатываем целевой класс (поскольку ему не нужен прокси -- он о нем ничего не знает), а потом уже прокси. Одно очень паршивое следствие состоит в том, что при каждом изменении целевого класса необходимо следить за прокси (откуда ошибки).
Или поручить эту задачу компилятору S> Нельзя использовать один прокси для многих целевых классов. Например, мы хотим разработать прокси ProxyForMarsObjects, а затем использовать его для доступа к объектам на Марсе, имеющих самый разный класс, который заранее не известен. Как это сделать? Я такого способа не знаю. Если знаете, то опишите, пожалуйста (а также см. п.1).
Ну, абстрагироваться от источника данных — это довольно легко. Помнится, ещё лет шесть-семь назад я написал прогу, которая в штатном режиме работала с SQL-сервером, а когда он оказывался недоступным (модем выключили), со вздохом лезла в локальный DBF-кэш. Что характерно, основная логика программы даже не догадывалась, что вместо сиськи теперь у неё соска. И всё это безо всяких КОП. И даже без Design Patterns. На старом добром Дельфи. S> Ну и в программе мы хотим использовать непосредственно целевые объекты, например, myAccount.getBalance(), тогда как в прокси мы вынуждены работать с посредником: myAccountProxy.getBalance(). Чувствуете разницу?
Чувствую. И особенно почувствуют те, кто будет дорабатывать и обезглючивать мою программу. Если в "нормальной" программе глючит myAccount.getBalance(), то я открываю исходник этого самого myAccount.getBalance() и ищу багу там. Но если где-то рядышком болтается ещё куча каких-то непонятных личностей, которые как им заблагорассудится перехватывают вызовы до, после, а также вместо отработки собственно "тела" getBalance(), то я просто сойду с ума! S>
S>Я уже не говорю о том, что наличие большого числа паттернов есть признак кризиса в теории. Согласен
Может быть, возможность "вклиниться" в оператор разыменования — это именно то, чего мне так не хватало?
Ответ достойный форума "философия программирования". Для чего же тогда вы тогда эту тему вытащили, если только хуже станет?
(с) Н.Вирт
