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

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

E>>>Очень много там всего написано и вообще складывается впечатление, что жизнь в "концептно-ориентированном программировании" бьет ключем. А реально это где-нибудь воплощено? Так сказать "в железе", в каких-нибудь языках, инструментах?

S>>Нет не воплощено. И планов таковых нет. А зачем собственно воплощать? От этого только все хуже станет.

E>Так в чем смысл?
В диссере...

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

S>>>Нет не воплощено. И планов таковых нет. А зачем собственно воплощать? От этого только все хуже станет.

E>>Так в чем смысл?
LVV>В диссере...

А что сейчас для защиты в области информатики внедрения уже не нужны?

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


S>Т.е. происходит что-то вроде этого:

S>

S>Lock(memHandle); 
S>mem =Resolve(memHandle);
mem->>myMethod(); 
S>Unlock(memHandle);
S>

S>Такой подход имеет следующие недостатки. Один и тот же код повторяется по всей программе (а что если что-то изменится в последовательности доступа). Я вовсе не хочу заниматься какими-то вспомогательными процедурами, а просто хочу вызвать метод по ссылке. Зачем такие сложности. Ну и кроме того, получение разрешенной ссылки в контекст, где она используется это очень плохо (небезопасно). Внутреннее представление должно храниться и использоваться внутри, а извне надо использовать внешнее представление. В КОП это выглядело бы так:
S>

S>memHandle->myMethod(); 
S>

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

Может стоит познакомится с динамическими языками? Там подобные перехваты легко реализуются.

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

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

S>>

Невозможно описать свой формат ссылок.
V>Не правда! Прокси может при своей инициализации получить что-то вроде такого:
V>

V>CAbstractProxy myBalance = new CAbstractProxy("Balance", "MarsComBank", "V.Pupkin");
V>

V>Сладкая парочка "MarsComBank" и "V.Pupkin" — это и есть совсем новый формат ссылки!

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

Далее, в этом примере мы использовали некий класс CAbstractProxy, который, судя по названию, является общим (не связан с Account). Как тогда потом осуществлять вызов методов из Account? Ведь этих методов в этом прокси нет.

S>>

Прокси заточен под целевой класс, т.е. он явно о нем знает и не может без него существовать. Т.е. первым мы разрабатываем целевой класс (поскольку ему не нужен прокси -- он о нем ничего не знает), а потом уже прокси. Одно очень паршивое следствие состоит в том, что при каждом изменении целевого класса необходимо следить за прокси (откуда ошибки).
V>Или поручить эту задачу компилятору

Правильный ход мысли. Но тогда надо ее развить дальше. Компилятор должен знать что с чем связано, т.е. какой прокси представляет какой класс. Т.е. надо в исходном тексте ввести какие-то указания. А это собственно уже будет новый язык программирования, где явно поддерживаются такие связи. Возможно: даже очень хороший язык. Но ведь его пока нет.

S>>

Нельзя использовать один прокси для многих целевых классов. Например, мы хотим разработать прокси ProxyForMarsObjects, а затем использовать его для доступа к объектам на Марсе, имеющих самый разный класс, который заранее не известен. Как это сделать? Я такого способа не знаю. Если знаете, то опишите, пожалуйста (а также см. п.1).
V>Ну, абстрагироваться от источника данных — это довольно легко. Помнится, ещё лет шесть-семь назад я написал прогу, которая в штатном режиме работала с SQL-сервером, а когда он оказывался недоступным (модем выключили), со вздохом лезла в локальный DBF-кэш. Что характерно, основная логика программы даже не догадывалась, что вместо сиськи теперь у неё соска. И всё это безо всяких КОП. И даже без Design Patterns. На старом добром Дельфи.

Остается только описать суть решения, а то на слово как-то не верится. А то потом окажется, что это вовсе не SQL-сервер был, да и не на Дельфи написано было

S>>

Ну и в программе мы хотим использовать непосредственно целевые объекты, например, myAccount.getBalance(), тогда как в прокси мы вынуждены работать с посредником: myAccountProxy.getBalance(). Чувствуете разницу?
V>Чувствую. И особенно почувствуют те, кто будет дорабатывать и обезглючивать мою программу. Если в "нормальной" программе глючит myAccount.getBalance(), то я открываю исходник этого самого myAccount.getBalance() и ищу багу там. Но если где-то рядышком болтается ещё куча каких-то непонятных личностей, которые как им заблагорассудится перехватывают вызовы до, после, а также вместо отработки собственно "тела" getBalance(), то я просто сойду с ума!

Ну никто же не жалуется, что при вызове figure.draw() в ООП будет на самом деле отрабатываться незивестно какая процедура. Даже брейк-поинт неизвестно где поставить. А перехват доступа происходит всегда и везде (прямого доступа нет), так лучше поставить этот механизм под контроль, чем вообще не знать, что происходит в программе. Кстати, доступ в КОП происходит по вполне понятным и естественным правилам, аналогичным доставке почты. Сперва идем в нужный город, потом в контексте города доходим до улицы и т.д. до цели. Ничего сложного здесь нет. Если метод не достиг цели, то ищи причину в базовых концептах.

S>>[/list]

S>>Я уже не говорю о том, что наличие большого числа паттернов есть признак кризиса в теории.
V>Согласен

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

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


S>>Т.е. происходит что-то вроде этого:

S>>

S>>Lock(memHandle); 
S>>mem =Resolve(memHandle);
mem->>>myMethod(); 
S>>Unlock(memHandle);
S>>

S>>Такой подход имеет следующие недостатки. Один и тот же код повторяется по всей программе (а что если что-то изменится в последовательности доступа). Я вовсе не хочу заниматься какими-то вспомогательными процедурами, а просто хочу вызвать метод по ссылке. Зачем такие сложности. Ну и кроме того, получение разрешенной ссылки в контекст, где она используется это очень плохо (небезопасно). Внутреннее представление должно храниться и использоваться внутри, а извне надо использовать внешнее представление. В КОП это выглядело бы так:
S>>

S>>memHandle->myMethod(); 
S>>

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

FR>Может стоит познакомится с динамическими языками? Там подобные перехваты легко реализуются.

Думаю стоит, но нет подходящих ссылок.

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

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

S>В КОП это выглядело бы так:
S>

S>memHandle->myMethod(); 
S>

S>Преимущества. Мы просто применяем метод к ссылке. Внутренний идентификатор (адрес в памяти) не попадает к нам, и мы не можем ничего испортить. Всегда можно изменить механизм доступа без изменения того, где он используется. Например, можно добавить начало и конец транзакции.
Во-первых, приведённый выше memHandle наверняка сначала инициализируется. Как-нибудь вот так:

memHandle.SetRef(MyWonderfulOID);

На мой взгляд, это не сильно проще, чем такое:

CCustomer *memHandle = new CCustomer(MyWonderfulOID); // При инициализации полезет в БД и вытащит кустомера в память
memHandle->myMethod(); // Сделает с кустомером что-то

Во-вторых, напрямую управляя получением/уничтожением "настоящего" объекта, мы можем выиграть в скорости. Например, если после myMethod() сразу вызывается myNextMethod(), то КОП сделает следующее:
1. Вытащит объект из БД.
2. Вызовет ему myMethod().
3. Выкинет объект из памяти.
4. Вытащит объект из БД ещё раз.
5. Вызовет ему myNewMethod().
6. Выкинет объект из памяти.
Итак, в базу слазили два раза. А так как залезание в базу — наверняка самая ресурсоёмкая здесь операция, то программа на ровном месте стормозила почти в два раза.

V>>До сих пор я думал, что вся программа — это алгоритмы и структуры данных (с) Н.Вирт
S>Так можно до Аристотеля добраться Почему бы не определить программу на компьютере как организованный набор атомов? Общее определение – зато никто не докопается.
Иногда и до Аристотеля полезно бывает добираться. В нашем ремесле так уж повелось, что, если мы не трепемся в RSDNе, то выдумываем алгоритмы и структуры данных. Чтобы задачу поставленную решить. Иногда, конечно, приходится и задачу самому ставить, но это уже совсем другая тема.

V>>Всё же, всё же... Зачем мне это может понадобиться? Я даже более-менее подходящий пример придумать не могу!
S>Вы уже описали такой пример в начале этого поста. Пусть ваши объекты хранятся в БД и имеют ключ в качестве идентификатора. Проблема: вызвать метод можно только по системной ссылке, тогда в наличии имеется только первичный ключ. Тут-то и поможет КОП.
Как я выше показал, можно и без КОП. По-моему, даже ещё и красивее получилось. И главное — всё под контролем. Моим контролем, а не какого-то там посредника.

V>>Мне больше нравится такая автоматизация:
V>>

V>>    Set xls = CreateObject("Excel.Application")
V>>    wb = xls.Workbooks.Open "C:\MyFile.xls"
V>>

V>>И всем (и особенно мне) от этого ХОРОШО

S>Хорошо только до определенного момента (обычно это проходит для малых или средних программ).
Вот как раз для особо больших программ и важно, чтобы я имел возможность легко и быстро (вечный дэдлайн!) программировать логику, не задумываясь о задействованных механизмах. Пусть Excel.Application думает о том, насколько у него большой MyFile.xls, и как много у него маленьких клеточек внутри!

V>>А, может быть, не вахтёр, а начальник тюрьмы?

S>Это государство, т.е., по определению классика, инструмент насилия. В зависимости от того, где объект родился и живет, к нему применяются разные законы. В частности, разные средства обозначения, разный жизненный цикл, разную степень открытости, разное наказание, разные ресурсы и т.п. Как раз на построение такого государства объектов и нацелено КОП. Мы описываем его структуру, законы, границы и т.п. И все это может функционировать сам по себе без объектов.
Моё твёрдое убеждение, что стандартных ограничений видимости (private, public и иже с ними) для этих целей достаточно, и больше ничего выдумывать не надо. Мне, по крайней мере, хватало. Или я не прав?

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



FR>>Может стоит познакомится с динамическими языками? Там подобные перехваты легко реализуются.

S>Думаю стоит, но нет подходящих ссылок.

Тут думаю парой ссылок не обойтись, нужно смотреть и изучать эти языки, некторые примеры можешь посмотреть тут Re[5]: Питон наступает :)

Автор: FR
Дата: 23.07.06

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

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

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

S>Остается только описать суть решения, а то на слово как-то не верится. А то потом окажется, что это вовсе не SQL-сервер был, да и не на Дельфи написано было

Да нет, всё-таки MS SQL и Дельфи. Программка была, которая показывала остатки товаров на разных складах. Так как нужна она была и там, где соединение с головным офисом происходило два раза в день через модем, пришлось сделать финт с локальным кэшем.

S>>>

Ну и в программе мы хотим использовать непосредственно целевые объекты, например, myAccount.getBalance(), тогда как в прокси мы вынуждены работать с посредником: myAccountProxy.getBalance(). Чувствуете разницу?
V>>Чувствую. И особенно почувствуют те, кто будет дорабатывать и обезглючивать мою программу. Если в "нормальной" программе глючит myAccount.getBalance(), то я открываю исходник этого самого myAccount.getBalance() и ищу багу там. Но если где-то рядышком болтается ещё куча каких-то непонятных личностей, которые как им заблагорассудится перехватывают вызовы до, после, а также вместо отработки собственно "тела" getBalance(), то я просто сойду с ума!

S>Ну никто же не жалуется, что при вызове figure.draw() в ООП будет на самом деле отрабатываться незивестно какая процедура. Даже брейк-поинт неизвестно где поставить.
Если криво рисуется линия, то см. line.draw(), а если круг, то circle.draw(). Что ж не понятно?
S>А перехват доступа происходит всегда и везде (прямого доступа нет)
... и известно как!
S>так лучше поставить этот механизм под контроль, чем вообще не знать, что происходит в программе.
То есть отдать в кривые ручки программера? Это называется "поставить под контроль"?

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

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

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

S>>В КОП это выглядело бы так:
S>>

S>>memHandle->myMethod(); 
S>>

S>>Преимущества. Мы просто применяем метод к ссылке. Внутренний идентификатор (адрес в памяти) не попадает к нам, и мы не можем ничего испортить. Всегда можно изменить механизм доступа без изменения того, где он используется. Например, можно добавить начало и конец транзакции.
V>Во-первых, приведённый выше memHandle наверняка сначала инициализируется. Как-нибудь вот так:
V>

V>memHandle.SetRef(MyWonderfulOID); 
V>

V>На мой взгляд, это не сильно проще, чем такое:
V>

V>CCustomer *memHandle = new CCustomer(MyWonderfulOID); // При инициализации полезет в БД и вытащит кустомера в память
V>memHandle->myMethod(); // Сделает с кустомером что-то
V>

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

V>Во-вторых, напрямую управляя получением/уничтожением "настоящего" объекта, мы можем выиграть в скорости. Например, если после myMethod() сразу вызывается myNextMethod(), то КОП сделает следующее:
V>1. Вытащит объект из БД.
V>2. Вызовет ему myMethod().
V>3. Выкинет объект из памяти.
V>4. Вытащит объект из БД ещё раз.
V>5. Вызовет ему myNewMethod().
V>6. Выкинет объект из памяти.
V>Итак, в базу слазили два раза. А так как залезание в базу — наверняка самая ресурсоёмкая здесь операция, то программа на ровном месте стормозила почти в два раза.

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


V>>>До сих пор я думал, что вся программа — это алгоритмы и структуры данных (с) Н.Вирт
S>>Так можно до Аристотеля добраться Почему бы не определить программу на компьютере как организованный набор атомов? Общее определение – зато никто не докопается.
V>Иногда и до Аристотеля полезно бывает добираться. В нашем ремесле так уж повелось, что, если мы не трепемся в RSDNе, то выдумываем алгоритмы и структуры данных. Чтобы задачу поставленную решить. Иногда, конечно, приходится и задачу самому ставить, но это уже совсем другая тема.

V>>>Всё же, всё же... Зачем мне это может понадобиться? Я даже более-менее подходящий пример придумать не могу!
S>>Вы уже описали такой пример в начале этого поста. Пусть ваши объекты хранятся в БД и имеют ключ в качестве идентификатора. Проблема: вызвать метод можно только по системной ссылке, тогда в наличии имеется только первичный ключ. Тут-то и поможет КОП.
V>Как я выше показал, можно и без КОП. По-моему, даже ещё и красивее получилось. И главное — всё под контролем. Моим контролем, а не какого-то там посредника.

Конечно можно без КОП, но просто криво получается. Хочу описать заказчика, а должен заниматься доступ к БД. И где же здесь смысл? Опять его нет.

V>>>Мне больше нравится такая автоматизация:
V>>>

V>>>    Set xls = CreateObject("Excel.Application")
V>>>    wb = xls.Workbooks.Open "C:\MyFile.xls"
V>>>

V>>>И всем (и особенно мне) от этого ХОРОШО

S>>Хорошо только до определенного момента (обычно это проходит для малых или средних программ).
V>Вот как раз для особо больших программ и важно, чтобы я имел возможность легко и быстро (вечный дэдлайн!) программировать логику, не задумываясь о задействованных механизмах. Пусть Excel.Application думает о том, насколько у него большой MyFile.xls, и как много у него маленьких клеточек внутри!

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

С другой стороны, даже Б. Гейтс нас не спасет, поскольку все объекты в этом примере имеют стандартные системные ссылки. А раз стандартные, значит не очень хорошие (ссылки на все случаи жизни не бывает). И тут мы опять захотим разработать то, что нужно нам, а не что предлагает Excel. (У вас есть туалетная бумага? Нет, но зато у нас есть наждачная.)

V>>>А, может быть, не вахтёр, а начальник тюрьмы?

S>>Это государство, т.е., по определению классика, инструмент насилия. В зависимости от того, где объект родился и живет, к нему применяются разные законы. В частности, разные средства обозначения, разный жизненный цикл, разную степень открытости, разное наказание, разные ресурсы и т.п. Как раз на построение такого государства объектов и нацелено КОП. Мы описываем его структуру, законы, границы и т.п. И все это может функционировать сам по себе без объектов.
V>Моё твёрдое убеждение, что стандартных ограничений видимости (private, public и иже с ними) для этих целей достаточно, и больше ничего выдумывать не надо. Мне, по крайней мере, хватало. Или я не прав?

А мне даже этого много. Ограничение доступа обычно приносит больше вреда, чем пользы. Сперва надо все двери открыть и работать без ограничений. И только в конце, когда будет ясно, что собственно надо охранять, надо какие-то комнаты прикрыть. Но проблема вся в том, что как раз до такого конечного состояния завершенности доходит очень редкий проект. А закрытые двери очень сильно мешают, поскольку народ бегает, суетится и толпится перед ними, не зная, какой очередной идиот закрыт дверь и ушел (хотя охранять там особо нечего). А вообще, надо оценить, что хуже, когда хороший человек не может попасть в комнату, либо когда плохой человек может туда попасть. Лучшее лекарство это выставить оборону на как можно дальнем расстоянии так, чтобы внутри все было открыто. Например, на уровне отдела кадров, который подбирает только хороших сотрудников. Тогда внутри все можно открыть, что сильно повышает производительность.

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

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

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



FR>>>Может стоит познакомится с динамическими языками? Там подобные перехваты легко реализуются.

S>>Думаю стоит, но нет подходящих ссылок.

FR>Тут думаю парой ссылок не обойтись, нужно смотреть и изучать эти языки, некторые примеры можешь посмотреть тут Re[5]: Питон наступает :)

Автор: FR
Дата: 23.07.06

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

FR>Теории нет, но на практике давно используются подобные приемы. И вообще почему именно нужен перхеват ссылок?

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

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

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

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

S>Правильный ход мысли. Но тогда надо ее развить дальше. Компилятор должен знать что с чем связано, т.е. какой прокси представляет какой класс. Т.е. надо в исходном тексте ввести какие-то указания. А это собственно уже будет новый язык программирования, где явно поддерживаются такие связи. Возможно: даже очень хороший язык. Но ведь его пока нет.
nemerle.org при помощи его макросов можно сделать что угодно.

S>Остается только описать суть решения, а то на слово как-то не верится. А то потом окажется, что это вовсе не SQL-сервер был, да и не на Дельфи написано было
Да банально это делается:

class MyObject
{
    public int Id;
    ...
}
interface IDataLayer
{
    MyObject GetMyObject(int id);
}

class SQLDataLayer : IDataLayer
{
    public MyObject GetMyObject(int id)
    {
        ...
    }
    public bool IsAvailable
    {
        get { ... }
    }
}

class DBFDataLayer : IDataLayer
{
    public MyObject GetMyObject(int id)
    {
        ...
    }
}

class SelectiveDataLayer : IDataLayer
{
    readonly SQLDataLayer m_SQLDataLayer;
    readonly DBFDataLayer m_DBFDataLayer;
    public SelectiveDataLayer(SQLDataLayer _SQLDataLayer, DBFDataLayer _DBFDataLayer)
    {
        m_SQLDataLayer = _SQLDataLayer;
        m_DBFDataLayer = _DBFDataLayer;
    }
    
    IDataLayer DataLayer
    {
        get
        {
            if (m_SQLDataLayer.IsAvailable)
                return m_SQLDataLayer;
            else
                return m_DBFDataLayer;
        }
    }
    public MyObject GetMyObject(int id)
    {
        return DataLayer.GetMyObject(id);
    }
}

На дельфе делается один в один.
В нормальной IDE механической работы практически не будет.

А если использовать язык с метарограммированием то вобще все просто как не учить уроки.
Например на nemerle это будет выглядить както так

[Record]
[InterfaceImpl(IDataLayer, DataLayer)]
class SelectiveDataLayer : IDataLayer
{
    m_SQLDataLayer : SQLDataLayer;
    m_DBFDataLayer : DBFDataLayer;
    DataLayer : IDataLayer
    {
        get
        {
            if (m_SQLDataLayer.IsAvailable)
                m_SQLDataLayer;
            else
                m_DBFDataLayer;
        }
    }
}

Макрос InterfaceImpl переправит все вызовы интерфейса IDataLayer свойству DataLayer, а стандартный макрос Record сгенерирует конструктор те нам вобще ничего делать не нужно будет.

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

S>А мне даже этого много. Ограничение доступа обычно приносит больше вреда, чем пользы. Сперва надо все двери открыть и работать без ограничений. И только в конце, когда будет ясно, что собственно надо охранять, надо какие-то комнаты прикрыть.
А может нужно проектировать систему, а не писать как попало?
Вот мне почемуто сразу ясно что открыть, а что не нужно.
Просто нужно сразу выделять интерфейс объекта и ни при каких обстоятельствах не мешать его с реализацией.
Также жизненно важно разбивать систему на уровни: Уровень данных. Уровень бизнес логики. Уровень пользовательского интерфейса. (это самое примитивное деление)
И ни в коем случае не смешивать их. Ибо если один раз смешал то дальше это будет наростать как снежный клубок. А распутать этот клубок потом будет очень не просто.

S>Но проблема вся в том, что как раз до такого конечного состояния завершенности доходит очень редкий проект. А закрытые двери очень сильно мешают, поскольку народ бегает, суетится и толпится перед ними, не зная, какой очередной идиот закрыт дверь и ушел (хотя охранять там особо нечего). А вообще, надо оценить, что хуже, когда хороший человек не может попасть в комнату, либо когда плохой человек может туда попасть. Лучшее лекарство это выставить оборону на как можно дальнем расстоянии так, чтобы внутри все было открыто. Например, на уровне отдела кадров, который подбирает только хороших сотрудников. Тогда внутри все можно открыть, что сильно повышает производительность.
Нет лучшее лекарство это организовать работу так чтобы народу ненужно было ломится куда попало.
Вот на прошлой работе в здании было 4 этажа, сотни комнат... А мне нужна было только одна (не считая коридоров, туалета и столовой) и от того закрыты или открыты другие комнаты моя производительность труда вобще никак не зависила.

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

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

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

S>

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

Парадигма — это не набор спецификаций. Парадигма — это удобный способ решения огромного класса задач.
Отдельной строковой константы "5" тоже ни в одном языке программирования нет. Значит, нужно придумывать новый подход, в котором эта константа будет? Ведь эта константа пригодится многим разработчикам во всем мире!

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

Например, ООП и паттерны проектирования используются для удобного решения задач, сводимых к объектной декомпозиции: есть классы объектов, у каждого класса есть свое поведение, описываемое некоторым "контрактом" — набором свойств, методов и правил доступа.
В свою очередь АОП позволяет уменьшить объем кода при построении любой многослойной логики (авторизация при необходимости, кэширование на лету, проверка прав доступа на лету и т.п.).
У тебя пока кроме задачи проксирования никакой другой задачи не вижу. А эта задача для больших систем уже была решена на много раз, самый известный пример, наверное, это Microsoft с технологией COM еще в глубоком 1995м году (или около того). MS Office и MSIE тому наглядное свидетельство.

#-*- encoding: cp1251 -*-
#Пример использования:
>>> rgb = RGB( 100, 192, 240 )
>>> rgb.Red()
100
>>> proxy = Proxy( rgb )
>>> proxy.Green()
192
>>> noblue = NoBlueProxy( rgb )
>>> noblue.Green()
192
>>> noblue.Blue()
0

#Сам код:
class Proxy:
    def __init__( self, subject ):
        self.__subject = subject
    def __getattr__( self, name ):
        return getattr( self.__subject, name )      

#Figure 11. Proxy base class

class RGB:
    def __init__( self, red, green, blue ):
        self.__red = red
        self.__green = green
        self.__blue = blue
    def Red( self ):
        return self.__red
    def Green( self ):
        return self.__green
    def Blue( self ):
        return self.__blue    

#Figure 12. Subject class

class NoBlueProxy( Proxy ):
    def Blue( self ):
        return 0    

P.S. Графоманские комментарии - мои.

Вот весь твой КОП на питоне 2.4. Ссылочка взята с первого попавшегося мне на глаза по запросу "python proxy pattern" документа http://www.python.org/workshops/1997-10/proceedings/savikko.html (да, похоже, 1997 год)
Ну и где тут твоя необходимость изменять проксик вместе с изменениями объекта?

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

S>Правильный ход мысли. Но тогда надо ее развить дальше. Компилятор должен знать что с чем связано, т.е. какой прокси представляет какой класс. Т.е. надо в исходном тексте ввести какие-то указания. А это собственно уже будет новый язык программирования, где явно поддерживаются такие связи. Возможно: даже очень хороший язык. Но ведь его пока нет.

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

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

S>Не согласен. Представим, что теперь пришел начальник и говорит, что все мол, хватит баловаться, объекты будут храниться в XML на моем домашнем компе. Хочешь или не хочешь, а надо переписывать класс CCustomer. А причина в том, что вместо того, чтобы описывать структуру и функции заказчика, туда загнали еще персистенс, который к заказчикам не имеет никакого отношения. В КОП CCustomer включает исключительно повадки заказчиков, а где он будет находиться (в куче, в БД или на др. компе) заранее неизвестно. Способ представления определяется в объявлении этого класса и реализуется в родительских концептах.

Вот потом после такого винда тормозит при входе в систему, когда сеть недоступна и подключены сетевые диски. После этого виндовс эксплорер виснет, когда пытается доступиться на сетевые диски или FTP, но со связью проблемы.
Методы доступа всегда накладывают свои ограничения, часто нефункциональные, например, "время доступа" или "необходимость /вред от кеширования данных для ускорения работы", "прокси с авторизацией по паролю". Попытка их игнорировать — признак неопытности. (подробнее — Джоэл Спольски, "Leaky abstractions". Хотя, я думаю, все уже эту статью прочитали.)

Поэтому заменить класс, от которого наследуется (если это ООП) customer, придется. К счастью, все нормальные архитекторы понимают, какие части системы трудно будет изменить, и поэтому особо тщательно их прописывают в архитектуре. Менять их потом теоретически возможно, но не рекомендуется. В силу именно нефункциональных ограничений.
В случае баз данных — основная причина — скорость — тоже нефункциональная. И ORM-мапперы тут не помогут. Только автоматический переписыватель SQL-запросов и хранимых процедур (девелопер БД) . Представил сложность?
Есть еще и экономическая причина — уменьшение трудоемкости задачи. Попробуй писать большую программу, переносимую на linux, win32 и win64, имея только компилятор для win32 и возможность проверки на win32. Слабо?

p.s. А начальники такие никогда не переведутся. И ведь они в чем-то правы — деньги-то они платят за твою работу, какой бы тупой она не была. А за твое безделье ни один начальник денег не заплатит.

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

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

S>>А мне даже этого много. Ограничение доступа обычно приносит больше вреда, чем пользы. Сперва надо все двери открыть и работать без ограничений. И только в конце, когда будет ясно, что собственно надо охранять, надо какие-то комнаты прикрыть.
WH>А может нужно проектировать систему, а не писать как попало?

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

WH>Вот мне почемуто сразу ясно что открыть, а что не нужно.

А вот мне чем дальше, тем менее ясным становится.

WH>Просто нужно сразу выделять интерфейс объекта и ни при каких обстоятельствах не мешать его с реализацией.

Как я выше отметил, есть разные подходы к проектированию и такое разделение это всего лишь один из них (не самый лучший).

WH>Также жизненно важно разбивать систему на уровни: Уровень данных. Уровень бизнес логики. Уровень пользовательского интерфейса. (это самое примитивное деление)
WH>И ни в коем случае не смешивать их. Ибо если один раз смешал то дальше это будет наростать как снежный клубок. А распутать этот клубок потом будет очень не просто.

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

S>>Но проблема вся в том, что как раз до такого конечного состояния завершенности доходит очень редкий проект. А закрытые двери очень сильно мешают, поскольку народ бегает, суетится и толпится перед ними, не зная, какой очередной идиот закрыт дверь и ушел (хотя охранять там особо нечего). А вообще, надо оценить, что хуже, когда хороший человек не может попасть в комнату, либо когда плохой человек может туда попасть. Лучшее лекарство это выставить оборону на как можно дальнем расстоянии так, чтобы внутри все было открыто. Например, на уровне отдела кадров, который подбирает только хороших сотрудников. Тогда внутри все можно открыть, что сильно повышает производительность.
WH>Нет лучшее лекарство это организовать работу так чтобы народу ненужно было ломится куда попало.
WH>Вот на прошлой работе в здании было 4 этажа, сотни комнат... А мне нужна было только одна (не считая коридоров, туалета и столовой) и от того закрыты или открыты другие комнаты моя производительность труда вобще никак не зависила.

S>>Но в КОП проверки и безопасность это всего лишь частный случай. Программист может там написать все что угодно. Например, просто диагностическую запись выдать, что мол, такой-то процесс зашел в охраняемую зону с такими-то параметрами.
WH>Както весь этот твой КОП выглядит очень искуственно и натянуто. Даже еще болие искуственно и натянуто чем Оберон...

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

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

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

S>>

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

B>Парадигма — это не набор спецификаций. Парадигма — это удобный способ решения огромного класса задач.

Именно такой способ и предлагается.

B>Например, ООП и паттерны проектирования используются для удобного решения задач, сводимых к объектной декомпозиции: есть классы объектов, у каждого класса есть свое поведение, описываемое некоторым "контрактом" — набором свойств, методов и правил доступа.

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

Кстати, правил доступа в ООП нет, если не считать статические ограничители доступа. Доступ и представление это прерогатива КОП.

B>В свою очередь АОП позволяет уменьшить объем кода при построении любой многослойной логики (авторизация при необходимости, кэширование на лету, проверка прав доступа на лету и т.п.).

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

B>У тебя пока кроме задачи проксирования никакой другой задачи не вижу. А эта задача для больших систем уже была решена на много раз, самый известный пример, наверное, это Microsoft с технологией COM еще в глубоком 1995м году (или около того). MS Office и MSIE тому наглядное свидетельство.

Задачи проксирования в КОП нет. Это просто механизм, который обычно предлагают вместо КОП при первом знакомстве, а потому можно с ним сравнивать. Кроме того, COM, MS Office и MSIE от Микрософта это НЕ языки программирования, соответственно и разговора никакого нет (не вижу связи).

B>Вот весь твой КОП на питоне 2.4. Ссылочка взята с первого попавшегося мне на глаза по запросу "python proxy pattern" документа http://www.python.org/workshops/1997-10/proceedings/savikko.html (да, похоже, 1997 год)
B>Ну и где тут твоя необходимость изменять проксик вместе с изменениями объекта?

Да, действительно так. Питон оказывается может как хамелеон имитировать другой класс. Это заслуга Питона (но не ООП, очевидно). Не хочу тебя расстраивать, но это мало что меняет. Во-первых, ты по-прежнему должен работать с прокси, т.е. надо писать так:

>>> proxy = Proxy( rgb )
>>> proxy.Green()

Ну а теперь объясни, будь добр, зачем мне это надо, если я хочу работать не с прокси, а с конечным объектом? Могу только повторить, что переменные должны иметь класс целевого объекта независимо от того, кто, как и когда встрянет потом между ними (кстати, это выполняется в АОП, что есть хорошо). Вот если бы можно было написать

>>> rgb = RGB( 100, 192, 240 )
>>> rgb.Red()

и при этом ссылка rgb указывала бы на прокси, то это было бы немного ближе к нашей великой цели. Но этого не происходит, а потому нужно пригласить КОП, который это умеет делать.

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

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

>>> proxy = Proxy( rgb )
>>> proxy.Green()

то все равно наша ссылка это обычная системная ссылка. Подумай о том, что этот объект может быть не в системной куче, а где-нибудь в трудно доступном месте, куда даже лучшая зубная щетка не достает. Че тогда будешь делать? Методов на самом деле кучу, но просто все это надо будет делать руками. Но хуже всего то, что это сразу приводит к размножению кода. Например, пусть у меня объекты хранятся на разных компах. Тогда нужна ссылка:

reference {
  String compName;
  int port;
  int objectId;
}

А далее я хочу все свои имеющиеся и будущие классы представлять такими ссылками, но пользоваться ими как обычными объектами, например:

  Customer cust = new Customer(); 
  Account acc = new Account(cust); 
  double acc.setBalance(1000);
}

Здесь все ссылки имеют сложный формат из трех полей. Но используются объекты как обычно. Если в будущем изменится формат ссылок, способ хранения объектов или что-то еще в механизме доступа, то этот код останется таким же. Круто?

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

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

S>>Правильный ход мысли. Но тогда надо ее развить дальше. Компилятор должен знать что с чем связано, т.е. какой прокси представляет какой класс. Т.е. надо в исходном тексте ввести какие-то указания. А это собственно уже будет новый язык программирования, где явно поддерживаются такие связи. Возможно: даже очень хороший язык. Но ведь его пока нет.

AL>Хотите "мега-идею"? Поместите кусок компилятора, знающего про координационные примитивы КОП, в рантайм.

Хорошая идея и я ее разрабатываю. Это ведет примерно в сторону т.н. языково-ориентированного программирования.

AL>Он будет динамически патчить код доступа при изменении взаимного положения взаимодействующих компонентов. Т.е. то, что разнесено по разным ммм... контекстам, будет взаимодействовать через прокси-заменители. А все остальное -- традиционным способом.

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

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

S>Ну а теперь объясни, будь добр, зачем мне это надо, если я хочу работать не с прокси, а с конечным объектом?
Если хочешь — работай. Хочешь через прокси — работай через прокси. Или ты хочешь заставить себя работать с прокси даже тогда, когда хочешь работать с конечным объектом?
S>Могу только повторить, что переменные должны иметь класс целевого объекта независимо от того, кто, как и когда встрянет потом между ними (кстати, это выполняется в АОП, что есть хорошо). Вот если бы можно было написать
S>

>>>> rgb = RGB( 100, 192, 240 )
>>>> rgb.Red()
S>

S>и при этом ссылка rgb указывала бы на прокси, то это было бы немного ближе к нашей великой цели. Но этого не происходит
Подсказка: никто не мешает запроксировать сам вызов RGB, который вернет то, что нужно. Точнее, мешает, но об этом далее.

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

>>>> proxy = Proxy( rgb )
>>>> proxy.Green()
S>

S>то все равно наша ссылка это обычная системная ссылка.
Ну и что?
S>Подумай о том, что этот объект может быть не в системной куче, а где-нибудь в трудно доступном месте, куда даже лучшая зубная щетка не достает. Че тогда будешь делать?
То же самое. Вот, в дотнете поддерживается прозрачное проксирование объектов через границу доменов. Никаких проблем — все достает. Статическая типизация ограничивает удобство написания универсальных прокси; для питона это не проблема.
S>Методов на самом деле кучу, но просто все это надо будет делать руками. Но хуже всего то, что это сразу приводит к размножению кода. Например, пусть у меня объекты хранятся на разных компах. Тогда нужна ссылка:
S>

S>reference {
S>  String compName;
S>  int port;
S>  int objectId;
S>}
S>

S>А далее я хочу все свои имеющиеся и будущие классы представлять такими ссылками, но пользоваться ими как обычными объектами, например:
S>

S>  Customer cust = new Customer(); 
S>  Account acc = new Account(cust); 
S>  double acc.setBalance(1000);
S>}
S>

S>Здесь все ссылки имеют сложный формат из трех полей.
Пардон, а откуда берутся значения этих полей? Злая магия подставляет имя компьютера и порт?
S>Но используются объекты как обычно. Если в будущем изменится формат ссылок, способ хранения объектов или что-то еще в механизме доступа, то этот код останется таким же. Круто?
А особенно круто — то, что это уже есть и доступно. В 100% сред это доступно при отказе от использования оператора new в прикладном коде — вместо этого используются вызовы фабрик, которые в свою очередь проксируются в одном месте.

Здравствуйте, eao197, Вы писали:
E>А что сейчас для защиты в области информатики внедрения уже не нужны?
Это для к.т.н. нужны. А если к.ф-м.н — то достаточно "уникального вклада в науку".