Re^2: Rules.
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
04 Янв 04, в 23:13, *Andrei N. Sobchuck* писал я к _Dmitry Feodorov_:
DF>> В любом таком выборе есть плюсы у одного, плюсы у другого. Так
DF>> вот хотелось бы обсудить их список при сравнении данных
DF>> технологий.
AS> Вопроса я не понимаю потому, что, afaik, выбора нет.
AS> Есть либо наследование, либо делегирование.
AS> Если я не прав, то хочется узнать какой язык поддерживает
AS> оба механизма.
Про далагирование и наследование вопроса не стояло. Hо imho, их парралельно
поддерживают 99% объектно ориентированных языков.
AS> А агрегация vs. наследование(делегирование) штука описанная
AS> (у Буча, например. или вот дискуссия -
AS> http://www.c2.com/cgi/wiki?CompositionInsteadOfInheritance).
Загляну, но хотелось бы узнать точки зрения, отличные от взглядов метра.
AS> Так это смотря что понимать под делегированием. Если рассматривать в
AS> контексте диспетчеризации сообщений, то в чистом виде не получится.
AS> Можно реализовать только пересылку сообщений aka "redirection"
AS> или "forwarding"
Hа мой взгляд, это обработка одного сообщения несколькими объектами, но при
этом число обработчиков неважно и каждый из них не имеет представление о других
обработчиках.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Andrei N. Sobchuck
DF> Hа мой взгляд, это обработка одного сообщения несколькими объектами, но при
DF> этом число обработчиков неважно и каждый из них не имеет представление о других
DF> обработчиках.
При делегировании "self" (или "this" - указатель на текущий объект) в объекте,
которому делегировано выполнение, продолжает указывать на объект из которого
произошло делегирование.
А просто переслать сообщение - дело не хитрое.
--
Andrei N.Sobchuck
JabberID: and...@jabber.ru. ICQ UIN: 46466235.
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
05 Янв 04, в 09:55, *Andrei N. Sobchuck* писал я к _Dmitry Feodorov_:
DF>> Hа мой взгляд, это обработка одного сообщения несколькими
DF>> объектами, но при этом число обработчиков неважно и каждый из них
DF>> не имеет представление о других обработчиках.
AS> При делегировании "self" (или "this" - указатель на текущий объект) в
AS> объекте, которому делегировано выполнение, продолжает указывать на
AS> объект из которого произошло делегирование. А просто переслать
AS> сообщение - дело не хитрое.
А теперь еще раз и по-русски:
1) self какого объекта?
2) а почему это должно быть так и зачем self тогда нужен?
3) а может дать определение делегирования не лазя под капот языков
программирования. Все-таки о логическом уровне рассуждаем.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Andrei N. Sobchuck
[Похоже, наглый гейт где-то проглотил этот пост]
DF>>> Hа мой взгляд, это обработка одного сообщения несколькими
DF>>> объектами, но при этом число обработчиков неважно и каждый из них
DF>>> не имеет представление о других обработчиках.
AS>> При делегировании "self" (или "this" - указатель на текущий объект) в
AS>> объекте, которому делегировано выполнение, продолжает указывать на
AS>> объект из которого произошло делегирование. А просто переслать
AS>> сообщение - дело не хитрое.
DF> А теперь еще раз и по-русски:
DF> 1) self какого объекта?
Допустим есть два объекта "А" и "Б". Если объект "А" делегирует объекту "Б"
выполнение операции "раз", то вызов "self два" в методе "раз" приведёт к
тому, что поиск метода, отвечающего на сообщение "два", начнётся
с объекта "А", а не с объекта "Б".
Полная аналогия с наследованием (смотри на Б, как на суперкласс, а на А,
как подкласс).
DF> 2) а почему это должно быть так и зачем self тогда нужен?
автоматически делегируется выполнение одной операции. За все остальные
продолжает отвечать делегирующий объект. self нужен абсолютно для того же,
для чего он используется в языках с классами.
DF> 3) а может дать определение делегирования не лазя под капот языков
DF> программирования. Все-таки о логическом уровне рассуждаем.
Если смотреть не с точки зрения конкретных ЯП, а рассматривать
делегирование, как передачу ответсвенности вообще, то не понятно,
почему ты противопоставляешь делегирование и агрегацию. При помощи
агрегации можно организовать "ручное" делегирование.
Но нет смысла их противопоставлять.
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
07 Янв 04, в 13:10, *Andrei N. Sobchuck* писал я к _Dmitry Feodorov_:
DF>> IMHO, интерфейсы нужны для абстрагирования от реализаций
DF>> объектов, т.е. в
AS> Если не брать во-внимание теоретические выгоды (типа документирование
AS> кода и т.д.), то есть очень прагматическая причина, по-которой
AS> без интерфейсов будет тяжело. А именно - строгая типизация. Как
AS> минимум в Жаву добавляли их для того, чтобы "обойти" ограничения на
AS> тип переменной в условиях одиночного наследования..
И это тоже немаловажно.
DF>> большинстве задач это понятие близкое абстрактному классу.
AS> Почти.
Я не говорю, что это одно и то же, но ведь близкие же у них цели.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
30 Дек 03, в 14:48, *Dmitry Lapshin* писал я к _Dmitry Feodorov_:
DF>>>> думаю идею шаблонов через какое-то время ждет такая же судьба.
DL>>> Да, в C# 2.0 уже обещают. А то без них типизированные коллекции
DL>>> кривовато выглядят.
DF>> Почему?
DL> А потому что все приходится приводить к типу object и обратно.
Hу may be, так как я сам на vb.net пишу.
DL>>> интерфейсов, и особых проблем это не вызывает. Хотя mix-in'ы
DL>>> порой вещь несомненно полезная.
DF>> Граблей слишком много, зачастую проще немного додумать
DF>> архитектуру проекта.
DL> Продумать архитектуру - это завсегда хорошо :-) Hасчет граблей - не
DL> знаю, активно mix-in'ы не юзал.
В VB6 активно на них приходилось наступать. Там вроде особых гиморов
необратимых не было.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Andrei N. Sobchuck
DL>>>> интерфейсов, и особых проблем это не вызывает. Хотя mix-in'ы
DL>>>> порой вещь несомненно полезная.
DF>>> Граблей слишком много, зачастую проще немного додумать
DF>>> архитектуру проекта.
DL>> Продумать архитектуру - это завсегда хорошо :-) Hасчет граблей - не
DL>> знаю, активно mix-in'ы не юзал.
DF> В VB6 активно на них приходилось наступать. Там вроде особых гиморов
DF> необратимых не было.
Будь точнее. В VB6 активно наступал на грабли с чем?
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
09 Янв 04, в 09:00, *Andrei N. Sobchuck* писал я к _Dmitry Feodorov_:
DL>>>>> интерфейсов, и особых проблем это не вызывает. Хотя mix-in'ы
DL>>>>> порой вещь несомненно полезная.
DF>>>> Граблей слишком много, зачастую проще немного додумать
DF>>>> архитектуру проекта.
DL>>> Продумать архитектуру - это завсегда хорошо :-) Hасчет граблей -
DL>>> не знаю, активно mix-in'ы не юзал.
DF>> В VB6 активно на них приходилось наступать. Там вроде особых
DF>> гиморов необратимых не было.
AS> Будь точнее. В VB6 активно наступал на грабли с чем?
Pеализация нескольких интерфейсов объектом.
Выявлено следующее, хотя может мне надо настроить нормально в ряде мест
ruki.sys:
1) Hе всегда обработчик соответствует ожидаемому.
2) Был ряд трабл в реализации моделирования наследования в VB, правда выше
трех уровней в иерархии забираться не стал, т.к. кол-во служебного кода
становится слишком большое.
Был еще большой гимор с системой обработки событий, о котором я здесь
недавно писал.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Andrei N. Sobchuck
DL>>>> не знаю, активно mix-in'ы не юзал.
DF>>> В VB6 активно на них приходилось наступать. Там вроде особых
DF>>> гиморов необратимых не было.
AS>> Будь точнее. В VB6 активно наступал на грабли с чем?
DF> Pеализация нескольких интерфейсов объектом.
Какое отношение имеют mix-in к реализации нескольких интерфейсов объектом?
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
12 Янв 04, в 13:43, *Andrei N. Sobchuck* писал я к _Dmitry Feodorov_:
DS>>> Язык на смену ++ уже нужен. Доколе заниматься всяким дурдомом
DS>>> вроде шаблонов? Жабу и шарп не предлагать, это смена паскаля.
DF>> Ждемс...
AS> Может для начала посмотреть то, что уже существует [кроме жабы, плюсов
AS> и шарпа]?
May be, хотя пока и VB.NET вполне хватает, т.е. я хочу сказать, что острой
потребности на данный момент в этом нет, но через какое-то время она появится.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Dmitry Lapshin
Приветствую тебя, Dmitry!
08 Янв 04 22:43, Dmitry Feodorov wrote to Dmitry Lapshin:
DL>> Продумать архитектуру - это завсегда хорошо :-) Hасчет граблей -
DL>> не знаю, активно mix-in'ы не юзал.
DF> В VB6 активно на них приходилось наступать. Там вроде особых гиморов
DF> необратимых не было.
А как в VB6 можно было юзать mix-in'ы, если там наследования *вообще* не было
как такового?! :-( )
С уважением, Dmitry Lapshin aka X-CODE
... В разрезах домов, в паутинах сетей скорость тока совпадает с моей (с) Био
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
15 Янв 04, в 17:55, *Dmitry Lapshin* писал я к _Dmitry Feodorov_:
DL>>> Продумать архитектуру - это завсегда хорошо :-) Hасчет граблей -
DL>>> не знаю, активно mix-in'ы не юзал.
DF>> В VB6 активно на них приходилось наступать. Там вроде особых
DF>> гиморов необратимых не было.
DL> А как в VB6 можно было юзать mix-in'ы, если там наследования *вообще*
DL> не было как такового?! :-( )
Hаследование можно здорово эмулировать. Об этом я уже писал.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]