Здравствуйте, XopoSHiy, Вы писали:
XSH>Когда книжку "Design patterns" банды четырех переводили на русский, случился небольшой казус.
XSH>.......
XSH>Надеюсь этот мой пост ускорит у кого-нибудь выход из этой разрушительной фазы. 
Спасибо, Кэп!
Здравствуйте, Warturtle, Вы писали:
W>Нужно сделать "визуальную" работу с объектами этих классов в App внешней по отношению к ним. Поместить это в LogicCore нельзя, т.к. это потянет за собой зависимости от ненужных и "тяжелых" библиотек. По-моему это самое оно для применения посетителя. Пример на C#.
Посмотрел Ваш пример. Не понял — а что мешает сделать
то же самое без Visitor'а?
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, Warturtle, Вы писали:
W>>Нужно сделать "визуальную" работу с объектами этих классов в App внешней по отношению к ним. Поместить это в LogicCore нельзя, т.к. это потянет за собой зависимости от ненужных и "тяжелых" библиотек. По-моему это самое оно для применения посетителя. Пример на C#.
КЛ>Посмотрел Ваш пример. Не понял — а что мешает сделать то же самое без Visitor'а?
То же самое не получилось. Пример правда не полностью отражает ситуацию — это да, там еще сериализация была. Можно, конечно, было сделать виртуальный метод с показом диалогов, но тут не получалось без использования рефлекшена получить из десереализованного объекта некоего класса получить объект его класса-наследника.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, Warturtle, Вы писали:
W>>Нужно сделать "визуальную" работу с объектами этих классов в App внешней по отношению к ним. Поместить это в LogicCore нельзя, т.к. это потянет за собой зависимости от ненужных и "тяжелых" библиотек. По-моему это самое оно для применения посетителя. Пример на C#.
КЛ>Посмотрел Ваш пример. Не понял — а что мешает сделать то же самое без Visitor'а?
То же самое не получилось. Пример правда не полностью отражает ситуацию — это да, там еще сериализация была. Можно, конечно, было сделать виртуальный метод с показом диалогов, но тут не получалось без использования рефлекшена получить из десереализованного объекта некоего класса получить объект его класса-наследника.
Здравствуйте, Warturtle, Вы писали:
W>То же самое не получилось. Пример правда не полностью отражает ситуацию — это да, там еще сериализация была. Можно, конечно, было сделать виртуальный метод с показом диалогов, но тут не получалось без использования рефлекшена получить из десереализованного объекта некоего класса получить объект его класса-наследника.
Правильно ли я понял, что
Visitor понадобился только для того, чтобы Вы могли написать такой код:
foreach (var x in parts)
{
x.Accept(edit_visitor, null);
}
?
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, Warturtle, Вы писали:
W>>То же самое не получилось. Пример правда не полностью отражает ситуацию — это да, там еще сериализация была. Можно, конечно, было сделать виртуальный метод с показом диалогов, но тут не получалось без использования рефлекшена получить из десереализованного объекта некоего класса получить объект его класса-наследника.
КЛ>Правильно ли я понял, что Visitor понадобился только для того, чтобы Вы могли написать такой код:
КЛ>КЛ>foreach (var x in parts)
КЛ>{
КЛ> x.Accept(edit_visitor, null);
КЛ>}
КЛ>
КЛ>?
Да. Простое наследование с замещением взаимодействующего с пользователем метода не годилось, как я уже написал, из-за проблем с сериализацией. Т.е. объекты классов-наследников должны были жить в "пользовательской" части программы, при этом "логическая" часть не должна про эту надстройку ничего знать и работать (тоже "полиморфно", разумеется) с объектами "логических" классов. Работать — тут означает и сохранять их "состояние" на диск, чтобы потом восстанавливать эти объекты в памяти. Допустим десериализовали мы объект класса Action1 и нужно теперь получить объект класса-наследника (Action1UI, например), в котором будет замещен метод с "визуальной" частью. И как это сделать без рефлекшена, или каких-то регистраций типов, или еще чего-то такого — непонятно.
Здравствуйте, XopoSHiy, Вы писали:
XSH>Когда книжку "Design patterns" банды четырех переводили на русский, случился небольшой казус.
Кстати, а откуда эти информация? Ну, о том что казус случился? Насколько я помню книга так и называлась (и называется)
Приемы объектно-ориентированного проектирования. <b>Паттерны </b>проектирования. Так что использовать слово "Шблон" придумали уже потом. От части потому что их действительно используют в основном как постановочные шаллоны, а не как паттерны распознавания смысловых конструкций.
ЗЫ
С выводами согласен. В прочем примерно о том же сказано в разделе
Критика в описании на Википедии.
Автор(ы): Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес