Rules.
Ivan Kuvshinov
Поместите, пожалуйста, правила в эхоконференцию. Если их нет, то желательно
об этом узнать.
КИА
Serguei Tarassov
На сообщение к All от 12 декабря 2003:
IK> Поместите, пожалуйста, правила в эхоконференцию. Если их нет, то
IK> желательно
IK> об этом узнать.
Ни разу не видел.
Общие правила: в интеллигентной учОной беседе обсуждается дизайн и
ОО-технологии, а также реализации в виде ОО-сред и языков.
--
Сергей Тарасов
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Ivan kuvshinov
ST> Общие правила: в интеллигентной учОной беседе обсуждается дизайн и
ST> ОО-технологии, а также реализации в виде ОО-сред и языков.
Понятно, буду подписываться. А Moderator, есть?
КИА
Serguei Tarassov
На сообщение к Serguei Tarassov от 13 декабря 2003:
Ik> Понятно, буду подписываться. А Moderator, есть?
Тоже ни разу не видел :)
Vladimir Provorov
13 Дек 03 17:57, Ivan kuvshinov wrote to Serguei Tarassov:
ST>> Общие правила: в интеллигентной учОной беседе обсуждается дизайн и
ST>> ОО-технологии, а также реализации в виде ОО-сред и языков.
Ik> Понятно, буду подписываться. А Moderator, есть?
Хто здесь??? :-)
А ОО= Объектно-ориентированное?
Vladimir
Ivan Kuvshinov
VP> А ОО= Объектно-ориентированное?
Ага! И, сейчас, какраз, приток подписчиков. :D
КИА
Ivan Kuvshinov
Ik> Понятно, буду подписываться.
Так, хде народ-то, а то - никак..
КИА
Yury Kotov
23 Дек 03 года (17:57)
Ivan Kuvshinov в своем письме к Ivan kuvshinov писал:
Ik>> Понятно, буду подписываться.
IK> Так, хде народ-то, а то - никак..
И правда. Hеужели столь непопулярная область знания...
Yury.
Ivan Kuvshinov
Может они все окопались в эхах, типа Ru.Visual.CPP, Ru.Delphi, Ru.SmallTalk -
и не кажут носа?
Примечание: ну, вот - дошла.
КИА
Alexei Vasiliev
═══[24 Дек 03 22:40], Yury Kotov ══ Ivan Kuvshinov:
YK> Здравствуй, Ivan!
YK> 23 Дек 03 года (17:57)
YK> Ivan Kuvshinov в своем письме к Ivan kuvshinov писал:
Ik>>> Понятно, буду подписываться.
IK>> Так, хде народ-то, а то - никак..
YK> И правда. Hеужели столь непопулярная область знания...
профессионалам обычно не о чем говорить
а если почитать с гугла архив то тут проходили достаточно интересные дискуссии
│ ___ │
av ║_/\_/\_║
∙──┬──┬─══І══[ (-<+>-)=]══І══─┬──┬──∙
* ^ ■ ╘══╛ ╘══╛ ■ ^ *
──────────────────────────────────────────────────────────────
Один человек - уже слишком много, чтобы изменить мир.
Ivan Kuvshinov
Профессионалам-то, всегда есть о чём поговорить - главное, их от дела
оторвать. :)
Hапример: в Ru.Program.Games и в Ru.Game.Design, иногда, проскакивают толковые
(на мой взгляд) письма на предмет идеологии ООП.
КИА
Alexander Gribanov
Однажды, 24 Дек 03 в 22:40, Yury Kotov писал Ivan Kuvshinov:
YK> И правда. Hеужели столь непопулярная область знания...
Хм. Область знания может и популярная, только вот говорить, когда никто не
о чем не спрашивает, - довольно таки сложное дело. А еще сложнее спрашивать,
когда не знаешь о чем спросить ;)
Hе прощаюсь, Alexander Gribanov.
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
26 Дек 03, в 07:36, *Alexander Gribanov* писал я к _Yury Kotov_:
YK>> И правда. Hеужели столь непопулярная область знания...
AG> Хм. Область знания может и популярная, только вот говорить, когда
AG> никто не о чем не спрашивает, - довольно таки сложное дело. А еще
AG> сложнее спрашивать, когда не знаешь о чем спросить ;)
А здесь имеются подписчика, которые могут ответить?
Если да, то вопрос: Hа сколько обосновано применение делегатов в слое
бизнеслогики в сравнении с агрегацией?
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Ivan Kuvshinov
AG> никто не о чем не спрашивает, - довольно таки сложное дело. А еще
AG> сложнее спрашивать, когда не знаешь о чем спросить ;)
Это верно, особенно последнее. Расскажите кто-нибудь, про шаблоны, темплеты
(не знаю как правильно) и множественное наследование (в частности когда оба
предка имеют почти эквивалентные методы из которых создаётся третий).
Собственно, имеют ли они отношение к ООП, или это, только, особенности
конкретного языка?
КИА
Andrei N. Sobchuck
DF> Если да, то вопрос: Hа сколько обосновано применение делегатов в слое
DF> бизнеслогики в сравнении с агрегацией?
что за "делегаты"?
--
Andrei N.Sobchuck
JabberID: and...@jabber.ru. ICQ UIN: 46466235.
Andrei N. Sobchuck
IK> Собственно, имеют ли они отношение к ООП, или это, только, особенности
IK> конкретного языка?
и первое и второе - особенности конкретного языка.
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
28 Дек 03, в 16:53, *Andrei N. Sobchuck* писал я к _Ivan Kuvshinov_:
IK>> Собственно, имеют ли они отношение к ООП, или это, только,
IK>> особенности конкретного языка?
AS> и первое и второе - особенности конкретного языка.
Множественное наследование используется во многих языках. Я думаю идею шаблонов
через какое-то время ждет такая же судьба.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
28 Дек 03, в 16:53, *Andrei N. Sobchuck* писал я к _Dmitry Feodorov_:
DF>> Если да, то вопрос: Hа сколько обосновано применение делегатов в
DF>> слое бизнеслогики в сравнении с агрегацией?
AS> что за "делегаты"?
Делегирование, т.е. run-time связывание объекта с исполнителями тех или иных
необходимых ему операций. Естественно делегатами могут быть объекты различных
классов, не имеющих общих наследников, а только отвечающие интересующему
интерфейсу.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
28 Дек 03, в 02:27, *Ivan Kuvshinov* писал я к _Alexander Gribanov_:
AG>> Хм. Область знания может и популярная, только вот говорить,
AG>> когда никто не о чем не спрашивает, - довольно таки сложное дело.
AG>> А еще сложнее спрашивать, когда не знаешь о чем спросить ;)
IK> Это верно, особенно последнее. Расскажите кто-нибудь, про шаблоны,
IK> темплеты (не знаю как правильно) и множественное наследование (в
IK> частности когда оба предка имеют почти эквивалентные методы из которых
IK> создаётся третий). Собственно, имеют ли они отношение к ООП, или это,
IK> только, особенности конкретного языка?
IMHO, первое - один из способов реализации наследования, ну а второе, это
острая проблема использования ООП. Естественно, ни то ни другое конкретной
особенностью C++ назвать, на мой взгляд, нельзя.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Andrei N. Sobchuck
DF>>> Если да, то вопрос: Hа сколько обосновано применение делегатов в
DF>>> слое бизнеслогики в сравнении с агрегацией?
AS>> что за "делегаты"?
DF> Делегирование, т.е. run-time связывание объекта с исполнителями тех или иных
А почему ты сравниваешь его с агрегацией?
Andrei N. Sobchuck
IK>>> Собственно, имеют ли они отношение к ООП, или это, только,
IK>>> особенности конкретного языка?
AS>> и первое и второе - особенности конкретного языка.
DF> Множественное наследование используется во многих языках. Я думаю идею шаблонов
Множественное наследование, во-первых есть не везде, а, во-вторых,
реализовано по разному.
DF> через какое-то время ждет такая же судьба.
во-первых, шаблоны можно реализовать по-разному,
во-вторых, языкам с динамической типизацией шаблоны ни к чему.
Dmitry Lapshin
Приветствую тебя, Dmitry!
29 Дек 03 00:19, Dmitry Feodorov wrote to Andrei N. Sobchuck:
DF> Множественное наследование используется во многих языках. Я думаю идею
DF> шаблонов через какое-то время ждет такая же судьба.
Да, в C# 2.0 уже обещают. А то без них типизированные коллекции кривовато
выглядят. Что касается множественного наследования - спорный вопрос. В том же
C# разрешено только множественное наследование интерфейсов, и особых проблем
это не вызывает. Хотя mix-in'ы порой вещь несомненно полезная.
С уважением, Dmitry Lapshin aka X-CODE
... Enjoy the vibe just like a tribe (c) DJ Bobo
Ivan Kuvshinov
IK>> наследование (в частности когда оба предка имеют почти
DF> IMHO, первое - один из способов реализации наследования, ну а второе,
DF> это острая проблема использования ООП. Естественно, ни то ни другое
DF> конкретной особенностью C++ назвать, на мой взгляд, нельзя.
И в чём острота проблемы?
КИА
Dmitry Sidoroff
28 Дек 03 00:14, Dmitry Feodorov -> Alexander Gribanov:
YK>>> И правда. Hеужели столь непопулярная область знания...
AG>> Хм. Область знания может и популярная, только вот говорить,
AG>> когда никто не о чем не спрашивает, - довольно таки сложное дело.
AG>> А еще сложнее спрашивать, когда не знаешь о чем спросить ;)
DF> А здесь имеются подписчика, которые могут ответить?
В спячке ;-)
DF> Если да, то вопрос: Hа сколько обосновано применение делегатов в слое
DF> бизнеслогики в сравнении с агрегацией?
Хм. Как тебе удалось заменить агрегацию делегацией?
Это вообще-то препендикулярные понятия.
Dmitry
Dmitry Sidoroff
28 Дек 03 02:27, Ivan Kuvshinov -> Alexander Gribanov:
AG>> Хм. Область знания может и популярная, только вот говорить,
AG>> когда никто не о чем не спрашивает, - довольно таки сложное дело.
AG>> А еще сложнее спрашивать, когда не знаешь о чем спросить ;)
IK> Это верно, особенно последнее. Расскажите кто-нибудь, про шаблоны,
IK> темплеты (не знаю как правильно)
Это малость из другой оперы ООПа. Так называемый generic позволяющий описывать
семейство классов/методов в типизированых языках.
IK> и множественное наследование (в частности когда оба предка имеют
IK> почти эквивалентные методы из которых создаётся третий).
Это исторические грабли. Раздельно объявленые методы надо рассматривать как
разные и следить что бы имена не пересекались.
IK> Собственно, имеют ли они отношение к ООП, или это, только,
IK> особенности конкретного языка?
Имеют.
Dmitry
Alexei Vasiliev
═══[29 Дек 03 00:12], Dmitry Feodorov ══ Andrei N. Sobchuck:
DF>>> Если да, то вопрос: Hа сколько обосновано применение делегатов в
DF>>> слое бизнеслогики в сравнении с агрегацией?
AS>> что за "делегаты"?
DF> Делегирование, т.е. run-time связывание объекта с исполнителями тех
DF> или иных необходимых ему операций. Естественно делегатами могут быть
DF> объекты различных классов, не имеющих общих наследников, а только
DF> отвечающие интересующему интерфейсу.
а агрегация значит статическое связывание ? (я давно банду 4х не читал)
то есть вопрос формулируется так:
динамического связывание vs. статическое связывание
:)
имхо, все зависит от конкретики, при использовании раскладки MVC, бизнес-логика
должна быть достаточно сильно отделена от остального мира. а уже как оно там
внутри работает, здесь требудется доп. информация.
динамическое связывание требудется в тех случаях, когда ты хочешь _в_
_последствии_ менять логику в процессе работы. но при этом поведение системы
будет неопределенное, что не есть гуд
основная математика, имхо должна быть жестко связвязана. или же разнесена на
разные уровни представления данных import/processing/export
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
29 Дек 03, в 08:49, *Andrei N. Sobchuck* писал я к _Dmitry Feodorov_:
DF>>>> Если да, то вопрос: Hа сколько обосновано применение делегатов
DF>>>> в слое бизнеслогики в сравнении с агрегацией?
AS>>> что за "делегаты"?
DF>> Делегирование, т.е. run-time связывание объекта с исполнителями
DF>> тех или иных
AS> А почему ты сравниваешь его с агрегацией?
Потому что для ряда задач эти методики могут в равной степени давать успешные
решения, но в дальнейшем каждая дает свое количество подводных камней. Что ни
есть гуд. Хотелось бы выяснить: Какая из методик дает их наименьшее количество.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
29 Дек 03, в 12:16, *Dmitry Lapshin* писал я к _Dmitry Feodorov_:
DF>> Множественное наследование используется во многих языках. Я думаю
DF>> идею шаблонов через какое-то время ждет такая же судьба.
DL> Да, в C# 2.0 уже обещают. А то без них типизированные коллекции
DL> кривовато выглядят.
Почему?
DL> Что касается множественного наследования - спорный
DL> вопрос. В том же C# разрешено только множественное наследование
DL> интерфейсов, и особых проблем это не вызывает. Хотя mix-in'ы порой
DL> вещь несомненно полезная.
Граблей слишком много, зачастую проще немного додумать архитектуру проекта.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
29 Дек 03, в 08:49, *Andrei N. Sobchuck* писал я к _Dmitry Feodorov_:
IK>>>> Собственно, имеют ли они отношение к ООП, или это, только,
IK>>>> особенности конкретного языка?
AS>>> и первое и второе - особенности конкретного языка.
DF>> Множественное наследование используется во многих языках. Я думаю
DF>> идею шаблонов
AS> Множественное наследование, во-первых есть не везде, а, во-вторых,
AS> реализовано по разному.
Любая из концепций ООП, применительно к конкретным языкам программирования
имеет свою специфику реализации. Hо разве при проектировании не происходит
абстрагирование от конкретного языка?
DF>> через какое-то время ждет такая же судьба.
AS> во-первых, шаблоны можно реализовать по-разному,
AS> во-вторых, языкам с динамической типизацией шаблоны ни к чему.
Pеализация реализацией, а следует рассматривать концепции, не вдаваясь в
детали.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
30 Дек 03, в 00:19, *Alexei Vasiliev* писал я к _Dmitry Feodorov_:
DF>>>> Если да, то вопрос: Hа сколько обосновано применение делегатов
DF>>>> в слое бизнеслогики в сравнении с агрегацией?
AS>>> что за "делегаты"?
DF>> Делегирование, т.е. run-time связывание объекта с исполнителями
DF>> тех или иных необходимых ему операций. Естественно делегатами
DF>> могут быть объекты различных классов, не имеющих общих
DF>> наследников, а только отвечающие интересующему интерфейсу.
AV> а агрегация значит статическое связывание ? (я давно банду 4х не
AV> читал)
AV> то есть вопрос формулируется так:
AV> динамического связывание vs. статическое связывание
AV> :)
Hу примерно так ;)
AV> имхо, все зависит от конкретики, при использовании раскладки MVC,
AV> бизнес-логика должна быть достаточно сильно отделена от остального
AV> мира. а уже как оно там внутри работает, здесь требудется доп.
AV> информация.
AV> динамическое связывание требудется в тех случаях, когда ты хочешь _в_
AV> _последствии_ менять логику в процессе работы. но при этом поведение
AV> системы будет неопределенное, что не есть гуд
А в случае потенциального расширения количества объектов следящих за
определенным параметром?
AV> основная математика, имхо должна быть жестко связвязана. или же
AV> разнесена на разные уровни представления данных
AV> import/processing/export
Это разумеется так.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
29 Дек 03, в 13:54, *Ivan Kuvshinov* писал я к _Dmitry Feodorov_:
IK>>> шаблоны, темплеты (не знаю как правильно) и множественное
IK>>> наследование (в частности когда оба предка имеют почти
DF>> IMHO, первое - один из способов реализации наследования, ну а
DF>> второе, это острая проблема использования ООП. Естественно, ни то
DF>> ни другое конкретной особенностью C++ назвать, на мой взгляд,
DF>> нельзя.
IK> И в чём острота проблемы?
1) Теоритическое обоснование многих аспектов использования множественного
наследования;
2) Pазрешение вопроса о повторном наследовании класса или скрещивание двух
подклассов одного класса.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Ivan Kuvshinov
ANS> реализовано по разному.
Можно привести примеры реализаций?
ANS> во-первых, шаблоны можно реализовать по-разному,
В чём могут различаться реализации шаблонов?
КИА
Ivan Kuvshinov
DS> Это малость из другой оперы ООПа. Так называемый generic позволяющий
DS> описывать семейство классов/методов в типизированых языках.
И чем отличается от виртуальных методов? (прошу прощения за "чайниковый"
вопрос)
КИА
Ivan Kuvshinov
DF> множественного наследования;
DF> 2) Pазрешение вопроса о повторном наследовании класса или скрещивание
DF> двух подклассов одного класса.
Вот в этих местах подробней, пожалуйста, а то я только теоритически знаю, что
не всё гладко.
КИА
Ivan Kuvshinov
DL> C# разрешено только множественное наследование интерфейсов, и особых
DL> проблем это не вызывает. Хотя mix-in'ы порой вещь несомненно полезная.
А что даёт множественное наследование интерфейсов? Чем эти "всё в одном" так
необходимы?
КИА
Alexei Vasiliev
═══[30 Дек 03 10:37], Dmitry Feodorov ══ Alexei Vasiliev:
AV>> то есть вопрос формулируется так:
AV>> динамического связывание vs. статическое связывание
AV>> :)
DF> Hу примерно так ;)
AV>> имхо, все зависит от конкретики, при использовании раскладки MVC,
AV>> бизнес-логика должна быть достаточно сильно отделена от
AV>> остального мира. а уже как оно там внутри работает, здесь
AV>> требудется доп. информация.
AV>> динамическое связывание требудется в тех случаях, когда ты хочешь
AV>> _в_ _последствии_ менять логику в процессе работы. но при этом
AV>> поведение системы будет неопределенное, что не есть гуд
DF> А в случае потенциального расширения количества объектов следящих за
DF> определенным параметром?
следить -> мониторить -> View , это уже другой уровнь, тут можно динамику
следить -> сделать
хотя с другой стороны все числодробительные параметры должны предоставляться
соотв. уровнем и быть жестко связаны с потребителем, иначе будет бардак
AV>> основная математика, имхо должна быть жестко связвязана. или же
AV>> разнесена на разные уровни представления данных
AV>> import/processing/export
DF> Это разумеется так.
│ ___ │
av ║_/\_/\_║
∙──┬──┬─══І══[ (-<+>-)=]══І══─┬──┬──∙
* ^ ■ ╘══╛ ╘══╛ ■ ^ *
──────────────────────────────────────────────────────────────
Если у вас нет проблем - ищите женщину. (Анна де Бейль)
Dmitry Sidoroff
30 Дек 03 18:47, Ivan Kuvshinov -> Dmitry Sidoroff:
IK>>> Расскажите кто-нибудь, про шаблоны, темплеты (не знаю как
IK>>> правильно)
DS>> Это малость из другой оперы ООПа. Так называемый generic
DS>> позволяющий описывать семейство классов/методов в типизированых
DS>> языках.
IK> И чем отличается от виртуальных методов? (прошу прощения за
IK> "чайниковый" вопрос)
Тем что обычный метод имеет один тип, а шаблоный семейство типов.
Dmitry
Ivan Kuvshinov
IK>> "чайниковый" вопрос)
То есть, что-то вроде макросов?
КИА
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
31 Дек 03, в 01:36, *Alexei Vasiliev* писал я к _Dmitry Feodorov_:
AV>>> то есть вопрос формулируется так:
AV>>> динамического связывание vs. статическое связывание
AV>>> :)
DF>> Hу примерно так ;)
AV>>> имхо, все зависит от конкретики, при использовании раскладки
AV>>> MVC, бизнес-логика должна быть достаточно сильно отделена от
AV>>> остального мира. а уже как оно там внутри работает, здесь
AV>>> требудется доп. информация.
AV>>> динамическое связывание требудется в тех случаях, когда ты
AV>>> хочешь _в_ _последствии_ менять логику в процессе работы. но при
AV>>> этом поведение системы будет неопределенное, что не есть гуд
DF>> А в случае потенциального расширения количества объектов следящих
DF>> за определенным параметром?
AV> следить -> мониторить -> View , это уже другой уровнь, тут можно
AV> динамику сделать
А если требуются горизонтальные связи в слое бизнеслогики?
AV> хотя с другой стороны все числодробительные параметры должны
AV> предоставляться соотв. уровнем и быть жестко связаны с потребителем,
AV> иначе будет бардак
А если параметры спископодобные и на их основе формируется дальнейшая обработка
данных?
AV>>> основная математика, имхо должна быть жестко связвязана. или же
AV>>> разнесена на разные уровни представления данных
AV>>> import/processing/export
DF>> Это разумеется так.
AV> │ ___ │
AV> av ║_/\_/\_║
AV> ∙──┬──┬─══І══[ (-<+>-)=]══І══─┬──┬──∙
AV> * ^ ■ ╘══╛ ╘══╛ ■ ^ *
AV> ──────────────────────────────────────────────────────────────
AV> Если у вас нет проблем - ищите женщину. (Анна де Бейль)
AV> ---
AV> * Origin: SpaceBase mail station. St.Petersburg (2:5030/644)
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
30 Дек 03, в 18:43, *Ivan Kuvshinov* писал я к _Dmitry Feodorov_:
DF>> 1) Теоритическое обоснование многих аспектов использования
DF>> множественного наследования;
DF>> 2) Pазрешение вопроса о повторном наследовании класса или
DF>> скрещивание двух подклассов одного класса.
IK> Вот в этих местах подробней, пожалуйста, а то я только теоритически
IK> знаю, что не всё гладко.
Hу, банальная вещь: есть Класс А, у него наследники Подкласс Б и подкласс В, в
обоих независимо реализован интерфейс Г, таким образом, если произвести
множественное наследование с Б и В в роли суперклассов, то происходит путаница
в том, какая из реализаций интерфейса Г будет использоваться.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
30 Дек 03, в 20:59, *Ivan Kuvshinov* писал я к _Dmitry Lapshin_:
DL>> Что касается множественного наследования - спорный вопрос. В том
DL>> же C# разрешено только множественное наследование интерфейсов, и
DL>> особых проблем это не вызывает. Хотя mix-in'ы порой вещь
DL>> несомненно полезная.
IK> А что даёт множественное наследование интерфейсов? Чем эти "всё в
IK> одном" так необходимы?
Скорее уместен здесь термин реализация интерфейсов, а это уже очевидно для чего
нужно: например, 1 объект несколько возможных ролей.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Andrei N. Sobchuck
DF> Потому что для ряда задач эти методики могут в равной степени давать успешные
DF> решения, но в дальнейшем каждая дает свое количество подводных камней. Что ни
DF> есть гуд. Хотелось бы выяснить: Какая из методик дает их наименьшее количество.
Честно говоря, не совсем ясно в чем вопрос. Делегирование - это (наряду с
наследованием) один из способов построения иерархии.
Соответсвенно, подход тот же, что и при выборе "наследование против агрегации"
Andrei N. Sobchuck
DF> Любая из концепций ООП, применительно к конкретным языкам программирования
DF> имеет свою специфику реализации. Hо разве при проектировании не происходит
DF> абстрагирование от конкретного языка?
Не уверен, что этого можно достичь
Dmitry Sidoroff
01 Янв 04 17:09, Ivan Kuvshinov -> Dmitry Sidoroff:
IK>>> И чем отличается от виртуальных методов? (прошу прощения за
IK>>> "чайниковый" вопрос)
DS>> Тем что обычный метод имеет один тип, а шаблоный семейство типов.
IK> То есть, что-то вроде макросов?
Hу разьве что их следующая инкарнация ;-)
Шаблоны в отличии от макросов
1. встроены в синтаксис
2. имеют ограничения на тип аргумента. В ++ неявные.
Dmitry
Andrei N. Sobchuck
ANS>> Множественное наследование, во-первых есть не везде, а, во-вторых,
ANS>> реализовано по разному.
Разруливать конфликты, которые возникают при МН можно разными способами.
По этому у каждого языка есть свои особенности.
Почитай, например, про C++, Eiffel, Self, CLOS.
ANS>> во-первых, шаблоны можно реализовать по-разному,
IK> В чём могут различаться реализации шаблонов?
Например:
http://longhorn.msdn.microsoft.com/lhsdk/ndp/vclrfdifferencesbetweenctemplatescgenerics.aspx
Alexei Vasiliev
═══[03 Янв 04 00:22], Dmitry Feodorov ══ Alexei Vasiliev:
DF>>> А в случае потенциального расширения количества объектов
DF>>> следящих за определенным параметром?
AV>> следить -> мониторить -> View , это уже другой уровнь, тут можно
AV>> динамику сделать
DF> А если требуются горизонтальные связи в слое бизнеслогики?
тогда выделяй объекты данных и все-равно жестко связывай с ними :
Data data;
DataProvider( &data );
DataClient1( &data );
DataClient2( &data );
в этом случае поставщик данных будет один, на одном уровне обработки, а
потребителей несколько, но вся иерархия взаимодействия должна быть жестко
прописана
...хм. вариант:
Data data;
if ( expr ) DataProvider1( &data); //import+processing
else DataProvider1( &data );
DataClient1( &data ); //view+import2(next level) - filter(?)
DataClient2( &data );
AV>> хотя с другой стороны все числодробительные параметры должны
AV>> предоставляться соотв. уровнем и быть жестко связаны с
AV>> потребителем, иначе будет бардак
DF> А если параметры спископодобные и на их основе формируется дальнейшая
DF> обработка данных?
имхо, тут стоит описать в виде тестов все возможные модели поведения системы,
а _потом_ их закодировать. это будет самый правильный метод определения
требуемой архитектуры
если возникает куча "если", тогда пришло время каждое "если" закодировать
тестом. USE CASES блин :)
Test Infected │ ___ │
av ║_/\_/\_║
∙──┬──┬─══І══[ (-<+>-)=]══І══─┬──┬──∙
* ^ ■ ╘══╛ ╘══╛ ■ ^ *
──────────────────────────────────────────────────────────────
Обычно люди так гордятся тем, что они "говорят то, что думают", что считают,
их это полностью освобождает от обязанности думать, что они говорят.
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
03 Янв 04, в 20:00, *Andrei N. Sobchuck* писал я к _Dmitry Feodorov_:
DF>> Любая из концепций ООП, применительно к конкретным языкам
DF>> программирования имеет свою специфику реализации. Hо разве при
DF>> проектировании не происходит абстрагирование от конкретного
DF>> языка?
AS> Hе уверен, что этого можно достичь
Hа 100% ты этого никогда не достигнешь, но стремиться увеличить эту цифру,
imho, крайне желательно.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
04 Янв 04, в 01:26, *Alexei Vasiliev* писал я к _Dmitry Feodorov_:
DF>>>> А в случае потенциального расширения количества объектов
DF>>>> следящих за определенным параметром?
AV>>> следить -> мониторить -> View , это уже другой уровнь, тут
AV>>> можно динамику сделать
DF>> А если требуются горизонтальные связи в слое бизнеслогики?
AV> тогда выделяй объекты данных и все-равно жестко связывай с ними :
AV> Data data;
AV> DataProvider( &data );
AV> DataClient1( &data );
AV> DataClient2( &data );
AV> в этом случае поставщик данных будет один, на одном уровне обработки,
AV> а потребителей несколько, но вся иерархия взаимодействия должна быть
AV> жестко прописана
AV> ...хм. вариант:
AV> Data data;
AV> if ( expr ) DataProvider1( &data); //import+processing
AV> else DataProvider1( &data );
AV> DataClient1( &data ); //view+import2(next level) - filter(?)
AV> DataClient2( &data );
В данных примерах есть значительный минус: мы получили кучу неявных связей,
которые ни коим образом полностью не отслеживаются в программе, т.е у нас есть
статическое связывание при куче необределенности. ИМХО, тут лучше использовать
динамику, т.к. там хот определенность границ переменчивости имеется.
AV>>> хотя с другой стороны все числодробительные параметры должны
AV>>> предоставляться соотв. уровнем и быть жестко связаны с
AV>>> потребителем, иначе будет бардак
DF>> А если параметры спископодобные и на их основе формируется
DF>> дальнейшая обработка данных?
AV> имхо, тут стоит описать в виде тестов все возможные модели поведения
AV> системы, а _потом_ их закодировать. это будет самый правильный метод
AV> определения требуемой архитектуры
А это можно поподробнее, т.к. я чего-то не въехал в твою мысль. Или мы не про
проектирование говорим?
AV> если возникает куча "если", тогда пришло время каждое "если"
AV> закодировать тестом. USE CASES блин :)
Hу без этого, естественно, при кодировании уже никак.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
03 Янв 04, в 20:00, *Andrei N. Sobchuck* писал я к _Dmitry Feodorov_:
DF>> Потому что для ряда задач эти методики могут в равной степени
DF>> давать успешные решения, но в дальнейшем каждая дает свое
DF>> количество подводных камней. Что ни есть гуд. Хотелось бы
DF>> выяснить: Какая из методик дает их наименьшее количество.
AS> Честно говоря, не совсем ясно в чем вопрос. Делегирование - это
AS> (наряду с наследованием) один из способов построения
AS> иерархии.
В любом таком выборе есть плюсы у одного, плюсы у другого. Так вот хотелось бы
обсудить их список при сравнении данных технологий.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Andrei N. Sobchuck
DF> В любом таком выборе есть плюсы у одного, плюсы у другого. Так вот хотелось бы
DF> обсудить их список при сравнении данных технологий.
Вопроса я не понимаю потому, что, afaik, выбора нет.
Есть либо наследование, либо делегирование.
Если я не прав, то хочется узнать какой язык поддерживает
оба механизма.
А агрегация vs. наследование(делегирование) штука описанная
(у Буча, например. или вот дискуссия -
http://www.c2.com/cgi/wiki?CompositionInsteadOfInheritance).
кстати. вот тут http://ooad.asf.ru/standarts/uml/spr/Delegation.asp
написано, что делегацию можно реализовать ввиде ассоциации. Так это
смотря что понимать под делегированием. Если рассматривать в
контексте диспетчеризации сообщений, то в чистом виде не получится.
Можно реализовать только пересылку сообщений aka "redirection"
или "forwarding"
Alexei Vasiliev
═══[04 Янв 04 13:00], Dmitry Feodorov ══ Alexei Vasiliev:
DF>>>>> А в случае потенциального расширения количества объектов
DF>>>>> следящих за определенным параметром?
AV>>>> следить -> мониторить -> View , это уже другой уровнь, тут
AV>>>> можно динамику сделать
DF>>> А если требуются горизонтальные связи в слое бизнеслогики?
AV>> тогда выделяй объекты данных и все-равно жестко связывай с ними :
AV>> Data data;
AV>> DataProvider( &data );
AV>> DataClient1( &data );
AV>> DataClient2( &data );
AV>> в этом случае поставщик данных будет один, на одном уровне
AV>> обработки, а потребителей несколько, но вся иерархия
AV>> взаимодействия должна быть жестко прописана
AV>> ...хм. вариант:
AV>> Data data;
AV>> if ( expr ) DataProvider1( &data); //import+processing
AV>> else DataProvider1( &data );
AV>> DataClient1( &data ); //view+import2(next level) - filter(?)
AV>> DataClient2( &data );
DF> В данных примерах есть значительный минус: мы получили кучу неявных
DF> связей, которые ни коим образом полностью не отслеживаются в
DF> программе, т.е у нас есть статическое связывание при куче
DF> необределенности.
почему же неопределенность? в 1 все определено и видно в коде и на диаграмме,
но следующая итерация примера 2 (см ниже) лучше
DF> ИМХО, тут лучше использовать динамику, т.к. там хот
DF> определенность границ переменчивости имеется.
1. напиши тесты поведения. снимется куча проблем
2.
во втором примере конечно есть неопределенность, но в реальности этот механизм
работает очень устойчиво, там правда чуть по другому:
Data data, data1, data2;
Provider1( &data1 ); //import
Provider2( &data2 );
if ( expr) data = data1;
else data = data2;
Client1( &data );
Client2( &data );
в этом случае можно независимо мониторить 2 канала:
View( &data1 );
View( &data2 );
AV>>>> хотя с другой стороны все числодробительные параметры должны
AV>>>> предоставляться соотв. уровнем и быть жестко связаны с
AV>>>> потребителем, иначе будет бардак
DF>>> А если параметры спископодобные и на их основе формируется
DF>>> дальнейшая обработка данных?
AV>> имхо, тут стоит описать в виде тестов все возможные модели
AV>> поведения системы, а _потом_ их закодировать. это будет самый
AV>> правильный метод определения требуемой архитектуры
DF> А это можно поподробнее, т.к. я чего-то не въехал в твою мысль. Или мы
DF> не про проектирование говорим?
именно про проектирование, есть механизм разработки TestDrivenDevelopment
(TDD). так вот с момента его внедрения, я стал видеть архитектуру проекта
намного более четче еще до написания "прямого" кода.
именно этот механизм позволяет исходить из требований, а не наоборот
AV>> если возникает куча "если", тогда пришло время каждое "если"
AV>> закодировать тестом. USE CASES блин :)
DF> Hу без этого, естественно, при кодировании уже никак.
но кодировать становится намного проще, когда есть тест
проверяющий/подтвержающий каждое "если"
Test Infected │ ___ │
av ║_/\_/\_║
∙──┬──┬─══І══[ (-<+>-)=]══І══─┬──┬──∙
* ^ ■ ╘══╛ ╘══╛ ■ ^ *
──────────────────────────────────────────────────────────────
В мире нет ничего невозможного. Ести вещи которые требуют больших или меньших
усилий и сопровождаются большим или меньшим риском. (Мастер Дракон)
Michael E. Demichev
DF> 1) Теоритическое обоснование многих аспектов использования множественного
DF> наследования;
А что там обосновывать? Все и так ясно.
DF> 2) Pазрешение вопроса о повторном наследовании класса или скрещивание двух
DF> подклассов одного класса.
ИМХО это не проблема Мн как такового, а проблема реализации МН в
конкретном языке.
--
С уважением,
Михаил
Ivan Kuvshinov
DF>>> множественного наследования;
DF>>> 2) Pазрешение вопроса о повторном наследовании класса или
DF>>> скрещивание двух подклассов одного класса.
IK>> Вот в этих местах подробней, пожалуйста, а то я только
DF> Hу, банальная вещь: есть Класс А, у него наследники Подкласс Б и
Это я, примерно, представляю. Hо говорилось о "многих аспектах" во первых, а
во вторых, почему это множественое наследие нужно вообще (раз уж это проблемное
место) и второй пункт в частности.
КИА
Ivan Kuvshinov
IK>> Можно привести примеры реализаций?
Это вообще реально, в общем случае?
AS> http://longhorn.msdn.microsoft.com/lhsdk/ndp/vclrfdifferencesbetweenct
AS> emplatescgenerics.aspx
Довольно "завёрнутая" ссылочка. Hа досуге посмотрю, правда английский и Си - я
не понимаю ;).
КИА
Ivan Kuvshinov
DS> 2. имеют ограничения на тип аргумента. В ++ неявные.
В чём и как эти ограничения проявляются?
КИА
Ivan Kuvshinov
DF> Скорее уместен здесь термин реализация интерфейсов, а это уже очевидно
DF> для чего нужно: например, 1 объект несколько возможных ролей.
Потенциальных, иначе это - не ООП.?
То есть некое улучшение, позволяющее передать то, как стоит строить программу
(интерфейсы), паразитируя на иделогии ООП, создаёт ей проблему и указывает на
затруднения в реализации, одновременно суля всякие вкусности (потому как
множественное наследие интерфейсов это естествено, для самого их понятия)?
КИА
Andrei N. Sobchuck
IK>>> Можно привести примеры реализаций?
AS>> Разруливать конфликты, которые возникают при МH можно разными
Если бы было реально, то не существовало бы разных реализаций.
Действительно разных. То есть, одна и та же иерархия тупо переложенная
на языках будет вести себя по-разному (если вообще заведётся).
--
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, в 06:31, *Ivan Kuvshinov* писал я к _Dmitry Feodorov_:
IK>>> А что даёт множественное наследование интерфейсов? Чем эти "всё
IK>>> в одном" так необходимы?
DF>> Скорее уместен здесь термин реализация интерфейсов, а это уже
DF>> очевидно для чего нужно: например, 1 объект несколько возможных
DF>> ролей.
IK> Потенциальных, иначе это - не ООП.?
Hа 90% да, в ряде случаев допустимые отклонения уместны, например, когда один
объект-диспетчер подставляется как объект-билдер в несколько других системных
классов.
IK> То есть некое улучшение, позволяющее передать то, как стоит строить
IK> программу (интерфейсы), паразитируя на иделогии ООП, создаёт ей
IK> проблему и указывает на затруднения в реализации,
По подребнее это раскрыть можно?
IK> одновременно суля всякие вкусности (потому как множественное наследие
IK> интерфейсов это естествено, для самого их понятия)?
Да вкусностей мало. Интерфейс - замена абстрактному классу. И на 99.9% эти
понятия тождественны. Дальнейшее есть не везде и часто, как говорится, от
лукавого.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
05 Янв 04, в 06:39, *Ivan Kuvshinov* писал я к _Dmitry Feodorov_:
DF>>>> 1) Теоритическое обоснование многих аспектов использования
DF>>>> множественного наследования;
DF>>>> 2) Pазрешение вопроса о повторном наследовании класса или
DF>>>> скрещивание двух подклассов одного класса.
IK>>> Вот в этих местах подробней, пожалуйста, а то я только
IK>>> теоритически знаю, что не всё гладко.
DF>> Hу, банальная вещь: есть Класс А, у него наследники Подкласс Б и
IK> Это я, примерно, представляю.
IK> Hо говорилось о "многих аспектах" во первых,
IK> а во вторых, почему это множественое наследие нужно вообще
IK> (раз уж это проблемное место) и второй пункт в частности.
Во второй части фразы ты ответил на вопрос в первой.
Я просто понял, что ты задаешь вопрос по пункту 2.
По п.1 есть прооблемы в обосновании методик использования множественного
наследования, которые были придуманы.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
05 Янв 04, в 01:14, *Alexei Vasiliev* писал я к _Dmitry Feodorov_:
DF>>>>>> А в случае потенциального расширения количества объектов
DF>>>>>> следящих за определенным параметром?
AV>>>>> следить -> мониторить -> View , это уже другой уровнь, тут
AV>>>>> можно динамику сделать
DF>>>> А если требуются горизонтальные связи в слое бизнеслогики?
AV>>> тогда выделяй объекты данных и все-равно жестко связывай с ними
AV>>> : Data data;
AV>>> DataProvider( &data );
AV>>> DataClient1( &data );
AV>>> DataClient2( &data );
AV>>> в этом случае поставщик данных будет один, на одном уровне
AV>>> обработки, а потребителей несколько, но вся иерархия
AV>>> взаимодействия должна быть жестко прописана
AV>>> ...хм. вариант:
AV>>> Data data;
AV>>> if ( expr ) DataProvider1( &data); //import+processing
AV>>> else DataProvider1( &data );
AV>>> DataClient1( &data ); //view+import2(next level) - filter(?)
AV>>> DataClient2( &data );
DF>> В данных примерах есть значительный минус: мы получили кучу
DF>> неявных связей, которые ни коим образом полностью не
DF>> отслеживаются в программе, т.е у нас есть статическое связывание
DF>> при куче необределенности.
AV> почему же неопределенность? в 1 все определено и видно в коде и на
AV> диаграмме, но следующая итерация примера 2 (см ниже) лучше
А ежели рассматривать более сложные случаи, то это 100% грабли и даже TDD не
поможет. Примерно такая вещь была у меня реализована в одном проекте, но там
этот принцип был реализован по всей программе, а не в конкретных методах. В
итоге 2 недели разработки 1 рабочей беты, месяц отладки и понимание
необходимости полной переделки принципа диспетчеризации.
Imho, все-таки необходимо каким-то образом сделать инкапсуляцию данных, что в
данном примере сделать крайне сложно по-прямому, а неопределенности держать на
уровне методов а не иерархий объектов. Это менее гибкий механизм, но он
позволяет снизить время отладки.
DF>> ИМХО, тут лучше использовать динамику, т.к. там хот
DF>> определенность границ переменчивости имеется.
AV> 1. напиши тесты поведения. снимется куча проблем
AV> 2.во втором примере конечно есть неопределенность, но в реальности
AV> этот механизм работает очень устойчиво, там правда чуть по другому:
В таком коде при кол-ве обработчиков более 10 тесты как правило не помогают.
AV> Data data, data1, data2;
AV> Provider1( &data1 ); //import
AV> Provider2( &data2 );
AV> if ( expr) data = data1;
AV> else data = data2;
AV> Client1( &data );
AV> Client2( &data );
AV> в этом случае можно независимо мониторить 2 канала:
AV> View( &data1 );
AV> View( &data2 );
AV>>>>> хотя с другой стороны все числодробительные параметры должны
AV>>>>> предоставляться соотв. уровнем и быть жестко связаны с
AV>>>>> потребителем, иначе будет бардак
DF>>>> А если параметры спископодобные и на их основе формируется
DF>>>> дальнейшая обработка данных?
AV>>> имхо, тут стоит описать в виде тестов все возможные модели
AV>>> поведения системы, а _потом_ их закодировать. это будет самый
AV>>> правильный метод определения требуемой архитектуры
DF>> А это можно поподробнее, т.к. я чего-то не въехал в твою мысль.
DF>> Или мы не про проектирование говорим?
AV> именно про проектирование, есть механизм разработки
AV> TestDrivenDevelopment (TDD). так вот с момента его внедрения, я стал
AV> видеть архитектуру проекта намного более четче еще до написания
AV> "прямого" кода.
Так что мы делаем: задаю вопрос еще раз пишем код или разрабатываем логическую
структуру проекта? afaik первое, а ты говоришь про второе.
AV> именно этот механизм позволяет исходить из требований, а не наоборот
Hе всегда требования на первой итерации на 100% выяснены, но это не повод,
imho, забивать полностью на архитектуру проекта, отмахиваясь Unit- и
приемочными тестами.
AV>>> если возникает куча "если", тогда пришло время каждое "если"
AV>>> закодировать тестом. USE CASES блин :)
DF>> Hу без этого, естественно, при кодировании уже никак.
AV> но кодировать становится намного проще, когда есть тест
AV> проверяющий/подтвержающий каждое "если"
С этим я тоже не спорю. Да, кстати, а как тестить User Interface под GUI
наилучшим образом? Я пока для себя решения еще не нашел (платформа: .NET)
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
05 Янв 04, в 07:33, *Michael E. Demichev* писал я к _Dmitry Feodorov_:
DF>> 1) Теоритическое обоснование многих аспектов использования
DF>> множественного наследования;
MD> А что там обосновывать? Все и так ясно.
И что объекты типа "нечто летающее" тоже ясно с какого бока в объекты отнесено?
DF>> 2) Pазрешение вопроса о повторном наследовании класса или
DF>> скрещивание двух подклассов одного класса.
MD> ИМХО это не проблема Мн как такового, а проблема реализации МH в
MD> конкретном языке.
Hо из-за этого возникают проблемы в реализации логического проектирования.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Ivan Kuvshinov
IK>> создаёт ей проблему и указывает на затруднения в реализации,
DF> По подребнее это раскрыть можно?
Если честно - сам теперь не пойму, что хотел сказать.. %)
Hаверное то, что интерфейсы представлиют то, как это будет развиваться, а
множественное наследование то, как это могло бы быть, а поскольку этого не
было, но близко, то почему бы не слепить - ну и что, что "нарезка", зато
работает?
КИА
Ivan Kuvshinov
IK>> (раз уж это проблемное место) и второй пункт в частности.
DF> Я просто понял, что ты задаешь вопрос по пункту 2.
DF> По п.1 есть прооблемы в обосновании методик использования
DF> множественного наследования, которые были придуманы.
Из всего, я только понял, что множественное наследие - это камень
преткновения, который обойти можно только уловками, но он нужен и проявляется и
в более мягких случаях.
Так вот, какие существуют методики (уловки), для обеспечения приемлемой работы
програм, могущих затронуть множественное наследие, тьфу - наследование :).
КИА
Alexei Vasiliev
═══[06 Янв 04 09:52], Dmitry Feodorov ══ Alexei Vasiliev:
DF>>>>>>> А в случае потенциального расширения количества объектов
DF>>>>>>> следящих за определенным параметром?
AV>>>>>> следить -> мониторить -> View , это уже другой уровнь, тут
AV>>>>>> можно динамику сделать
DF>>>>> А если требуются горизонтальные связи в слое бизнеслогики?
AV>>>> тогда выделяй объекты данных и все-равно жестко связывай с ними
AV>>>> : Data data;
AV>>>> DataProvider( &data );
AV>>>> DataClient1( &data );
AV>>>> DataClient2( &data );
AV>>>> в этом случае поставщик данных будет один, на одном уровне
AV>>>> обработки, а потребителей несколько, но вся иерархия
AV>>>> взаимодействия должна быть жестко прописана
AV>>>> ...хм. вариант:
AV>>>> Data data;
AV>>>> if ( expr ) DataProvider1( &data); //import+processing
AV>>>> else DataProvider1( &data );
AV>>>> DataClient1( &data ); //view+import2(next level) - filter(?)
AV>>>> DataClient2( &data );
DF>>> В данных примерах есть значительный минус: мы получили кучу
DF>>> неявных связей, которые ни коим образом полностью не
DF>>> отслеживаются в программе, т.е у нас есть статическое связывание
DF>>> при куче необределенности.
AV>> почему же неопределенность? в 1 все определено и видно в коде и
AV>> на диаграмме, но следующая итерация примера 2 (см ниже) лучше
DF> А ежели рассматривать более сложные случаи, то это 100% грабли и даже
DF> TDD не поможет.
тут уже нужен UML :)
DF> Примерно такая вещь была у меня реализована в одном
DF> проекте, но там этот принцип был реализован по всей программе, а не в
DF> конкретных методах. В итоге 2 недели разработки 1 рабочей беты, месяц
DF> отладки и понимание необходимости полной переделки принципа
DF> диспетчеризации.
н-да.. нельзя же так сразу. но в моем случае этот подход обоснован языком,
ANSI C , поэтому и пришлось моделировать ОО через явный this
DF> Imho, все-таки необходимо каким-то образом сделать
DF> инкапсуляцию данных, что в данном примере сделать крайне сложно
DF> по-прямому, а неопределенности держать на уровне методов а не иерархий
DF> объектов. Это менее гибкий механизм, но он позволяет снизить время
DF> отладки.
логично, у меня в проекте неопределенность (выбор поставщика) вынесена вообще
на уровень принятия решения
DF>>> ИМХО, тут лучше использовать динамику, т.к. там хот
DF>>> определенность границ переменчивости имеется.
AV>> 1. напиши тесты поведения. снимется куча проблем
AV>> 2.во втором примере конечно есть неопределенность, но в
AV>> реальности этот механизм работает очень устойчиво, там правда
AV>> чуть по другому:
DF> В таком коде при кол-ве обработчиков более 10 тесты как правило не
DF> помогают.
смотря как писать их. задача тестов показать/подтвердить:
1. правильность расчета data1 и data2 (test1, test2)
2. правильность выбора (test3)
3. реакцию клиента1 на data (test4..5)
4. реакцию клиента2 на data (test6..10)
итого 10 тестов перекрывающих пример 3
...ооп-с... из теста 3 следует что выбор источника(data) нужно реализовать
методом (приколы TDD 8-)
.... стоп. что тв имееш ввиду под "обработчиком" ??
"поставщик" данных или "потребитель" ? если поставщик то см. выше 1, если
потребитель то смотри (выше) 3,4,...
AV>> Data data, data1, data2;
AV>> Provider1( &data1 ); //import
AV>> Provider2( &data2 );
selectSource( &data, &data1, &data2 );
AV>> Client1( &data );
AV>> Client2( &data );
AV>> в этом случае можно независимо мониторить 2 канала:
AV>> View( &data1 );
AV>> View( &data2 );
AV>>>>>> хотя с другой стороны все числодробительные параметры должны
AV>>>>>> предоставляться соотв. уровнем и быть жестко связаны с
AV>>>>>> потребителем, иначе будет бардак
DF>>>>> А если параметры спископодобные и на их основе формируется
DF>>>>> дальнейшая обработка данных?
AV>>>> имхо, тут стоит описать в виде тестов все возможные модели
AV>>>> поведения системы, а _потом_ их закодировать. это будет самый
AV>>>> правильный метод определения требуемой архитектуры
DF>>> А это можно поподробнее, т.к. я чего-то не въехал в твою мысль.
DF>>> Или мы не про проектирование говорим?
AV>> именно про проектирование, есть механизм разработки
AV>> TestDrivenDevelopment (TDD). так вот с момента его внедрения, я
AV>> стал видеть архитектуру проекта намного более четче еще до
AV>> написания "прямого" кода.
DF> Так что мы делаем: задаю вопрос еще раз пишем код или разрабатываем
DF> логическую структуру проекта? afaik первое, а ты говоришь про второе.
код зависит от вопроса, но если этот вопрос выразить тестом то будет минимум
кода обеспечивающего правильный ответ на вопрос. при расширении, ты задаешь
второй вопрос (тест) и дополняешь/рефакториш код так чтобы он отвечал "верно"
на оба вопроса (теста)
для удобства рефакторинга можно:
1. нарисовать логическую структуру модуля/подсистемы
2. сделать рисунок красивым
3. модифицировать код в соответсвии с рисунком.
4. существующие тесты подтвердят правильность работы программы
если рисунок красивый (!), то код тоже будет ясным и понятным
AV>> именно этот механизм позволяет исходить из требований, а не
AV>> наоборот
DF> Hе всегда требования на первой итерации на 100% выяснены, но это не
DF> повод, imho, забивать полностью на архитектуру проекта, отмахиваясь
DF> Unit- и приемочными тестами.
если правильно писать модульные тесты, то и архитектура бедет правильной,
но ,имхо, для того чтобы правильно написать модульные тесты нужно правильно все
_нарисовать_ .
рисунок проекта - метафора
рисунок подсистемы/модуля - схема взаимодействия 2..5 блоков (модулей)
притча из жизни:
Когда я начинал разработку одного крупного проекта (RTX, чип 1839,...), я
начитался кучу хороших книжек по дизайну и уже имел опыт разработки с
собиранием граблей из за плохого дизайна. Я до начала кодирования нарисовал
схему всего проекта, сделал приблизительный каркас основной программы, расписал
что и на каком уровне должно быть и тд.
но программа начала писаться с простого теста запускаемого на целевой
платформе, потом в этот простой код стали добавляться другие существующие
(разработанные до меня) компоненты. В результате , сейчас, дизайн проекта
совсем не похож на задуманный (и никогда небыл похож), но при этом он
обеспечивает расширение и легкую проверку всех подсистем. а также позволяет
делать то что я в него не закладывал.
Отсюда вывод: что не стоит делать детальную проработку дизайна проекта сначала.
достаточно всего лишь общего наброска MVC. Более конкретная проработка нужна
уже при реализации конкретного уровня или подсистемы.
..ой блин, какое ДАО загнал :)
AV>>>> если возникает куча "если", тогда пришло время каждое "если"
AV>>>> закодировать тестом. USE CASES блин :)
DF>>> Hу без этого, естественно, при кодировании уже никак.
AV>> но кодировать становится намного проще, когда есть тест
AV>> проверяющий/подтвержающий каждое "если"
DF> С этим я тоже не спорю. Да, кстати, а как тестить User Interface под
DF> GUI наилучшим образом?
поправка: как дизайнить интерфейс :)
DF> Я пока для себя решения еще не нашел (платформа: .NET)
плохо искал :)
если архитектура MVC:
1. все события от View идут на вектора Controller или модели. (direct)
2. все что нужно View он _сам_ берет у Model (polling)
3. основной цикл работы View такой: -DDX-Show-WaitEvent-
4. имеем:
void testModelAsView()
{
/*
после ввода числа в поле ввода, должны получить значение OK если оно в
диапазоне
1..100
*/
model.setValue( 10 ); TS_ASSERT( model.sucess() == OK);
model.setValue( 110 ); TS_ASSERT( model.sucess() != OK );
/*
model.SetValue() - метод который дернется по нажатию enter в поле ввода (или
DDX)
model.sucess() - метод который сообщит View что нужно рисовать
*/
}
void testViewAsModel()
{
model.SetValue( 10 );
//сообщили TS что хотим проверить view
TS_ASSERT_VIEW( "должно оторазить OK", &view );
model.SetValue( 110 );
TS_ASSERT_VIEW( "не должно оторазить OK", &view );
/*
TS_ASSERT_VIEW( comment, ViewObject* ) - свой макрос умеющий отображать:
коментарий, две кнопки OK/FAILED и GUI обьект (ViewObject) с симуляцией
нормального пуска
объект model для этого теста можно заменить тестовым наследником, например для
автоматизированного прогона всех возможных вариантов
*/
}
первый тест проверяет логику модели в зависимости от пользователя,
второй тест проверяет правильность индикации на различных режимах работы, в том
числе и димических
так как интерфейс пользовательский то пользоватлю и придется его тестить :(
обычно этим занимаются группы верификации. потому что "Вид" как его не крути
воспринимается только глазами. машине пофиг, ей только xml , имхо можно
скормить, и то не факт что это будет то что ты хотел
..и кука в тему попалась %)
│ ___ │
av ║_/\_/\_║
∙──┬──┬─══І══[ (-<+>-)=]══І══─┬──┬──∙
* ^ ■ ╘══╛ ╘══╛ ■ ^ *
──────────────────────────────────────────────────────────────
Делать ошибки может любой, но делать это пpофессионально - единицы. (c) DmS
Alexei Vasiliev
═══[29 Дек 03 00:12], Dmitry Feodorov ══ Andrei N. Sobchuck:
DF>>> Если да, то вопрос: Hа сколько обосновано применение делегатов в
DF>>> слое бизнеслогики в сравнении с агрегацией?
AS>> что за "делегаты"?
DF> Делегирование, т.е. run-time связывание объекта с исполнителями тех
DF> или иных необходимых ему операций. Естественно делегатами могут быть
DF> объекты различных классов, не имеющих общих наследников, а только
DF> отвечающие интересующему интерфейсу.
гы.. сейчас открыл банду 4х, долго (3 минуты :) думал, но так и непонял
в каком шаблоне затык
1. у тебя "исполнитель " это:
по поведению:
- команда, обычно набор классов обеспечения действия. (созд. дин.)
- посетитель, один класс делающий что-то для многих
- посредник, знает все о всех, и все знают его, но никто не знает соседа
- состояние, обычно набор обьектов - моделей поведения обьекта
или другое?
по стуктуре:
- фасад, делает один интерфейс к разробленной подсистеме
- прокси , наследует интерфейс базового и замещает обьект базового для контрол
доступа
- декоратор, прокси только с расширенным интерфейсом
- мост, разделяет абстракцию от реализации
- адаптер, адаптирует интерфейс обьекта под требуемый (почти прокси)
или другое?
2. какой механизм у тебя применяется в этой самой бизнес-логике?
3. "run-time связывание объекта" кем ? кто связывает?
4. кто такая у тебя "бизнес-логика" ? вот у меня это числодробилка! :)
а то, имхо, мы совсем от темы удались..
кста: в примере 3 (в другом письме), SelectSource() - по шаблону стратегия
а Data - посредник, тк никто не знает "папу" :)
..н-да вторая неделя выходных, скоро опять дома кодировать начну..
│ ___ │
av ║_/\_/\_║
∙──┬──┬─══І══[ (-<+>-)=]══І══─┬──┬──∙
* ^ ■ ╘══╛ ╘══╛ ■ ^ *
──────────────────────────────────────────────────────────────
Писатель умирает, когда он больше ничего не может сказать. (с)unknown
Dmitry Sidoroff
05 Янв 04 06:41, Ivan Kuvshinov -> Dmitry Sidoroff:
DS>>>> Тем что обычный метод имеет один тип, а шаблоный семейство
DS>>>> типов.
DS>> 2. имеют ограничения на тип аргумента. В ++ неявные.
IK> В чём и как эти ограничения проявляются?
В требуемых методах. В других языках есть и более продвинутые возможности
работы именно с типом аргументов.
Generic препендикулярен ООПе. Это возможность работать с множествами статически
типизированных функций/классов.
К макросам это не сводимо потому что макропроцесор ничего не знает о типах.
Dmitry
Ivan Kuvshinov
DS> возможности работы именно с типом аргументов.
DS> К макросам это не сводимо потому что макропроцесор ничего не знает о
DS> типах.
Понятно.
КИА
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
07 Янв 04, в 01:52, *Ivan Kuvshinov* писал я к _Dmitry Feodorov_:
IK>>> а во вторых, почему это множественое наследие нужно вообще
IK>>> (раз уж это проблемное место) и второй пункт в частности.
DF>> Во второй части фразы ты ответил на вопрос в первой.
DF>> Я просто понял, что ты задаешь вопрос по пункту 2.
DF>> По п.1 есть прооблемы в обосновании методик использования
DF>> множественного наследования, которые были придуманы.
IK> Из всего, я только понял, что множественное наследие - это камень
IK> преткновения, который обойти можно только уловками, но он нужен и
IK> проявляется и в более мягких случаях. Так вот, какие существуют
IK> методики (уловки), для обеспечения приемлемой работы програм, могущих
IK> затронуть множественное наследие, тьфу - наследование :).
Методика одна: изменение дерева классов и замена связей, реализуемых
множественным наследованием на агрегирование. Это менее наглядно в ряде
случаев, но позволяет сэкономить нервы, время и мозги для других вещей.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
07 Янв 04, в 02:46, *Ivan Kuvshinov* писал я к _Dmitry Feodorov_:
IK>>> То есть некое улучшение, позволяющее передать то, как стоит
IK>>> строить программу (интерфейсы), паразитируя на иделогии ООП,
IK>>> создаёт ей проблему и указывает на затруднения в реализации,
DF>> По подребнее это раскрыть можно?
IK> Если честно - сам теперь не пойму, что хотел сказать.. %)
Бывает...
IK> Hаверное то, что интерфейсы представлиют то, как это будет
IK> развиваться,
Интерфейсы скорее стандартизуют внешний вид объекта в программе, что дает
возможность программе не зависеть от реализации конкретного класса.
IK> а множественное наследование то, как это могло бы быть, а
IK> поскольку этого не было, но близко
А близко-ли? Hаследование, пускай и множественное, - это перенесение
родителя(ей) в потомок, что зачастую уместно. А интерфейс _только_
стандартизует способ обращения к функциональности объекта.
IK> , то почему бы не слепить - ну и
IK> что, что "нарезка", зато работает?
IMHO, интерфейсы нужны для абстрагирования от реализаций объектов, т.е. в
большинстве задач это понятие близкое абстрактному классу.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Andrei N. Sobchuck
DF> IMHO, интерфейсы нужны для абстрагирования от реализаций объектов, т.е. в
Если не брать во-внимание теоретические выгоды (типа документирование кода
и т.д.), то есть очень прагматическая причина, по-которой без
интерфейсов будет тяжело. А именно - строгая типизация.
Как минимум в Жаву добавляли их для того, чтобы "обойти" ограничения
на тип переменной в условиях одиночного наследования..
DF> большинстве задач это понятие близкое абстрактному классу.
Почти.
Ivan Kuvshinov
IK>> поскольку этого не было, но близко
DF> родителя(ей) в потомок, что зачастую уместно. А интерфейс _только_
DF> стандартизует способ обращения к функциональности объекта.
Ok
КИА
Ivan Kuvshinov
DF> множественным наследованием на агрегирование. Это менее наглядно в
Переходим к агрегированию - что за зверь?
КИА
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
07 Янв 04, в 02:05, *Alexei Vasiliev* писал я к _Dmitry Feodorov_:
DF>>>> Если да, то вопрос: Hа сколько обосновано применение делегатов
DF>>>> в слое бизнеслогики в сравнении с агрегацией?
AS>>> что за "делегаты"?
DF>> Делегирование, т.е. run-time связывание объекта с исполнителями
DF>> тех или иных необходимых ему операций. Естественно делегатами
DF>> могут быть объекты различных классов, не имеющих общих
DF>> наследников, а только отвечающие интересующему интерфейсу.
AV> гы.. сейчас открыл банду 4х, долго (3 минуты :) думал, но так и
AV> непонял в каком шаблоне затык
В данный момент GOF под рукой нет, по-этому обрисую задачу в общем:
AV> 1. у тебя "исполнитель " это:
AV> по поведению:
AV> - посетитель, один класс делающий что-то для многих
В общем-то это выработка методов воздействия на данные
AV> по стуктуре:
AV> - фасад, делает один интерфейс к разробленной подсистеме
Хотя скорее это extender
AV> 2. какой механизм у тебя применяется в этой самой бизнес-логике?
AV> 3. "run-time связывание объекта" кем? кто связывает?
Связывание осуществляется либо вышестоящим объектом (т.е. объектом, в списке
которого данный объект находится) либо специальным builderoм
AV> 4. кто такая у тебя "бизнес-логика" ? вот у меня это числодробилка! :)
Обработка списков, графики, числовуха.
AV> а то, имхо, мы совсем от темы удались..
В общем-то да...
AV> ..н-да вторая неделя выходных, скоро опять дома кодировать начну..
А у меня сессия, так что не попрограмить нормально... =(
AV> Писатель умирает, когда он больше ничего не может сказать. (с)unknown
А программист, когда ничего больше не может написать ;)
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
07 Янв 04, в 00:41, *Alexei Vasiliev* писал я к _Dmitry Feodorov_:
DF>>>>>>>> А в случае потенциального расширения количества объектов
DF>>>>>>>> следящих за определенным параметром?
AV>>>>>>> следить -> мониторить -> View , это уже другой уровнь, тут
AV>>>>>>> можно динамику сделать
DF>>>>>> А если требуются горизонтальные связи в слое бизнеслогики?
AV>>>>> тогда выделяй объекты данных и все-равно жестко связывай с
AV>>>>> ними
AV>>>>> : Data data;
AV>>>>> DataProvider( &data );
AV>>>>> DataClient1( &data );
AV>>>>> DataClient2( &data );
AV>>>>> в этом случае поставщик данных будет один, на одном уровне
AV>>>>> обработки, а потребителей несколько, но вся иерархия
AV>>>>> взаимодействия должна быть жестко прописана
AV>>>>> ...хм. вариант:
AV>>>>> Data data;
AV>>>>> if ( expr ) DataProvider1( &data); //import+processing
AV>>>>> else DataProvider1( &data );
AV>>>>> DataClient1( &data ); //view+import2(next level) - filter(?)
AV>>>>> DataClient2( &data );
DF>>>> В данных примерах есть значительный минус: мы получили кучу
DF>>>> неявных связей, которые ни коим образом полностью не
DF>>>> отслеживаются в программе, т.е у нас есть статическое
DF>>>> связывание при куче необределенности.
AV>>> почему же неопределенность? в 1 все определено и видно в коде и
AV>>> на диаграмме, но следующая итерация примера 2 (см ниже) лучше
DF>> А ежели рассматривать более сложные случаи, то это 100% грабли и
DF>> даже TDD не поможет.
AV> тут уже нужен UML :)
UML это инструмент сильный, но он не поможет при траблах реализаций.
DF>> Примерно такая вещь была у меня реализована в одном
DF>> проекте, но там этот принцип был реализован по всей программе, а
DF>> не в конкретных методах. В итоге 2 недели разработки 1 рабочей
DF>> беты, месяц отладки и понимание необходимости полной переделки
DF>> принципа диспетчеризации.
AV> н-да.. нельзя же так сразу. но в моем случае этот подход обоснован
AV> языком, ANSI C , поэтому и пришлось моделировать ОО через явный this
Hу тогда ясно. В той модели VB задавал тоже вполне нормальный интерфейс, но
сработала житейская мудрость: Любую идею за n действий можно свести к абсурду.
DF>> Imho, все-таки необходимо каким-то образом сделать
DF>> инкапсуляцию данных, что в данном примере сделать крайне сложно
DF>> по-прямому, а неопределенности держать на уровне методов а не
DF>> иерархий объектов. Это менее гибкий механизм, но он позволяет
DF>> снизить время отладки.
AV> логично, у меня в проекте неопределенность (выбор поставщика) вынесена
AV> вообще на уровень принятия решения
Hо механизм защиты все равно не будет лишним.
DF>>>> ИМХО, тут лучше использовать динамику, т.к. там хот
DF>>>> определенность границ переменчивости имеется.
AV>>> 1. напиши тесты поведения. снимется куча проблем
AV>>> 2.во втором примере конечно есть неопределенность, но в
AV>>> реальности этот механизм работает очень устойчиво, там правда
AV>>> чуть по другому:
DF>> В таком коде при кол-ве обработчиков более 10 тесты как правило
DF>> не помогают.
AV> смотря как писать их. задача тестов показать/подтвердить:
AV> 1. правильность расчета data1 и data2 (test1, test2)
AV> 2. правильность выбора (test3)
AV> 3. реакцию клиента1 на data (test4..5)
AV> 4. реакцию клиента2 на data (test6..10)
AV> итого 10 тестов перекрывающих пример 3
AV> ...ооп-с... из теста 3 следует что выбор источника(data) нужно
AV> реализовать методом (приколы TDD 8-)
AV> .... стоп. что тв имееш ввиду под "обработчиком" ??
AV> "поставщик" данных или "потребитель" ? если поставщик то см. выше 1,
AV> если потребитель то смотри (выше) 3,4,...
Вся фича в том, что любой из объектов в теории может менять данные в объекте, и
при кол-ве параметров, которые можно изменять ~ 50 получается большой гимор.
AV>>> Data data, data1, data2;
AV>>> Provider1( &data1 ); //import
AV>>> Provider2( &data2 );
AV> selectSource( &data, &data1, &data2 );
AV>>> Client1( &data );
AV>>> Client2( &data );
AV>>> в этом случае можно независимо мониторить 2 канала:
AV>>> View( &data1 );
AV>>> View( &data2 );
AV>>>>>>> хотя с другой стороны все числодробительные параметры должны
AV>>>>>>> предоставляться соотв. уровнем и быть жестко связаны с
AV>>>>>>> потребителем, иначе будет бардак
DF>>>>>> А если параметры спископодобные и на их основе формируется
DF>>>>>> дальнейшая обработка данных?
AV>>>>> имхо, тут стоит описать в виде тестов все возможные модели
AV>>>>> поведения системы, а _потом_ их закодировать. это будет самый
AV>>>>> правильный метод определения требуемой архитектуры
DF>>>> А это можно поподробнее, т.к. я чего-то не въехал в твою мысль.
DF>>>> Или мы не про проектирование говорим?
AV>>> именно про проектирование, есть механизм разработки
AV>>> TestDrivenDevelopment (TDD). так вот с момента его внедрения, я
AV>>> стал видеть архитектуру проекта намного более четче еще до
AV>>> написания "прямого" кода.
DF>> Так что мы делаем: задаю вопрос еще раз пишем код или
DF>> разрабатываем логическую структуру проекта? afaik первое, а ты
DF>> говоришь про второе.
AV> код зависит от вопроса, но если этот вопрос выразить тестом то будет
AV> минимум кода обеспечивающего правильный ответ на вопрос. при
AV> расширении, ты задаешь второй вопрос (тест) и дополняешь/рефакториш
AV> код так чтобы он отвечал "верно" на оба вопроса (теста)
Вопрос в том, что это решение - имитация ООП в структурном языке, в ОО языке
данная архитектура, скорее всего, неприемлема, т.к. существуют более сильные
варианты. Вот собственно все, что я хотел сказать всеми этими вопросами, и то,
что проектирование и тесты в общем-то две разные вещи, которые перемешивать в
одну кучу не стоит.
AV>>> именно этот механизм позволяет исходить из требований, а не
AV>>> наоборот
DF>> Hе всегда требования на первой итерации на 100% выяснены, но это
DF>> не повод, imho, забивать полностью на архитектуру проекта,
DF>> отмахиваясь Unit- и приемочными тестами.
AV> если правильно писать модульные тесты, то и архитектура бедет
AV> правильной, но ,имхо, для того чтобы правильно написать модульные
AV> тесты нужно правильно все _нарисовать_ . рисунок проекта -
AV> метафора рисунок подсистемы/модуля - схема взаимодействия 2..5 блоков
AV> (модулей)
Так собственно вопрос в том, как производить корректнее разделение
функциональности по модулям.
AV> притча из жизни:
AV> Когда я начинал разработку одного крупного проекта (RTX, чип
AV> 1839,...), я начитался кучу хороших книжек по дизайну и уже имел опыт
AV> разработки с собиранием граблей из за плохого дизайна. Я до начала
AV> кодирования нарисовал схему всего проекта, сделал приблизительный
AV> каркас основной программы, расписал что и на каком уровне должно быть
AV> и тд. но программа начала писаться с простого теста запускаемого на
AV> целевой платформе, потом в этот простой код стали добавляться другие
AV> существующие (разработанные до меня) компоненты. В результате ,
AV> сейчас, дизайн проекта совсем не похож на задуманный (и никогда небыл
AV> похож), но при этом он обеспечивает расширение и легкую проверку всех
AV> подсистем. а также позволяет делать то что я в него не закладывал.
AV> Отсюда вывод: что не стоит делать детальную проработку дизайна проекта
AV> сначала. достаточно всего лишь общего наброска MVC. Более конкретная
AV> проработка нужна уже при реализации конкретного уровня или подсистемы.
А ее и не сделать никогда или ты не согласен? ;)
AV> ..ой блин, какое ДАО загнал :)
Да... бывает.
AV>>>>> если возникает куча "если", тогда пришло время каждое "если"
AV>>>>> закодировать тестом. USE CASES блин :)
DF>>>> Hу без этого, естественно, при кодировании уже никак.
AV>>> но кодировать становится намного проще, когда есть тест
AV>>> проверяющий/подтвержающий каждое "если"
DF>> С этим я тоже не спорю. Да, кстати, а как тестить User Interface
DF>> под GUI наилучшим образом?
AV> поправка: как дизайнить интерфейс :)
DF>> Я пока для себя решения еще не нашел (платформа: .NET)
AV> плохо искал :)
Пока еще обхожусь, но вскоре вопрос встанет ребром, т.к. UI достатьчно
гиморойный получается. =(
AV> если архитектура MVC:
AV> 1. все события от View идут на вектора Controller или модели. (direct)
AV> 2. все что нужно View он _сам_ берет у Model (polling)
AV> 3. основной цикл работы View такой: -DDX-Show-WaitEvent-
AV> 4. имеем:
AV> void testModelAsView()
AV> {
AV> /*
AV> после ввода числа в поле ввода, должны получить значение OK если оно в
AV> диапазоне 1..100 */
AV> model.setValue( 10 ); TS_ASSERT( model.sucess() == OK);
AV> model.setValue( 110 ); TS_ASSERT( model.sucess() != OK );
AV> /*
AV> model.SetValue() - метод который дернется по нажатию enter в поле
AV> ввода (или DDX)
AV> model.sucess() - метод который сообщит View что нужно рисовать
AV> */
AV> }
AV> void testViewAsModel()
AV> {
AV> model.SetValue( 10 );
AV> //сообщили TS что хотим проверить view
AV> TS_ASSERT_VIEW( "должно оторазить OK", &view );
AV> model.SetValue( 110 );
AV> TS_ASSERT_VIEW( "не должно оторазить OK", &view );
AV> /*
AV> TS_ASSERT_VIEW( comment, ViewObject* ) - свой макрос умеющий
AV> отображать: коментарий, две кнопки OK/FAILED и GUI обьект (ViewObject)
AV> с симуляцией нормального пуска
Мне надо, чтоб данные вставлялись в контрол извне программы, а не из кода, т.к.
часть контролов своих с отрисовкой из кода. Понятно, что анализировать
результаты надо самому, но вот тыкать по сто раз в одни и те же кнопки слегка
запарно, особенно когда кнопок и их заменителей много. =(
AV> так как интерфейс пользовательский то пользоватлю и придется его
AV> тестить :( обычно этим занимаются группы верификации.
В данном случае таких групп особенно нет. Конечно вид форм есть кому показать,
но вот тестирование всех контролов, в том числе корректный ввод в них - гимор.
AV> потому что "Вид"
AV> как его не крути воспринимается только глазами. машине пофиг, ей
AV> только xml , имхо можно скормить, и то не факт что это будет то что ты
AV> хотел
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Michael E. Demichev
DF> DF>> 1) Теоритическое обоснование многих аспектов использования
DF> DF>> множественного наследования;
DF> MD> А что там обосновывать? Все и так ясно.
DF> И что объекты типа "нечто летающее" тоже ясно с какого бока в объекты отнесено?
Извини, не понял совершенно.
DF> DF>> 2) Pазрешение вопроса о повторном наследовании класса или
DF> DF>> скрещивание двух подклассов одного класса.
DF> MD> ИМХО это не проблема Мн как такового, а проблема реализации МH в
DF> MD> конкретном языке.
DF> Hо из-за этого возникают проблемы в реализации логического проектирования.
Если при использовании МН возникают проблемы, значит неправильно
используется МН :)
--
С уважением,
Михаил
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
07 Янв 04, в 23:43, *Ivan Kuvshinov* писал я к _Dmitry Feodorov_:
DF>> Методика одна: изменение дерева классов и замена связей,
DF>> реализуемых множественным наследованием на агрегирование. Это
DF>> менее наглядно в
IK> Переходим к агрегированию - что за зверь?
Статический вызов сервиса, представляемого объектом через его интерфейс.
(Сервис может предствалять не простой вызов метода, а сценарий использования).
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Alexei Vasiliev
═══[08 Янв 04 01:23], Dmitry Feodorov ══ Alexei Vasiliev:
AV>>>> почему же неопределенность? в 1 все определено и видно в коде и
AV>>>> на диаграмме, но следующая итерация примера 2 (см ниже) лучше
DF>>> А ежели рассматривать более сложные случаи, то это 100% грабли и
DF>>> даже TDD не поможет.
AV>> тут уже нужен UML :)
DF> UML это инструмент сильный, но он не поможет при траблах реализаций.
возможно, но когда делаешь с кода рисунок, а с рисунка код , получается очень
даже неплохо :)
DF>>> Примерно такая вещь была у меня реализована в одном
DF>>> проекте, но там этот принцип был реализован по всей программе, а
DF>>> не в конкретных методах. В итоге 2 недели разработки 1 рабочей
DF>>> беты, месяц отладки и понимание необходимости полной переделки
DF>>> принципа диспетчеризации.
AV>> н-да.. нельзя же так сразу. но в моем случае этот подход
AV>> обоснован языком, ANSI C , поэтому и пришлось моделировать ОО
AV>> через явный this
DF> Hу тогда ясно. В той модели VB задавал тоже вполне нормальный
DF> интерфейс, но сработала житейская мудрость: Любую идею за n действий
DF> можно свести к абсурду.
дык :)))
DF>>> Imho, все-таки необходимо каким-то образом сделать
DF>>> инкапсуляцию данных, что в данном примере сделать крайне сложно
DF>>> по-прямому, а неопределенности держать на уровне методов а не
DF>>> иерархий объектов. Это менее гибкий механизм, но он позволяет
DF>>> снизить время отладки.
AV>> логично, у меня в проекте неопределенность (выбор поставщика)
AV>> вынесена вообще на уровень принятия решения
DF> Hо механизм защиты все равно не будет лишним.
вариант.
DF>>>>> ИМХО, тут лучше использовать динамику, т.к. там хот
DF>>>>> определенность границ переменчивости имеется.
AV>>>> 1. напиши тесты поведения. снимется куча проблем
AV>>>> 2.во втором примере конечно есть неопределенность, но в
AV>>>> реальности этот механизм работает очень устойчиво, там правда
AV>>>> чуть по другому:
DF>>> В таком коде при кол-ве обработчиков более 10 тесты как правило
DF>>> не помогают.
skipped
DF> Вся фича в том, что любой из объектов в теории может менять данные в
DF> объекте, и при кол-ве параметров, которые можно изменять ~ 50
DF> получается большой гимор.
ключевое слово: "в теории" , а ты напиши тесты сдля того что на практике
сначала тесты интерфейса показывающие как его юзать, а потом тесты поведения
демонтрирующие ту или иную модель поведения
а если стоять и рассужать. то конечно все будет плохо. может стоит набраться
храбрости сесть и сделать?
у меня в системе тоже дофига параметров, и чтобы проверить изменения 1..2 нужно
писать оверхед для установки значений 10 , но зато я могу имея тест сэкономить
время на отладке ибо проверяется _конкретное_ поведение в _конкретном_ месте
[skip]
DF>>> Так что мы делаем: задаю вопрос еще раз пишем код или
DF>>> разрабатываем логическую структуру проекта? afaik первое, а ты
DF>>> говоришь про второе.
AV>> код зависит от вопроса, но если этот вопрос выразить тестом то
AV>> будет минимум кода обеспечивающего правильный ответ на вопрос.
AV>> при расширении, ты задаешь второй вопрос (тест) и
AV>> дополняешь/рефакториш код так чтобы он отвечал "верно" на оба
AV>> вопроса (теста)
DF> Вопрос в том, что это решение - имитация ООП в структурном языке, в ОО
DF> языке данная архитектура, скорее всего, неприемлема, т.к. существуют
DF> более сильные варианты.
не всегда, вышеприведенный код не сильно будет отличаться для с++ :
class Data{ public: virtual vood impor()=0; };
class Data1 : Data{...} data1;
data1.import();
data2.import();
Data* pData = strategy.select(&data1, &data2);
client1( pData );
client2( pData );
клиенты всеравно будут работать с каким-то обьектом данных
DF> Вот собственно все, что я хотел сказать всеми
DF> этими вопросами, и то, что проектирование и тесты в общем-то две
DF> разные вещи, которые перемешивать в одну кучу не стоит.
нет!, это взаимодополняющие вещи. потому что интерфейс и архитектура
спроектированная на бумаге в коде выгдялит совсем не так (есть опыт).
а интерфейс спроектированный с помощью теста дает именно то что нужно (!)
при этом тест (как в моем примере) оказывает существенное влияние на
архитектуру модуля выделяя или гася акценты на некоторых моментах
AV>>>> именно этот механизм позволяет исходить из требований, а не
AV>>>> наоборот
DF>>> Hе всегда требования на первой итерации на 100% выяснены, но это
DF>>> не повод, imho, забивать полностью на архитектуру проекта,
DF>>> отмахиваясь Unit- и приемочными тестами.
AV>> если правильно писать модульные тесты, то и архитектура бедет
AV>> правильной, но ,имхо, для того чтобы правильно написать модульные
AV>> тесты нужно правильно все _нарисовать_ . рисунок проекта -
AV>> метафора рисунок подсистемы/модуля - схема взаимодействия 2..5
AV>> блоков (модулей)
DF> Так собственно вопрос в том, как производить корректнее разделение
DF> функциональности по модулям.
1. уровни взаимодействия (iso osi for example :)
2. логические подсистемы (кредитные карты это вам не наличность)
3. модели поведения
обычно все видно в общем рисунке кто где и как
AV>> притча из жизни:
[skip]
AV>> Отсюда вывод: что не стоит делать детальную проработку дизайна
AV>> проекта сначала. достаточно всего лишь общего наброска MVC. Более
AV>> конкретная проработка нужна уже при реализации конкретного уровня
AV>> или подсистемы.
DF> А ее и не сделать никогда или ты не согласен? ;)
почему же? было бы желание!
AV>> ..ой блин, какое ДАО загнал :)
DF> Да... бывает.
дык ;)
AV>>>>>> если возникает куча "если", тогда пришло время каждое "если"
AV>>>>>> закодировать тестом. USE CASES блин :)
DF>>>>> Hу без этого, естественно, при кодировании уже никак.
AV>>>> но кодировать становится намного проще, когда есть тест
AV>>>> проверяющий/подтвержающий каждое "если"
DF>>> С этим я тоже не спорю. Да, кстати, а как тестить User Interface
DF>>> под GUI наилучшим образом?
AV>> поправка: как дизайнить интерфейс :)
DF>>> Я пока для себя решения еще не нашел (платформа: .NET)
AV>> плохо искал :)
DF> Пока еще обхожусь, но вскоре вопрос встанет ребром, т.к. UI достатьчно
DF> гиморойный получается. =(
я знаю, это всегда так
[skip]
AV>> void testViewAsModel()
AV>> {
SCRIPT{ //metacode ;)
FOCUS( ID_OK ),
KBD(LEFT),
KBD(LEFT),
KBD('A')
KBD(ENTER)
MOUSE_FOCUS( OK_CANCEL )
MOUSE( LEFT )
}
AV>> model.SetValue( 10 );
AV>> //сообщили TS что хотим проверить view
AV>> TS_ASSERT_VIEW( "должно оторазить OK", &view );
AV>> model.SetValue( 110 );
TS_ASSERT_VIEW( "не должно оторазить OK", &view, SCRIPT );
AV>> /*
AV>> TS_ASSERT_VIEW( comment, ViewObject* ) - свой макрос умеющий
AV>> отображать: коментарий, две кнопки OK/FAILED и GUI обьект
AV>> (ViewObject) с симуляцией нормального пуска
DF> Мне надо, чтоб данные вставлялись в контрол извне программы, а не из
DF> кода, т.к. часть контролов своих с отрисовкой из кода. Понятно, что
DF> анализировать результаты надо самому, но вот тыкать по сто раз в одни
DF> и те же кнопки слегка запарно, особенно когда кнопок и их заменителей
DF> много. =(
а что мешает из тестового треда посылать в систему евенты
фокуса/клавиатуры/мышки ?? Control Agent же это умеет! а тут у тебя свой же
код
AV>> так как интерфейс пользовательский то пользоватлю и придется его
AV>> тестить :( обычно этим занимаются группы верификации.
DF> В данном случае таких групп особенно нет. Конечно вид форм есть кому
DF> показать, но вот тестирование всех контролов, в том числе корректный
DF> ввод в них - гимор.
см выше, это просто :) только нужно 2 (а может и 1) идеальных дня потратить
чтобы сделать движок в первой редакции
у меня вот система работает с stdin/stdout но мне лениво картинки тестировать
:( хотя скоро уже придется это делать, причина есть :)
│ ___ │
av ║_/\_/\_║
∙──┬──┬─══І══[ (-<+>-)=]══І══─┬──┬──∙
* ^ ■ ╘══╛ ╘══╛ ■ ^ *
──────────────────────────────────────────────────────────────
Неужели вам действительно нужно убить человека, чтобы понять что он живой?
Alexei Vasiliev
═══[07 Янв 04 23:43], Ivan Kuvshinov ══ Dmitry Feodorov:
DF>> Методика одна: изменение дерева классов и замена связей,
DF>> реализуемых множественным наследованием на агрегирование. Это
DF>> менее наглядно в
IK> Переходим к агрегированию - что за зверь?
см мое письмо про архитектуру и шаблоны
│ ___ │
av ║_/\_/\_║
∙──┬──┬─══╤══[ (-<+>-)=]══╤══─┬──┬──∙
* ^ ■ ╘══╛ ╘══╛ ■ ^ *
──────────────────────────────────────────────────────────────
Парадокс изобретателя: "более общую проблему обычно решить проще".
Alexei Vasiliev
═══[08 Янв 04 01:45], Dmitry Feodorov ══ Alexei Vasiliev:
DF>>>>> Если да, то вопрос: Hа сколько обосновано применение делегатов
DF>>>>> в слое бизнеслогики в сравнении с агрегацией?
AS>>>> что за "делегаты"?
DF>>> Делегирование, т.е. run-time связывание объекта с исполнителями
DF>>> тех или иных необходимых ему операций. Естественно делегатами
DF>>> могут быть объекты различных классов, не имеющих общих
DF>>> наследников, а только отвечающие интересующему интерфейсу.
чего-то устял я, открываем банду 4х (паттерны проектирования):
агрегированный объект - объект представленный из подобъектов. подобъекты
называются частями агрегата. агрегат отвечает за их.
делегирование - механизм реализации, при котором объект перенаправляет или
"делегирует" запрос другому объекту который выполняет этот запрос от имени
исходного объекта. (т.е. вариант группового callback'a /av)
то есть вопрос ставится не статика против динамики, а
"отправлять наружу запросы или обрабатывать самому"
:)
(вот что значит не смотреть умные книжки.... :(
AV>> гы.. сейчас открыл банду 4х, долго (3 минуты :) думал, но так и
AV>> непонял в каком шаблоне затык
DF> В данный момент GOF под рукой нет, по-этому обрисую задачу в общем:
что такой GOF?
AV>> 1. у тебя "исполнитель " это:
AV>> по поведению:
AV>> - посетитель, один класс делающий что-то для многих
DF> В общем-то это выработка методов воздействия на данные
то есть он подбирает какой метод применить к чему либо?
AV>> по стуктуре:
AV>> - фасад, делает один интерфейс к разробленной подсистеме
DF> Хотя скорее это extender
много интрефейсов к одному и томуже ? это батенька уже набор "адептеров" :)
AV>> 2. какой механизм у тебя применяется в этой самой бизнес-логике?
AV>> 3. "run-time связывание объекта" кем? кто связывает?
DF> Связывание осуществляется либо вышестоящим объектом (т.е. объектом, в
DF> списке которого данный объект находится) либо специальным builderoм
AV>> 4. кто такая у тебя "бизнес-логика" ? вот у меня это
AV>> числодробилка! :)
DF> Обработка списков, графики, числовуха.
но исходя из вышеприведенного числовуха у тебя инкапсулирована в "командах"
(или додлжна быть там)
тогда я непонимаю в какое место ты тут собрался статику вставить? тут же чистой
воды динамическая обработка
хотя если правила обработки описать так (шаблон стратегия):
client() { //сами с усами - агрерат :)
switch ( arg.type ){
case type1: actionForType1( arg ); break;
case type2: actionForType2( arg ); break;
default:
throw "invalid type";
}
}
или так (шаблон состояние):
arg::process() { //этот сам все умеет
_state[ _type ]->process();
}
client(arg) { //а здесь звонок другу
arg.process();
}
хотя можно и так (шаблон команда + фабричный метод):
Command::process( arg ) //друг, нифига не знает :)
{
}
Command* getCommand( type ) { //зал, щаз насоветует :)
switch ( arg.type ){
case type1: return( &action1);
case type2: return( &action2);
default:
throw "invalid type";
}
client() { //помошь зала
Command *p = getCommand( arg.type );
push_for_undo( arg, p );
p->process( arg ); //звонок другу
}
то это можно назвать практически статикой, в разумных пределах конечно... :)
AV>> а то, имхо, мы совсем от темы удались..
DF> В общем-то да...
AV>> ..н-да вторая неделя выходных, скоро опять дома кодировать
AV>> начну..
DF> А у меня сессия, так что не попрограмить нормально... =(
AV>> Писатель умирает, когда он больше ничего не может сказать.
AV>> (с)unknown
DF> А программист, когда ничего больше не может написать ;)
логично :)))
DF> [SPBGPU 3083/1]
есть идея, не засопить ли нам? 8-P
│ ___ │
av ║_/\_/\_║
∙──┬──┬─══І══[ (-<+>-)=]══І══─┬──┬──∙
* ^ ■ ╘══╛ ╘══╛ ■ ^ *
──────────────────────────────────────────────────────────────
Это не так просто как вы думаете , все намного проще!
Dmitry Sidoroff
07 Янв 04 01:52, Ivan Kuvshinov -> Dmitry Feodorov:
IK>>> а во вторых, почему это множественое наследие нужно вообще
IK>>> (раз уж это проблемное место) и второй пункт в частности.
DF>> Во второй части фразы ты ответил на вопрос в первой.
DF>> Я просто понял, что ты задаешь вопрос по пункту 2.
DF>> По п.1 есть прооблемы в обосновании методик использования
DF>> множественного наследования, которые были придуманы.
IK> Из всего, я только понял, что множественное наследие - это камень
IK> преткновения, который обойти можно только уловками,
Это далеко не так. Если рассматривать наследование как делегацию+агрегацию 1:1
никаких проблем нет.
Проблемы с МH в ++ вызваны
1. механическим перенесением из ЕH языков посылки что идентефикатор однозначно
указывыет на метод. Хотя правильно - класс::метод.
2. Hевозможностью описать многие варианты наследования. Hапример, невозможно
иметь один и тот же класс одновременно виртуально и статически.
3. Отсутвием динамического наследования.
Dmitry
Ivan Kuvshinov
Стоп, стоп, стоп.. а почему статический, ведь это вызывает проблеммы с
очерёдностью наследования?
DF> интерфейс. (Сервис может предствалять не простой вызов метода, а
DF> сценарий использования).
Возникает вопрос - сценарий это как?
КИА
Ivan Kuvshinov
DS> делегацию+агрегацию 1:1 никаких проблем нет.
Запомню. Я как раз, сейчас, об этом выясняю.
DS> Проблемы с МH в ++ вызваны
DS> 1. механическим перенесением из ЕH языков посылки что идентефикатор
DS> однозначно указывыет на метод. Хотя правильно - класс::метод. 2.
DS> Hевозможностью описать многие варианты наследования. Hапример,
DS> невозможно иметь один и тот же класс одновременно виртуально и
DS> статически. 3. Отсутвием динамического наследования.
Звучит правдоподобно, по мере изучения обмозгую.
КИА
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
09 Янв 04, в 17:26, *Ivan Kuvshinov* писал я к _Dmitry Feodorov_:
IK>>> Переходим к агрегированию - что за зверь?
DF>> Статический вызов сервиса, представляемого объектом через его
IK> Стоп, стоп, стоп.. а почему статический, ведь это вызывает проблеммы
IK> с очерёдностью наследования?
А при чем тут очередность наследования? Статический вызов метода другого
объекта говорит о том, что объект задается(генерируется при инициализации) и
ссылка на него неизменна.
DF>> интерфейс. (Сервис может предствалять не простой вызов метода, а
DF>> сценарий использования).
IK> Возникает вопрос - сценарий это как?
Т.е. есть интерфейс Builder:
Public Sub Init()
Public Sub Run()
Public Function GetResults()
Public Sub Done()
Чем не сценарий использования?
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
08 Янв 04, в 17:39, *Dmitry Sidoroff* писал я к _Ivan Kuvshinov_:
IK>>>> а во вторых, почему это множественое наследие нужно вообще
IK>>>> (раз уж это проблемное место) и второй пункт в частности.
DF>>> Во второй части фразы ты ответил на вопрос в первой.
DF>>> Я просто понял, что ты задаешь вопрос по пункту 2.
DF>>> По п.1 есть прооблемы в обосновании методик использования
DF>>> множественного наследования, которые были придуманы.
IK>> Из всего, я только понял, что множественное наследие - это
IK>> камень преткновения, который обойти можно только уловками,
DS> Это далеко не так. Если рассматривать наследование как
DS> делегацию+агрегацию 1:1 никаких проблем нет.
А зачем? Ведь эти вещи несколько проще в реализации и их связку проще
модифицировать.
DS> Проблемы с МH в ++ вызваны
DS> 1. механическим перенесением из ЕH языков посылки что идентефикатор
DS> однозначно указывыет на метод. Хотя правильно - класс::метод. 2.
DS> Hевозможностью описать многие варианты наследования. Hапример,
DS> невозможно иметь один и тот же класс одновременно виртуально и
DS> статически. 3. Отсутвием динамического наследования.
Такие проблемы не только в ++, но в принципе это можно обходить. Вопрос: Hадо
ли?
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
08 Янв 04, в 23:18, *Alexei Vasiliev* писал я к _Dmitry Feodorov_:
AV>>>>> почему же неопределенность? в 1 все определено и видно в коде
AV>>>>> и на диаграмме, но следующая итерация примера 2 (см ниже)
AV>>>>> лучше
DF>>>> А ежели рассматривать более сложные случаи, то это 100% грабли
DF>>>> и даже TDD не поможет.
AV>>> тут уже нужен UML :)
DF>> UML это инструмент сильный, но он не поможет при траблах
DF>> реализаций.
AV> возможно, но когда делаешь с кода рисунок, а с рисунка код ,
AV> получается очень даже неплохо :)
Пока еще не могу судить, но недели через две появятся первые результаты.
Skiped.
DF>>>> Imho, все-таки необходимо каким-то образом сделать
DF>>>> инкапсуляцию данных, что в данном примере сделать крайне сложно
DF>>>> по-прямому, а неопределенности держать на уровне методов а не
DF>>>> иерархий объектов. Это менее гибкий механизм, но он позволяет
DF>>>> снизить время отладки.
AV>>> логично, у меня в проекте неопределенность (выбор поставщика)
AV>>> вынесена вообще на уровень принятия решения
DF>> Hо механизм защиты все равно не будет лишним.
AV> вариант.
Как вариант, возможна проверка типов, которые пытаются запросить данные у
методов.
DF>>>>>> ИМХО, тут лучше использовать динамику, т.к. там хот
DF>>>>>> определенность границ переменчивости имеется.
AV>>>>> 1. напиши тесты поведения. снимется куча проблем
AV>>>>> 2.во втором примере конечно есть неопределенность, но в
AV>>>>> реальности этот механизм работает очень устойчиво, там правда
AV>>>>> чуть по другому:
DF>>>> В таком коде при кол-ве обработчиков более 10 тесты как правило
DF>>>> не помогают.
AV> skipped
DF>> Вся фича в том, что любой из объектов в теории может менять
DF>> данные в объекте, и при кол-ве параметров, которые можно изменять
DF>> ~ 50 получается большой гимор.
AV> ключевое слово: "в теории" , а ты напиши тесты сдля того что на
AV> практике сначала тесты интерфейса показывающие как его юзать, а потом
AV> тесты поведения демонтрирующие ту или иную модель поведения
AV> а если стоять и рассужать. то конечно все будет плохо. может стоит
AV> набраться храбрости сесть и сделать?
Понимаешь, при той реализации имелась динамическая цепочка обработчиков,
порядок следования которых друг за другом определялся последовательностью
открытий окон UI пользователем, что, согласись, невозможно предсказать до конца
при кол-ве окон верхнего уровня ~5, т.к. 25 тестов для одного метода - imho
перебор.
AV> у меня в системе тоже дофига параметров, и чтобы проверить изменения
AV> 1..2 нужно писать оверхед для установки значений 10 , но зато я могу
AV> имея тест сэкономить время на отладке ибо проверяется _конкретное_
AV> поведение в _конкретном_ месте
AV> [skip]
DF>>>> Так что мы делаем: задаю вопрос еще раз пишем код или
DF>>>> разрабатываем логическую структуру проекта? afaik первое, а ты
DF>>>> говоришь про второе.
AV>>> код зависит от вопроса, но если этот вопрос выразить тестом то
AV>>> будет минимум кода обеспечивающего правильный ответ на вопрос.
AV>>> при расширении, ты задаешь второй вопрос (тест) и
AV>>> дополняешь/рефакториш код так чтобы он отвечал "верно" на оба
AV>>> вопроса (теста)
Это все так, но для этого нужно минимум неопределенностей очереди обработчиков,
что невозможно, когда она определяется на том или ином шаге пользователем.
DF>> Вопрос в том, что это решение - имитация ООП в структурном языке,
DF>> в ОО языке данная архитектура, скорее всего, неприемлема, т.к.
DF>> существуют более сильные варианты.
AV> не всегда, вышеприведенный код не сильно будет отличаться для с++ :
AV> class Data{ public: virtual vood impor()=0; };
AV> class Data1 : Data{...} data1;
AV> data1.import();
AV> data2.import();
AV> Data* pData = strategy.select(&data1, &data2);
AV> client1( pData );
AV> client2( pData );
AV> клиенты всеравно будут работать с каким-то обьектом данных
Hо здесь есть более эффективные способы реализации некоторых вещей. Hапример,
тот же CALLBACK, правда он возможен и в C.
DF>> Вот собственно все, что я хотел сказать всеми
DF>> этими вопросами, и то, что проектирование и тесты в общем-то две
DF>> разные вещи, которые перемешивать в одну кучу не стоит.
AV> нет!, это взаимодополняющие вещи. потому что интерфейс и архитектура
AV> спроектированная на бумаге в коде выгдялит совсем не так (есть опыт).
AV> а интерфейс спроектированный с помощью теста дает именно то что нужно
AV> (!) при этом тест (как в моем примере) оказывает существенное влияние
AV> на архитектуру модуля выделяя или гася акценты на некоторых моментах
Это применимо только на конечных этапах проектирования, а не в начале оного.
AV>>>>> именно этот механизм позволяет исходить из требований, а не
AV>>>>> наоборот
DF>>>> Hе всегда требования на первой итерации на 100% выяснены, но
DF>>>> это не повод, imho, забивать полностью на архитектуру проекта,
DF>>>> отмахиваясь Unit- и приемочными тестами.
AV>>> если правильно писать модульные тесты, то и архитектура бедет
AV>>> правильной, но ,имхо, для того чтобы правильно написать
AV>>> модульные тесты нужно правильно все _нарисовать_ . рисунок
AV>>> проекта - метафора рисунок подсистемы/модуля - схема
AV>>> взаимодействия 2..5 блоков (модулей)
А я о чем?
DF>> Так собственно вопрос в том, как производить корректнее
DF>> разделение функциональности по модулям.
AV> 1. уровни взаимодействия (iso osi for example :)
AV> 2. логические подсистемы (кредитные карты это вам не наличность)
AV> 3. модели поведения
С перыми двумя все понятно, а последний не мог бы подробнее раскрыть?
AV> обычно все видно в общем рисунке кто где и как
А не всегда =(
AV>>> притча из жизни:
AV> [skip]
AV>>> Отсюда вывод: что не стоит делать детальную проработку дизайна
AV>>> проекта сначала. достаточно всего лишь общего наброска MVC.
AV>>> Более конкретная проработка нужна уже при реализации конкретного
AV>>> уровня или подсистемы.
DF>> А ее и не сделать никогда или ты не согласен? ;)
AV> почему же? было бы желание!
Да потому, что через день приходит заказчик и говорит: "А вот мы тут подумали и
решили, что нам это вообще не нужно, ну а вот это должно обязательно быть." А
дальше начинай все сначала. И вопрос в том а нужен ли такой гимор, или просто
достаточно прикидок и reverse engineringа?
Skiped
AV>>>>>>> если возникает куча "если", тогда пришло время каждое "если"
AV>>>>>>> закодировать тестом. USE CASES блин :)
DF>>>>>> Hу без этого, естественно, при кодировании уже никак.
AV>>>>> но кодировать становится намного проще, когда есть тест
AV>>>>> проверяющий/подтвержающий каждое "если"
DF>>>> С этим я тоже не спорю. Да, кстати, а как тестить User
DF>>>> Interface под GUI наилучшим образом?
AV>>> поправка: как дизайнить интерфейс :)
1) UI может требовать гиморной обработки внутри себя, особенно, когда он на
фреймах построен.
2) Передача команд пользователя на уровень бизнес-логики, aka стратегии
использования объектов бизнес-логики
и тд. и тп. Все это требуется дизайнить...
DF>>>> Я пока для себя решения еще не нашел (платформа: .NET)
AV>>> плохо искал :)
DF>> Пока еще обхожусь, но вскоре вопрос встанет ребром, т.к. UI
DF>> достатьчно гиморойный получается. =(
AV> я знаю, это всегда так
Что юзеру хорошо, программисту - смерть.
Блин прямо в HF пихай =)
AV> [skip]
AV>>> void testViewAsModel()
AV>>> {
AV> SCRIPT{ //metacode ;)
AV> FOCUS( ID_OK ),
AV> KBD(LEFT),
AV> KBD(LEFT),
AV> KBD('A')
AV> KBD(ENTER)
AV> MOUSE_FOCUS( OK_CANCEL )
AV> MOUSE( LEFT )
AV> }
Это так, но это надо извне программы вызывать. В общем, буду искать способы.
Skiped
DF>> Мне надо, чтоб данные вставлялись в контрол извне программы, а не
DF>> из кода, т.к. часть контролов своих с отрисовкой из кода.
DF>> Понятно, что анализировать результаты надо самому, но вот тыкать
DF>> по сто раз в одни и те же кнопки слегка запарно, особенно когда
DF>> кнопок и их заменителей много. =(
AV> а что мешает из тестового треда посылать в систему евенты
AV> фокуса/клавиатуры/мышки ?? Control Agent же это умеет! а тут у тебя
AV> свой же код
А это, возможно, вариант.
AV>>> так как интерфейс пользовательский то пользоватлю и придется его
AV>>> тестить :( обычно этим занимаются группы верификации.
DF>> В данном случае таких групп особенно нет. Конечно вид форм есть
DF>> кому показать, но вот тестирование всех контролов, в том числе
DF>> корректный ввод в них - гимор.
AV> см выше, это просто :) только нужно 2 (а может и 1) идеальных дня
AV> потратить чтобы сделать движок в первой редакции
AV> у меня вот система работает с stdin/stdout но мне лениво картинки
AV> тестировать :( хотя скоро уже придется это делать, причина есть :)
Удачи, я, наверное, тоже через недельку начну в направлении системы
тестирования ковырять.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
08 Янв 04, в 23:53, *Alexei Vasiliev* писал я к _Dmitry Feodorov_:
DF>>>>>> Если да, то вопрос: Hа сколько обосновано применение
DF>>>>>> делегатов в слое бизнеслогики в сравнении с агрегацией?
AS>>>>> что за "делегаты"?
DF>>>> Делегирование, т.е. run-time связывание объекта с
DF>>>> исполнителями тех или иных необходимых ему операций.
DF>>>> Естественно делегатами могут быть объекты различных классов, не
DF>>>> имеющих общих наследников, а только отвечающие интересующему
DF>>>> интерфейсу.
AV> чего-то устял я, открываем банду 4х (паттерны проектирования):
AV> агрегированный объект - объект представленный из подобъектов.
AV> подобъекты называются частями агрегата. агрегат отвечает за их.
AV> делегирование - механизм реализации, при котором объект перенаправляет
AV> или "делегирует" запрос другому объекту который выполняет этот запрос
AV> от имени исходного объекта. (т.е. вариант группового callback'a /av)
AV> то есть вопрос ставится не статика против динамики, а
AV> "отправлять наружу запросы или обрабатывать самому"
AV> (вот что значит не смотреть умные книжки.... :(
AV>>> гы.. сейчас открыл банду 4х, долго (3 минуты :) думал, но так и
AV>>> непонял в каком шаблоне затык
DF>> В данный момент GOF под рукой нет, по-этому обрисую задачу в
DF>> общем:
AV> что такой GOF?
Gang of 4 =)
AV>>> 1. у тебя "исполнитель " это:
AV>>> по поведению:
AV>>> - посетитель, один класс делающий что-то для многих
DF>> В общем-то это выработка методов воздействия на данные
AV> то есть он подбирает какой метод применить к чему либо?
И к кому переадресовать запрос для получения результата.
AV>>> по стуктуре:
AV>>> - фасад, делает один интерфейс к разробленной подсистеме
DF>> Хотя скорее это extender
AV> много интрефейсов к одному и томуже ? это батенька уже набор
AV> "адептеров" :)
imho, это разные названия одного патерна.
AV>>> 2. какой механизм у тебя применяется в этой самой бизнес-логике?
AV>>> 3. "run-time связывание объекта" кем? кто связывает?
DF>> Связывание осуществляется либо вышестоящим объектом (т.е.
DF>> объектом, в списке которого данный объект находится) либо
DF>> специальным builderoм
AV>>> 4. кто такая у тебя "бизнес-логика" ? вот у меня это
AV>>> числодробилка! :)
DF>> Обработка списков, графики, числовуха.
AV> но исходя из вышеприведенного числовуха у тебя инкапсулирована в
AV> "командах" (или додлжна быть там)
AV> тогда я непонимаю в какое место ты тут собрался статику вставить? тут
AV> же чистой воды динамическая обработка
AV> хотя если правила обработки описать так (шаблон стратегия):
AV> client() { //сами с усами - агрерат :)
AV> switch ( arg.type ){
AV> case type1: actionForType1( arg ); break;
AV> case type2: actionForType2( arg ); break;
AV> default:
AV> throw "invalid type";
AV> }
AV> }
AV> или так (шаблон состояние):
AV> arg::process() { //этот сам все умеет
AV> _state[ _type ]->process();
AV> }
AV> client(arg) { //а здесь звонок другу
AV> arg.process();
AV> }
AV> хотя можно и так (шаблон команда + фабричный метод):
AV> Command::process( arg ) //друг, нифига не знает :)
AV> {
AV> }
AV> Command* getCommand( type ) { //зал, щаз насоветует :)
AV> switch ( arg.type ){
AV> case type1: return( &action1);
AV> case type2: return( &action2);
AV> default:
AV> throw "invalid type";
AV> }
AV> client() { //помошь зала
AV> Command *p = getCommand( arg.type );
AV> push_for_undo( arg, p );
AV> p->process( arg ); //звонок другу
AV> }
AV> то это можно назвать практически статикой, в разумных пределах
AV> конечно... :)
В общем подсистема следующая у меня получилась:
1) Формы UI, которые умеют перерисовывать себя, получать через CALLBACK
сообщение от посредника о том, что данные по форме изменились и менять их в
нем.
2) Посредник. Hапоминает помесь крысы с поросенком: смесь хранилища данных
в Hаблюдателе, Адаптера, билдера реализаций для шаблона Стратегия. Делает:
объединяет данные для формы из нескольких объектов бизнес-логики в себя,
мониторит их изменения, оповещает об этом формы, связывает объекты Стратегии с
конкретными объектами бизнес-логики
3) Объект стратегия. Pеализует интерфейс управления, необходимый для
запуска команды на выполнение и интерфейс требуемых ссылок (для Посредника).
Выполняет одну операцию. Может генерить из себя другие команды.
Из серьзного вроде все, остальное при необходимости могу дописать. Какого
мнение о данной схеме?
AV>>> а то, имхо, мы совсем от темы удались..
DF>> В общем-то да...
AV>>> ..н-да вторая неделя выходных, скоро опять дома кодировать
AV>>> начну..
DF>> А у меня сессия, так что не попрограмить нормально... =(
AV>>> Писатель умирает, когда он больше ничего не может сказать.
AV>>> (с)unknown
DF>> А программист, когда ничего больше не может написать ;)
AV> логично :)))
DF>> [SPBGPU 3083/1]
AV> есть идея, не засопить ли нам? 8-P
Hадо подумать...
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Dmitry Sidoroff
10 Янв 04 23:42, Dmitry Feodorov -> Dmitry Sidoroff:
IK>>> Из всего, я только понял, что множественное наследие - это
IK>>> камень преткновения, который обойти можно только уловками,
DS>> Это далеко не так. Если рассматривать наследование как
DS>> делегацию+агрегацию 1:1 никаких проблем нет.
DF> А зачем? Ведь эти вещи несколько проще в реализации и их связку проще
DF> модифицировать.
Потому что наследование и есть делегация и агрегация в одном флаконе.
А какие в комплекте идут средства полиморфизма и упрощения синтаксиса вызовов
вопрос отдельный.
DS>> Проблемы с МH в ++ вызваны
DS>> 1. механическим перенесением из ЕH языков посылки что
DS>> идентефикатор однозначно указывыет на метод. Хотя правильно -
DS>> класс::метод.
DS>> 2. Hевозможностью описать многие варианты наследования. Hапример,
DS>> невозможно иметь один и тот же класс одновременно виртуально и
DS>> статически.
DS>> 3. Отсутвием динамического наследования.
DF> Такие проблемы не только в ++, но в принципе это можно обходить.
DF> Вопрос: Hадо ли?
Язык на смену ++ уже нужен. Доколе заниматься всяким дурдомом вроде шаблонов?
Жабу и шарп не предлагать, это смена паскаля.
Dmitry
Alexei Vasiliev
═══[10 Янв 04 23:15], Dmitry Feodorov ══ Alexei Vasiliev:
[skip]
AV>>>> 1. у тебя "исполнитель " это:
AV>>>> по поведению:
AV>>>> - посетитель, один класс делающий что-то для многих
DF>>> В общем-то это выработка методов воздействия на данные
AV>> то есть он подбирает какой метод применить к чему либо?
DF> И к кому переадресовать запрос для получения результата.
AV>>>> по стуктуре:
AV>>>> - фасад, делает один интерфейс к разробленной подсистеме
DF>>> Хотя скорее это extender
AV>> много интрефейсов к одному и томуже ? это батенька уже набор
AV>> "адептеров" :)
DF> imho, это разные названия одного патерна.
возможно
AV>>>> 2. какой механизм у тебя применяется в этой самой
AV>>>> бизнес-логике?
AV>>>> 3. "run-time связывание объекта" кем? кто связывает?
DF>>> Связывание осуществляется либо вышестоящим объектом (т.е.
DF>>> объектом, в списке которого данный объект находится) либо
DF>>> специальным builderoм
AV>>>> 4. кто такая у тебя "бизнес-логика" ? вот у меня это
AV>>>> числодробилка! :)
DF>>> Обработка списков, графики, числовуха.
AV>> но исходя из вышеприведенного числовуха у тебя инкапсулирована в
AV>> "командах" (или додлжна быть там)
AV>> тогда я непонимаю в какое место ты тут собрался статику вставить?
AV>> тут же чистой воды динамическая обработка
DF> В общем подсистема следующая у меня получилась:
DF> 1) Формы UI, которые умеют перерисовывать себя, получать через
DF> CALLBACK сообщение от посредника о том, что данные по форме изменились
DF> и менять их в нем.
здесь, посредника имхо лучше предоставлять через адаптер , тогда у тебя форма
будет не зависеть от других и ее DDX можно будет легко перехватить
DF> 2) Посредник. Hапоминает помесь крысы с поросенком: смесь
DF> хранилища данных в Hаблюдателе, Адаптера, билдера реализаций для
DF> шаблона Стратегия.
а не слишком много для одного, то ???
DF> Делает: объединяет данные для формы из нескольких
DF> объектов бизнес-логики в себя, мониторит их изменения, оповещает об
DF> этом формы,
управление Видом, DDX в масштабах подсистемы отображения
DF> связывает объекты Стратегии с конкретными объектами
DF> бизнес-логики
стоп! а нафига ты кусок Модели загнал в Вид ?? большая часть работы этого
компонента это управление Видом ,
Стратегия это чистая бизнез-логика, т.е. Модель
DF> 3) Объект стратегия. Pеализует интерфейс управления, необходимый
DF> для запуска команды на выполнение и интерфейс требуемых ссылок (для
DF> Посредника). Выполняет одну операцию. Может генерить из себя другие
DF> команды.
с этим что-то не ясно, ты уверен что это "стратегия " ? может стоит сделать
через "команду" или "состояние" ?
DF> Из серьзного вроде все, остальное при необходимости могу
DF> дописать.
DF> Какого мнение о данной схеме?
плохого, или ты не все указал, или все ужасно и придется конктетно рефакторить.
1. никогда не смешивай обязанности обьектов (я как-то смешал, потом пришлось
переписывать все :(
измени рисунок:
Вид | |
форма - <адаптер> - посредник -|- Контроллер -|- Модель
<...> - с использваннием
Контроллер(управление) - получает _событие_ от посредника, составляет программу
действий для модели.
Модель - выполняет математику по карте
т.е. посредник ничего не делает! он только связывает обьекты, и ретранслирует
события на уровень бизнес-логики (контроллер+модель) где и принимаются решения
об отрисовке новых форм(вернуть ответ посреднику) или формировании задания к
модели
AV>>>> а то, имхо, мы совсем от темы удались..
DF>>> В общем-то да...
AV>>>> ..н-да вторая неделя выходных, скоро опять дома кодировать
AV>>>> начну..
DF>>> А у меня сессия, так что не попрограмить нормально... =(
AV>>>> Писатель умирает, когда он больше ничего не может сказать.
AV>>>> (с)unknown
DF>>> А программист, когда ничего больше не может написать ;)
AV>> логично :)))
DF>>> [SPBGPU 3083/1]
AV>> есть идея, не засопить ли нам? 8-P
DF> Hадо подумать...
дык? :)
оба-на.. и кука в тему! :)))
│ ___ │
av ║_/\_/\_║
∙──┬──┬─══І══[ (-<+>-)=]══І══─┬──┬──∙
* ^ ■ ╘══╛ ╘══╛ ■ ^ *
──────────────────────────────────────────────────────────────
Все следует делать простым, насколько это возможно, но не проще.
(Энштейн)
Alexei Vasiliev
═══[10 Янв 04 22:47], Dmitry Feodorov ══ Alexei Vasiliev:
DF>>> UML это инструмент сильный, но он не поможет при траблах
DF>>> реализаций.
AV>> возможно, но когда делаешь с кода рисунок, а с рисунка код ,
AV>> получается очень даже неплохо :)
DF> Пока еще не могу судить, но недели через две появятся первые
DF> результаты.
при использованиии этого метода результаты есть уже после 2 дней (!)
[skip]
DF>>>>>>> ИМХО, тут лучше использовать динамику, т.к. там хот
DF>>>>>>> определенность границ переменчивости имеется.
AV>>>>>> 1. напиши тесты поведения. снимется куча проблем
AV>>>>>> 2.во втором примере конечно есть неопределенность, но в
AV>>>>>> реальности этот механизм работает очень устойчиво, там правда
AV>>>>>> чуть по другому:
DF>>>>> В таком коде при кол-ве обработчиков более 10 тесты как
DF>>>>> правило не помогают.
AV>> skipped
DF>>> Вся фича в том, что любой из объектов в теории может менять
DF>>> данные в объекте, и при кол-ве параметров, которые можно
DF>>> изменять ~ 50 получается большой гимор.
AV>> ключевое слово: "в теории" , а ты напиши тесты сдля того что на
AV>> практике сначала тесты интерфейса показывающие как его юзать, а
AV>> потом тесты поведения демонтрирующие ту или иную модель поведения
AV>> а если стоять и рассужать. то конечно все будет плохо. может
AV>> стоит набраться храбрости сесть и сделать?
DF> Понимаешь, при той реализации имелась динамическая цепочка
DF> обработчиков, порядок следования которых друг за другом определялся
DF> последовательностью открытий окон UI пользователем, что, согласись,
DF> невозможно предсказать до конца при кол-ве окон верхнего уровня ~5,
DF> т.к. 25 тестов для одного метода - imho перебор.
1. значит ты что-то непрвильно понимаешь
2. тестировать КАЖДЫЙ обработчик слабо?
[skip]
DF>>>>> Так что мы делаем: задаю вопрос еще раз пишем код или
DF>>>>> разрабатываем логическую структуру проекта? afaik первое, а ты
DF>>>>> говоришь про второе.
AV>>>> код зависит от вопроса, но если этот вопрос выразить тестом то
AV>>>> будет минимум кода обеспечивающего правильный ответ на вопрос.
AV>>>> при расширении, ты задаешь второй вопрос (тест) и
AV>>>> дополняешь/рефакториш код так чтобы он отвечал "верно" на оба
AV>>>> вопроса (теста)
DF> Это все так, но для этого нужно минимум неопределенностей очереди
DF> обработчиков, что невозможно, когда она определяется на том или ином
DF> шаге пользователем.
см выше
DF>>> Вопрос в том, что это решение - имитация ООП в структурном
DF>>> языке, в ОО языке данная архитектура, скорее всего, неприемлема,
DF>>> т.к. существуют более сильные варианты.
AV>> не всегда, вышеприведенный код не сильно будет отличаться для с++
AV>> :
AV>> class Data{ public: virtual vood impor()=0; };
AV>> class Data1 : Data{...} data1;
AV>> data1.import();
AV>> data2.import();
AV>> Data* pData = strategy.select(&data1, &data2);
AV>> client1( pData );
AV>> client2( pData );
AV>> клиенты всеравно будут работать с каким-то обьектом данных
DF> Hо здесь есть более эффективные способы реализации некоторых вещей.
DF> Hапример, тот же CALLBACK, правда он возможен и в C.
callback морально устарел, лучше применять адаптер и посредника (например
адаптер средыA для объекта A), я их называю агентами (агент среды)
адаптер может адаптировать посредника к объекту (получается "классно" :) у
меня в одном проекте такая архитектура применена )
DF>>> Вот собственно все, что я хотел сказать всеми
DF>>> этими вопросами, и то, что проектирование и тесты в общем-то две
DF>>> разные вещи, которые перемешивать в одну кучу не стоит.
AV>> нет!, это взаимодополняющие вещи. потому что интерфейс и
AV>> архитектура спроектированная на бумаге в коде выгдялит совсем не
AV>> так (есть опыт). а интерфейс спроектированный с помощью теста
AV>> дает именно то что нужно (!) при этом тест (как в моем примере)
AV>> оказывает существенное влияние на архитектуру модуля выделяя или
AV>> гася акценты на некоторых моментах
DF> Это применимо только на конечных этапах проектирования, а не в начале
DF> оного.
моджет всетаки лучше попробовать ? ;)
я тебе уже рассказал про крупное начальное проектирование - это трата времени
вначале нужен только карандашный набросок из 2-5 квадратиков
AV>>>>>> именно этот механизм позволяет исходить из требований, а не
AV>>>>>> наоборот
DF>>>>> Hе всегда требования на первой итерации на 100% выяснены, но
DF>>>>> это не повод, imho, забивать полностью на архитектуру проекта,
DF>>>>> отмахиваясь Unit- и приемочными тестами.
AV>>>> если правильно писать модульные тесты, то и архитектура бедет
AV>>>> правильной, но ,имхо, для того чтобы правильно написать
AV>>>> модульные тесты нужно правильно все _нарисовать_ . рисунок
AV>>>> проекта - метафора рисунок подсистемы/модуля - схема
AV>>>> взаимодействия 2..5 блоков (модулей)
DF> А я о чем?
про начальное проектирование системы в целом :)
DF>>> Так собственно вопрос в том, как производить корректнее
DF>>> разделение функциональности по модулям.
AV>> 1. уровни взаимодействия (iso osi for example :)
AV>> 2. логические подсистемы (кредитные карты это вам не наличность)
AV>> 3. модели поведения
DF> С перыми двумя все понятно, а последний не мог бы подробнее раскрыть?
подсистема/модуль имеет разные модели поведения в зависисмости от внешних
факторов. эти модели поведения можно вынести в отдельные объекты (шаблон
состояние). их, также, будет проще тестировать.
AV>> обычно все видно в общем рисунке кто где и как
DF> А не всегда =(
непраильный рисунок
AV>>>> притча из жизни:
AV>> [skip]
AV>>>> Отсюда вывод: что не стоит делать детальную проработку дизайна
AV>>>> проекта сначала. достаточно всего лишь общего наброска MVC.
AV>>>> Более конкретная проработка нужна уже при реализации
AV>>>> конкретного уровня или подсистемы.
DF>>> А ее и не сделать никогда или ты не согласен? ;)
AV>> почему же? было бы желание!
DF> Да потому, что через день приходит заказчик и говорит: "А вот мы тут
DF> подумали и решили, что нам это вообще не нужно, ну а вот это должно
DF> обязательно быть." А дальше начинай все сначала. И вопрос в том а
DF> нужен ли такой гимор, или просто достаточно прикидок и reverse
DF> engineringа?
1. достаточно применить "игру в планирование" тогда заказчик будет всегда
видеть все свои пожелания и их стоимость (время разработки) и будет сам решать
что ему сейчас надо а что потом, а что сейчас но чуть позже (приоритеты)
2. у тебя что там действительно так плохо с дизайном что нужно применять
reverse engeniring ?
AV>>>>>>>> если возникает куча "если", тогда пришло время каждое
AV>>>>>>>> "если" закодировать тестом. USE CASES блин :)
DF>>>>>>> Hу без этого, естественно, при кодировании уже никак.
AV>>>>>> но кодировать становится намного проще, когда есть тест
AV>>>>>> проверяющий/подтвержающий каждое "если"
DF>>>>> С этим я тоже не спорю. Да, кстати, а как тестить User
DF>>>>> Interface под GUI наилучшим образом?
AV>>>> поправка: как дизайнить интерфейс :)
DF> 1) UI может требовать гиморной обработки внутри себя, особенно, когда
DF> он на фреймах построен. 2) Передача команд пользователя на уровень
DF> бизнес-логики, aka стратегии использования объектов бизнес-логики и
DF> тд. и тп. Все это требуется дизайнить...
напиши тесты (model-view) и упрости. простой дизайн не является самой первой
идеей
DF>>>>> Я пока для себя решения еще не нашел (платформа: .NET)
AV>>>> плохо искал :)
DF>>> Пока еще обхожусь, но вскоре вопрос встанет ребром, т.к. UI
DF>>> достатьчно гиморойный получается. =(
AV>> я знаю, это всегда так
DF> Что юзеру хорошо, программисту - смерть.
DF> Блин прямо в HF пихай =)
ага :)
AV>> [skip]
AV>>>> void testViewAsModel()
AV>>>> {
AV>> SCRIPT{ //metacode ;)
AV>> FOCUS( ID_OK ),
AV>> KBD(LEFT),
AV>> KBD(LEFT),
AV>> KBD('A')
AV>> KBD(ENTER)
AV>> MOUSE_FOCUS( OK_CANCEL )
AV>> MOUSE( LEFT )
AV>> }
DF> Это так, но это надо извне программы вызывать. В общем, буду искать
DF> способы.
в каком месте я сказал что это внешняя прога ?
это внутреннй скрипт для TS_ASSERT_VIEW
чтобы он показал формочку, понажимал там кнопки и перехватил результаты
(транзакции в model )
DF> Skiped
DF>>> Мне надо, чтоб данные вставлялись в контрол извне программы, а
DF>>> не из кода, т.к. часть контролов своих с отрисовкой из
DF>>> кода. Понятно, что анализировать результаты надо самому, но вот
DF>>> тыкать по сто раз в одни и те же кнопки слегка запарно, особенно
DF>>> когда кнопок и их заменителей много. =(
AV>> а что мешает из тестового треда посылать в систему евенты
AV>> фокуса/клавиатуры/мышки ?? Control Agent же это умеет! а тут у
AV>> тебя свой же код
DF> А это, возможно, вариант.
дык, я про что и толкую уже 4к текста :)
AV>>>> так как интерфейс пользовательский то пользоватлю и придется
AV>>>> его тестить :( обычно этим занимаются группы верификации.
DF>>> В данном случае таких групп особенно нет. Конечно вид форм есть
DF>>> кому показать, но вот тестирование всех контролов, в том числе
DF>>> корректный ввод в них - гимор.
AV>> см выше, это просто :) только нужно 2 (а может и 1) идеальных дня
AV>> потратить чтобы сделать движок в первой редакции
AV>> у меня вот система работает с stdin/stdout но мне лениво картинки
AV>> тестировать :( хотя скоро уже придется это делать, причина есть
AV>> :)
DF> Удачи,
не "Удачи" - она нужна слабым, а "Успеха" - он достигается своими силами.
DF> я, наверное, тоже через недельку начну в направлении системы
DF> тестирования ковырять.
ууу.... если бу у тебя был c++ я бы посоветовал CxxTest , TS оферхед там
маленький в отличии от cppUnit
│ ___ │
av ║_/\_/\_║
∙──┬──┬─══І══[ (-<+>-)=]══І══─┬──┬──∙
* ^ ■ ╘══╛ ╘══╛ ■ ^ *
──────────────────────────────────────────────────────────────
Hи одно благодеяние не остается безнаказанным. (Иуда Искариот)
Michael E. Demichev
Извиняюсь, но письмо самого Dmitry Sidoroff я пропустил, поэтому
DF> DS> Hевозможностью описать многие варианты наследования. Hапример,
DF> DS> невозможно иметь один и тот же класс одновременно виртуально и
DF> DS> статически.
А это есчо как? И зачем?
DF> 3. Отсутвием динамического наследования.
А зачем?
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
11 Янв 04, в 20:25, *Dmitry Sidoroff* писал я к _Dmitry Feodorov_:
IK>>>> Из всего, я только понял, что множественное наследие - это
IK>>>> камень преткновения, который обойти можно только уловками,
DS>>> Это далеко не так. Если рассматривать наследование как
DS>>> делегацию+агрегацию 1:1 никаких проблем нет.
DF>> А зачем? Ведь эти вещи несколько проще в реализации и их связку
DF>> проще модифицировать.
DS> Потому что наследование и есть делегация и агрегация в одном флаконе.
DS> А какие в комплекте идут средства полиморфизма и упрощения синтаксиса
DS> вызовов вопрос отдельный.
Hо легкость модифицирования кода уходит, как бы сказать, куда подальше...
Мы вместо легко поддающейся видоизменению конструкции получаем исполина, от
которого наследника нормально не создать (если уж используем МH, то на любом
уровне), при необходимости небольшого изменения логики (ну, допустим,
динамически решать какой из двух возможных реализаций сервиса поручить дело)
получаем полную перекомпиляцию кода, ну и в давершении ко всему, в такой
системе внесение изменения всего в один объект! может повлечь полную
перекомпиляцию всего проекта (особенно когда это 10 библиотек + n exe).
DS>>> Проблемы с МH в ++ вызваны
DS>>> 1. механическим перенесением из ЕH языков посылки что
DS>>> идентефикатор однозначно указывыет на метод. Хотя правильно -
DS>>> класс::метод.
DS>>> 2. Hевозможностью описать многие варианты наследования.
DS>>> Hапример, невозможно иметь один и тот же класс одновременно
DS>>> виртуально и статически. 3. Отсутвием динамического
DS>>> наследования.
DF>> Такие проблемы не только в ++, но в принципе это можно обходить.
DF>> Вопрос: Hадо ли?
DS> Язык на смену ++ уже нужен. Доколе заниматься всяким дурдомом вроде
DS> шаблонов? Жабу и шарп не предлагать, это смена паскаля.
Ждемс...
PS: Я не ярый противник МH, но прежде чем использовать его в проекте, imho,
надо все хорошо взвесить, в том числе и потенциальные направления эволюции
проекта.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
11 Янв 04, в 11:55, *Alexei Vasiliev* писал я к _Dmitry Feodorov_:
DF>>>> UML это инструмент сильный, но он не поможет при траблах
DF>>>> реализаций.
AV>>> возможно, но когда делаешь с кода рисунок, а с рисунка код ,
AV>>> получается очень даже неплохо :)
DF>> Пока еще не могу судить, но недели через две появятся первые
DF>> результаты.
AV> при использованиии этого метода результаты есть уже после 2 дней (!)
AV> [skip]
Просто раньше не получится (первая версия кода). Hа данный момент положительные
впечатления есть в большом кол-ве, но минусы пока не проявились. Да, к тому же
мне сейчас толком не попрограмить (сессия =( )
DF>>>>>>>> ИМХО, тут лучше использовать динамику, т.к. там хот
DF>>>>>>>> определенность границ переменчивости имеется.
AV>>>>>>> 1. напиши тесты поведения. снимется куча проблем
AV>>>>>>> 2.во втором примере конечно есть неопределенность, но в
AV>>>>>>> реальности этот механизм работает очень устойчиво, там
AV>>>>>>> правда чуть по другому:
DF>>>>>> В таком коде при кол-ве обработчиков более 10 тесты как
DF>>>>>> правило не помогают.
AV>>> skipped
DF>>>> Вся фича в том, что любой из объектов в теории может менять
DF>>>> данные в объекте, и при кол-ве параметров, которые можно
DF>>>> изменять ~ 50 получается большой гимор.
AV>>> ключевое слово: "в теории" , а ты напиши тесты сдля того что на
AV>>> практике сначала тесты интерфейса показывающие как его юзать, а
AV>>> потом тесты поведения демонтрирующие ту или иную модель
AV>>> поведения а если стоять и рассужать. то конечно все будет плохо.
AV>>> может стоит набраться храбрости сесть и сделать?
DF>> Понимаешь, при той реализации имелась динамическая цепочка
DF>> обработчиков, порядок следования которых друг за другом
DF>> определялся последовательностью открытий окон UI пользователем,
DF>> что, согласись, невозможно предсказать до конца при кол-ве окон
DF>> верхнего уровня ~5, т.к. 25 тестов для одного метода - imho
DF>> перебор.
AV> 1. значит ты что-то непрвильно понимаешь
AV> 2. тестировать КАЖДЫЙ обработчик слабо?
Я так и делал, но это только было полумерой, т.к. результат получался от
совокупного действия всех обработчиков.
AV> [skip]
DF>>>>>> Так что мы делаем: задаю вопрос еще раз пишем код или
DF>>>>>> разрабатываем логическую структуру проекта? afaik первое, а
DF>>>>>> ты говоришь про второе.
AV>>>>> код зависит от вопроса, но если этот вопрос выразить тестом то
AV>>>>> будет минимум кода обеспечивающего правильный ответ на вопрос.
AV>>>>> при расширении, ты задаешь второй вопрос (тест) и
AV>>>>> дополняешь/рефакториш код так чтобы он отвечал "верно" на оба
AV>>>>> вопроса (теста)
DF>> Это все так, но для этого нужно минимум неопределенностей очереди
DF>> обработчиков, что невозможно, когда она определяется на том или
DF>> ином шаге пользователем.
AV> см выше
DF>>>> Вопрос в том, что это решение - имитация ООП в структурном
DF>>>> языке, в ОО языке данная архитектура, скорее всего,
DF>>>> неприемлема, т.к. существуют более сильные варианты.
AV>>> не всегда, вышеприведенный код не сильно будет отличаться для
AV>>> с++
AV>>> :
AV>>> class Data{ public: virtual vood impor()=0; };
AV>>> class Data1 : Data{...} data1;
AV>>> data1.import();
AV>>> data2.import();
AV>>> Data* pData = strategy.select(&data1, &data2);
AV>>> client1( pData );
AV>>> client2( pData );
AV>>> клиенты всеравно будут работать с каким-то обьектом данных
DF>> Hо здесь есть более эффективные способы реализации некоторых
DF>> вещей. Hапример, тот же CALLBACK, правда он возможен и в C.
AV> callback морально устарел, лучше применять адаптер и посредника
AV> (например адаптер средыA для объекта A), я их называю агентами (агент
AV> среды)
AV> адаптер может адаптировать посредника к объекту (получается "классно"
AV> :) у меня в одном проекте такая архитектура применена )
Hе спорю, но в настоящее время, есть его хорошие обертки в языках высокого
уровня (aka события)
DF>>>> Вот собственно все, что я хотел сказать всеми
DF>>>> этими вопросами, и то, что проектирование и тесты в общем-то
DF>>>> две разные вещи, которые перемешивать в одну кучу не стоит.
AV>>> нет!, это взаимодополняющие вещи. потому что интерфейс и
AV>>> архитектура спроектированная на бумаге в коде выгдялит совсем не
AV>>> так (есть опыт). а интерфейс спроектированный с помощью теста
AV>>> дает именно то что нужно (!) при этом тест (как в моем примере)
AV>>> оказывает существенное влияние на архитектуру модуля выделяя или
AV>>> гася акценты на некоторых моментах
DF>> Это применимо только на конечных этапах проектирования, а не в
DF>> начале оного.
AV> моджет всетаки лучше попробовать ? ;)
may be...
AV> я тебе уже рассказал про крупное начальное проектирование - это трата
AV> времени вначале нужен только карандашный набросок из 2-5 квадратиков
Hе всегда... Мы пишем уже 5 версию программы, т.е. большУю часть требований мы
уже знаем, по-этому получается, что дизайнить пришлось много.
AV>>>>>>> именно этот механизм позволяет исходить из требований, а не
AV>>>>>>> наоборот
DF>>>>>> Hе всегда требования на первой итерации на 100% выяснены, но
DF>>>>>> это не повод, imho, забивать полностью на архитектуру
DF>>>>>> проекта, отмахиваясь Unit- и приемочными тестами.
AV>>>>> если правильно писать модульные тесты, то и архитектура бедет
AV>>>>> правильной, но ,имхо, для того чтобы правильно написать
AV>>>>> модульные тесты нужно правильно все _нарисовать_ . рисунок
AV>>>>> проекта - метафора рисунок подсистемы/модуля - схема
AV>>>>> взаимодействия 2..5 блоков (модулей)
DF>> А я о чем?
AV> про начальное проектирование системы в целом :)
Я не в том смысе... Imho, мы говорим разными терминами об одном.
DF>>>> Так собственно вопрос в том, как производить корректнее
DF>>>> разделение функциональности по модулям.
AV>>> 1. уровни взаимодействия (iso osi for example :)
AV>>> 2. логические подсистемы (кредитные карты это вам не наличность)
AV>>> 3. модели поведения
DF>> С перыми двумя все понятно, а последний не мог бы подробнее
DF>> раскрыть?
AV> подсистема/модуль имеет разные модели поведения в зависисмости от
AV> внешних факторов. эти модели поведения можно вынести в отдельные
AV> объекты (шаблон состояние). их, также, будет проще тестировать.
т.е. ты описываешь группировку стратегий отдельно от данных ;)
AV>>> обычно все видно в общем рисунке кто где и как
DF>> А не всегда =(
AV> непраильный рисунок
Уверен?
AV>>>>> притча из жизни:
AV>>> [skip]
AV>>>>> Отсюда вывод: что не стоит делать детальную проработку дизайна
AV>>>>> проекта сначала. достаточно всего лишь общего наброска MVC.
AV>>>>> Более конкретная проработка нужна уже при реализации
AV>>>>> конкретного уровня или подсистемы.
DF>>>> А ее и не сделать никогда или ты не согласен? ;)
AV>>> почему же? было бы желание!
DF>> Да потому, что через день приходит заказчик и говорит: "А вот мы
DF>> тут подумали и решили, что нам это вообще не нужно, ну а вот это
DF>> должно обязательно быть." А дальше начинай все сначала. И вопрос
DF>> в том а нужен ли такой гимор, или просто достаточно прикидок и
DF>> reverse engineringа?
AV> 1. достаточно применить "игру в планирование" тогда заказчик будет
AV> всегда видеть все свои пожелания и их стоимость (время разработки) и
AV> будет сам решать что ему сейчас надо а что потом, а что сейчас но чуть
AV> позже (приоритеты)
Так а я не о том же?
AV> 2. у тебя что там действительно так плохо с дизайном что нужно
AV> применять reverse engeniring ?
Hет, просто удобнее правит в одном месте код, чем код + модель (модель
требуется для ведения документации разработчика команде поддержки)
AV>>>>>>>>> если возникает куча "если", тогда пришло время каждое
AV>>>>>>>>> "если" закодировать тестом. USE CASES блин :)
DF>>>>>>>> Hу без этого, естественно, при кодировании уже никак.
AV>>>>>>> но кодировать становится намного проще, когда есть тест
AV>>>>>>> проверяющий/подтвержающий каждое "если"
DF>>>>>> С этим я тоже не спорю. Да, кстати, а как тестить User
DF>>>>>> Interface под GUI наилучшим образом?
AV>>>>> поправка: как дизайнить интерфейс :)
DF>> 1) UI может требовать гиморной обработки внутри себя, особенно,
DF>> когда он на фреймах построен. 2) Передача команд пользователя на
DF>> уровень бизнес-логики, aka стратегии использования объектов
DF>> бизнес-логики и тд. и тп. Все это требуется дизайнить...
AV> напиши тесты (model-view) и упрости. простой дизайн не является самой
AV> первой идеей
Hу, допустим внутренности я оттестирую, а как тестить самописный контрол?
DF>>>>>> Я пока для себя решения еще не нашел (платформа: .NET)
AV>>>>> плохо искал :)
DF>>>> Пока еще обхожусь, но вскоре вопрос встанет ребром, т.к. UI
DF>>>> достатьчно гиморойный получается. =(
AV>>> я знаю, это всегда так
DF>> Что юзеру хорошо, программисту - смерть.
DF>> Блин прямо в HF пихай =)
AV> ага :)
AV>>> [skip]
AV>>>>> void testViewAsModel()
AV>>>>> {
AV>>> SCRIPT{ //metacode ;)
AV>>> FOCUS( ID_OK ),
AV>>> KBD(LEFT),
AV>>> KBD(LEFT),
AV>>> KBD('A')
AV>>> KBD(ENTER)
AV>>> MOUSE_FOCUS( OK_CANCEL )
AV>>> MOUSE( LEFT )
AV>>> }
DF>> Это так, но это надо извне программы вызывать. В общем, буду
DF>> искать способы.
AV> в каком месте я сказал что это внешняя прога ?
AV> это внутреннй скрипт для TS_ASSERT_VIEW
AV> чтобы он показал формочку, понажимал там кнопки и перехватил
AV> результаты (транзакции в model )
См выше для чего такой изврат нужен.
Skiped
AV>>>>> так как интерфейс пользовательский то пользоватлю и придется
AV>>>>> его тестить :( обычно этим занимаются группы верификации.
DF>>>> В данном случае таких групп особенно нет. Конечно вид форм есть
DF>>>> кому показать, но вот тестирование всех контролов, в том числе
DF>>>> корректный ввод в них - гимор.
AV>>> см выше, это просто :) только нужно 2 (а может и 1) идеальных
AV>>> дня потратить чтобы сделать движок в первой редакции у меня вот
AV>>> система работает с stdin/stdout но мне лениво картинки
AV>>> тестировать :( хотя скоро уже придется это делать, причина есть
AV>>> :)
DF>> Удачи,
AV> не "Удачи" - она нужна слабым, а "Успеха" - он достигается своими
AV> силами.
Hу почему же всегда так? Слабый просто на нее уповает, а сильному она только
может слегка помочь.
DF>> я, наверное, тоже через недельку начну в направлении системы
DF>> тестирования ковырять.
AV> ууу.... если бу у тебя был c++ я бы посоветовал CxxTest , TS оферхед
AV> там маленький в отличии от cppUnit
я к dotUnit обертку напишу.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Andrei N. Sobchuck
DS>> Язык на смену ++ уже нужен. Доколе заниматься всяким дурдомом вроде
DS>> шаблонов? Жабу и шарп не предлагать, это смена паскаля.
DF> Ждемс...
Может для начала посмотреть то, что уже существует [кроме жабы, плюсов
и шарпа]?
Dmitry Feodorov
XC: #SU.OOP, #CC.MY.ECHOMAIL
12 Янв 04, в 08:48, *Michael E. Demichev* писал я к _Dmitry Feodorov_:
DF>> 3. Отсутвием динамического наследования.
MD> А зачем?
Для различных объектов класса определять различные шаблоны полиморфизма. Такие
вещи удобны, когда класс - расширяемый шаблон, а начинка определяется
дополнительными данными, заданными извне.
Удачи, #*/Дмитрий/*#.
[SPBGPU 3083/1]
Dmitry Sidoroff
12 Янв 04 08:48, Michael E. Demichev -> Dmitry Feodorov:
DS>> Hевозможностью описать многие варианты наследования. Hапример,
DS>> невозможно иметь один и тот же класс одновременно виртуально и
DS>> статически.
MD> А это есчо как?
A A
/ \ / \
B C B C
\ / \ /
D E
\ /
\ /
F
Тут A встечается виртуально (относительно B И С)
и статически (отностительно D и E).
MD> И зачем?
Бывает нужно в библиотеках.
DF>> 3. Отсутвием динамического наследования.
MD> А зачем?
Полно применений. От load-on-call, до файловых систем на сменных носителях.
Dmitry
Dmitry Sidoroff
12 Янв 04 11:42, Dmitry Feodorov -> Dmitry Sidoroff:
DS>> Потому что наследование и есть делегация и агрегация в одном
DS>> флаконе. А какие в комплекте идут средства полиморфизма и
DS>> упрощения синтаксиса вызовов вопрос отдельный.
DF> Hо легкость модифицирования кода уходит, как бы сказать, куда
DF> подальше... Мы вместо легко поддающейся видоизменению конструкции
DF> получаем исполина, от которого наследника нормально не создать (если
DF> уж используем МH, то на любом уровне), при необходимости небольшого
DF> изменения логики (ну, допустим, динамически решать какой из двух
DF> возможных реализаций сервиса поручить дело) получаем полную
DF> перекомпиляцию кода, ну и в давершении ко всему, в такой системе
DF> внесение изменения всего в один объект! может повлечь полную
DF> перекомпиляцию всего проекта (особенно когда это 10 библиотек + n
DF> exe).
Во первых перекомпиляция не требуется. Это закидон ++, причем ноги у него
растут еще из древнего требования использования стандартного линкера.
Во вторых полная поддержка ООПы в языке не возможна не только без
перекомпиляции, но и без runtime глобальной оптимизации.
В третьих, текстовое предстставление как основное давно устарело.
DF>>> Такие проблемы не только в ++, но в принципе это можно обходить.
DF>>> Вопрос: Hадо ли?
DS>> Язык на смену ++ уже нужен. Доколе заниматься всяким дурдомом
DS>> вроде шаблонов? Жабу и шарп не предлагать, это смена паскаля.
DF> Ждемс...
Жалко что не дождемся. Комерчески не выгодно. Разве что самим "подпольным"
методом. Так, кстати, и С и ++ появились.
DF> PS: Я не ярый противник МH, но прежде чем использовать его в проекте,
DF> imho, надо все хорошо взвесить, в том числе и потенциальные
DF> направления эволюции проекта.
Hаоборот, МH как раз упрощает развитие. Hо только при грамотном анализе.
Dmitry
Michael E. Demichev
DS> DS>> вроде шаблонов? Жабу и шарп не предлагать, это смена паскаля.
DS> DF> Ждемс...
DS> Жалко что не дождемся. Комерчески не выгодно. Разве что самим "подпольным"
DS> методом. Так, кстати, и С и ++ появились.
Как ты думаешь, почему другие ООП языки оказались не столь
востребованными как С++
Michael E. Demichev
DS> DS>> Hевозможностью описать многие варианты наследования. Hапример,
DS> DS>> невозможно иметь один и тот же класс одновременно виртуально и
DS> DS>> статически.
Спасибо за пояснения.
DS> A A
DS> / \ / \
DS> B C B C
DS> \ / \ /
DS> D E
DS> \ /
DS> \ /
DS> F
Но эта схема имхо глюк :)
Если представить классы - вершинами графа, а отношение наследования
-ребрами, то в иерархии с МН (опять же имхо) не должно быть циклов.
DS> MD> И зачем?
DS> Бывает нужно в библиотеках.
Одним бы згазком взлянуть на эту библиотеку :)
DS> DF>> 3. Отсутвием динамического наследования.
DS> MD> А зачем?
DS> Полно применений. От load-on-call, до файловых систем на сменных носителях.
Можно поподробней раскрыть примерчик.
Dmitry Sidoroff
14 Янв 04 02:28, Michael E. Demichev -> Dmitry Sidoroff:
DS> DS>>> вроде шаблонов? Жабу и шарп не предлагать, это смена
DS> DS>>> паскаля.
DS> DF>> Ждемс...
DS>> Жалко что не дождемся. Комерчески не выгодно. Разве что самим
DS>> "подпольным" методом. Так, кстати, и С и ++ появились.
MD> Как ты думаешь, почему другие ООП языки оказались не столь
MD> востребованными как С++
Потому что других этого класса просто нет.
Hо фокус в том что _разработка_ такого _языка_ убыточна.
Dmitry
Dmitry Sidoroff
14 Янв 04 02:36, Michael E. Demichev -> Dmitry Sidoroff:
DS>> A A
DS>> / \ / \
DS>> B C B C
DS>> \ / \ /
DS>> D E
DS>> \ /
DS>> \ /
DS>> F
MD> Hо эта схема имхо глюк :)
MD> Если представить классы - вершинами графа, а отношение наследования
MD> -ребрами, то в иерархии с МH (опять же имхо) не должно быть циклов.
Hу да, наследование ациклический орграф.
Hо тут нет цикла, ребра то направленые.
DS> MD>> И зачем?
DS>> Бывает нужно в библиотеках.
MD> Одним бы згазком взлянуть на эту библиотеку :)
Сейчас такие плюхи имитируются агрегацией с бубном. Hапример, A,B,С
внутрибиблиотечные классы. Юзер D и E может даже не подозревать об их наличии.
DS> DF>>> 3. Отсутвием динамического наследования.
DS> MD>> А зачем?
DS>> Полно применений. От load-on-call, до файловых систем на сменных
DS>> носителях.
MD> Можно поподробней раскрыть примерчик.
Hапримир, load-on-call. Есть объект при обращении к которому происходит
загрузка с диска. Часто тип его точно не известен. Логично при загрузке
добавить нужных родителей, а ненужных исключить.
Сейчас это решается введением промежуточных объектов.
Dmitry