Значение display метода по его названию

[macklakov]

Цитата:

Сообщение от TasmanianDevil

Ежели есть еще какие подводные камни - поведайте, буду весьма благодарен, особенно если на проекте в аттачменте приведете примеры таких проблем.

1. Название вариантов enum-а несет в себе гораздо больше смысловой нагрузки, чем Id класса. В сложных расчетах этот параметр передается через 10-к методов, а иногда и контейнеров, в результате определить, что послужило причиной создания данного объекта и почему он являеся инстансом данного класса невозможно или очень сложно.
2. Т.к. перекрестные порушены, совсем не весело вносить существенные изменения в такой механизм. Т.к. механизм искуственно усложнен + не работают проверки сигнатур, любые изменения могут привести к неожиданным эффектам.
3. Если писатель допустил ошибку, найти ее и исправить крайне тяжело.
4. Рушится сама прадигма ООП. Такие конструкции даже на функциональное программирование не тянут, это больше похоже на использование GOTO.

Цитата:

Сообщение от TasmanianDevil

Программисту - труднее(отсутствует в момент написания проверка на типы и количество аргументов и нет подсветки синтаксиса), консультанту же должно быть по барабану.

О чем и речь. Консультанту и пользователю от этого пользы никакой, разве что подтормаживает немного сильнее. Зато разработчику масса проблем. Спрашивается, для чего создаются такие "универсальные решения"?

Цитата:

Сообщение от TasmanianDevil

В любом случае конечного вопроса не снимает - зачем сделана такая возможность ?

Для создания инструментов разработчика. К примеру, если хочется модифицировать или создать свой механизм экспорта/импорта данных, без подобных механизмов было бы очень сложно.

Цитата:

Сообщение от TasmanianDevil

Скорее всего поимел, ибо как правило, мысль о подобных "универсализмах" приходит после того как вдоволь "наелся" рутинным допрограммированием и просыпается разумная лень оптимизаторская, что не есть плохо, но вот хорошо ли это - зависит от реализации задуманного.

Я не против обобщений и универсальности как таковых. Я против использования классов Dict... в бизнес-логике.

[TasmanianDevil]

Цитата:

Сообщение от macklakov

Я не против обобщений и универсальности как таковых. Я против использования классов Dict... в бизнес-логике.

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