Adler
Даже проглядел гоф4, что-то ничего не подходит.
Эээ...менеджер 3 структур. В методе До нет никаких особенностей. Пока это просто структура которая умеет что-то делать с 3мя другими структурами. Причем DoA и DoB еще даже не обязательно должны делать что-то схожее.
Еслиб это были конструкторы то это был бы adapter. Но это просто 3 функции-члена.
Вобщем я сдаюсь.
Adler
> Кто-нибудь видит pattern в этом коде?
Нет, ибо говнокод:) Три совершенно разных сущности связаны в одном месте - это спаггети код. Кроме того это явный признак God Object (три сущности засунуты в один класс). Кроме того такой подход ведет к копипасту (куча однотипных функций).
тру пустые структуры, три пустых метода. Я же говорю, foobar.
Adler
> static visitor
Что-то оно некрасиво. Лучше дальше Си его не нести.
Adler
> Чем больше кода, тем больше в нём закономерностей и тем труднее понять какую из
> них хочет показать автор.
Но после некоторого количества уже не угадать, что именно имел в виду автор. Если бы кроме foo был бы bar с такими же методами, был бы double dispatch. А так - непонятно что.
Adler
> тут каждый метод принимает один параметр уникального типа.
Ну так или иначе это не visitor. тк реализация шаблона должна быть не примерна похожа, а точно соответствовать каноничной реализации.
Adler
> я считаю, что класс bar не нужен для того, чтобы заметить закономерность типа
> static visitor у класса foo.
потому что в твою схему укладывается и
struct Document{}; struct File{}; struct Message{}; struct Manager{ void SendDocument(Document&){}; void CheckFile( File&){}; void SendMessage( Message&){}; }
т.е. то что war_zes назвал god object и куча других примеров. Привел бы ты bar - я думаю ни у кого вопросов что за паттерн не возникло.
равен
> Есть структуры данных и есть алгоритмы, решающие определенные задачи.
> Потом, внезапно, приходит банда 4-х и заявляет: "А мы не такие, а у нас
> паттерны!!11"
> А в чем смысл всего этого? (в жопу пусть себе запихают свои паттерны)
Нету никаких ЛИШНИХ сучностей. Есть горький опыт на разных проджектах, бородатые дядьки пытались образумить молодёжь от болезни "делаю сам и плюю на чужой опыт "
AvrDragon
> А вот как и для чего использованы остальные уже не очевидно.
Да ну всё же очевидно. По секрету скажу что сами паттерны присутсвуют в игровых проектах. Просто часто изобретается лисопед :)
Strategy как отделение поведения от сущности. Factory чтобы гибко работать с интерфейсом и тд
Adler
> Если предположить что мы рассматриваем классы в которых методы не меняют
> глобальные переменные
Есть же еще поля класса.
Если там
void LoadTexture(string&){}; void LoadTextureFromID( Resource&){}; void DeleteTexture( Texture&){};
это тоже такой визитор?
Adler
Ясно.
Adler
> что суть ООП это потерять тип объекта, а потом костылями пытаться его получить?
Да пожалуйста. Тогда суть недо-ООП это не терять тип объекта, но потом пытаться делать костыли для работы с разными типами одним способом :)
innuendo
> Нету никаких ЛИШНИХ сучностей. Есть горький опыт на разных проджектах,
> бородатые дядьки пытались образумить молодёжь от болезни "делаю сам и плюю на
> чужой опыт "
Если речь идет о ООП, то лишние сущности там появляются постоянно
Самый правильный подход - это изначальная ориентировака на решение любой задачи - это разбиение на последовательно/параллельно.
У любой задачи есть ограниченные ресурсы по решению, в рамках этих ресурсов разрабатывается код, дающий максимальную производительность.
От железа до софта принцип все тот-же.
Исходить надо из этого, а не мне вот этот паттерн больше нравится :)
равен
> > Нету никаких ЛИШНИХ сучностей. Есть горький опыт на разных проджектах,
> > бородатые дядьки пытались образумить молодёжь от болезни "делаю сам и плюю
> > на
> > чужой опыт "
> Если речь идет о ООП, то лишние сущности там появляются постоянно
Например ?
Тема в архиве.