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

[TasmanianDevil]

Цитата:

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

... лучше захардкодить все реально существующие варианты, чем ваять очередное "универсальное решение" на все случаи жизни...

N-угольные колеса вместо круглых ?
А потом при появлении нового варианта перетачивать на (N+1)-угольное, то бишь допрограммируя ?

Цитата:

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

Мне недавно пришлось столкнуться с настройкой, в которой нужно выбрать класс, который будет производить рассчет. Ни консультанту ни программисту от таких решений не легче.

Простите, а чем это отличается функционально от выбора в какой-либо настройке некоего значения Enum'а, по которому в дальнейшем некий суперкласс породит своего потомка с отличным от других функционалом расчета? Программисту - труднее(отсутствует в момент написания проверка на типы и количество аргументов и нет подсветки синтаксиса), консультанту же должно быть по барабану.

Цитата:

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

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

Проблемы консультанта, притом большие, если Enum в настройке он понимает, а класс - нет. Консультант без некоей доли общего программерского багажа по своей предметной части гораздо менее ценен, чем имеющий такой багаж.
Дебажить беда ? Дебажится аки "отче наш", единственная проблема навскидку видится в невозможности увидеть внутреннюю структуру объекта нашего класса, создаваемого через абстрактный объект, в области его жизни, однако при вызове любых методов оного - все как на ладони внутри этих методов. Ежели есть еще какие подводные камни - поведайте, буду весьма благодарен, особенно если на проекте в аттачменте приведете примеры таких проблем.

Цитата:

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

И даже писатель стоящих скилзов не получил. Писать такие модификации не сложно, гордиться здесь нечем

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

Спорить можно долго, но давайте озадачимся вопросом - зачем они вообще были сделаны в системе, эти возможность и доступность вызова метода класса по имени для разработчика ? Атавизм это или возможность расширения ?

[Yprit]

Цитата:

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

Простите, а чем это отличается функционально от выбора в какой-либо настройке некоего значения Enum'а

1. Отсутствием контроля типов, правильности сигнатуры и т.п. в момент компиляции - все ошибки полезут в рантайме
2. Невозможностью использования перекрестных ссылок

В принципе, еще куча мелких проблем. Для знакомства со всеми ними достаточно плотно поработать с модулем "Расчеты с персоналом", функционалом счетчиков, например. Дебажить... Да, только и остается, что дебажить - втрое больше времени занимает, но ничего другого нам не оставили.

[TasmanianDevil]

Цитата:

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

1. Отсутствием контроля типов, правильности сигнатуры и т.п. в момент компиляции - все ошибки полезут в рантайме
2. Невозможностью использования перекрестных ссылок

В вопросе ключевым словом было "функционально" и по сути своей больше к консультанту относилось. Именно функционально в плане работы логики - фактически ничем не отличается. Про программиста в принципе изначально ясно было.

Про перекрестные спасибо - совсем про них забыл что-то я.

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

[mazzy]

Цитата:

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

один из возможных путей построения всяких удобностей.

Удобностей для кого?
Можно привести примеры удобностей?

[TasmanianDevil]

Цитата:

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

Можно привести примеры удобностей?

Например, вот ...

[mazzy]

Цитата:

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

N-угольные колеса вместо круглых ?
А потом при появлении нового варианта перетачивать на (N+1)-угольное, то бишь допрограммируя ?

Можно я повторюсь?

Цитата:

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

Да, конечно, если программист захочет добавить функционал, то в первом случае он должен добавить всего лишь один метод, а во втором - расширить обертку. Но это только кажется. Поскольку в первом случае "настраивать" систему сможет только програмист. Поэтому в первом случае программист делает никому не нужную работу - вместо того, чтобы просто запрограммировать выбор в коде, он делает никому не нужный интерфейс, которым сможет воспользоваться только он сам (и то только в первое время - потом забудет как это работает и все равно полезет в код по новой).

[macklakov]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[TasmanianDevil]

Цитата:

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

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

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