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

[macklakov]

Цитата:

Сообщение от Андрей К.

Доброго времени суток.
Стоит задача: из списка дисплейметодов определенной таблицы(список уже реализован) необходимо выбрать интересующий метод (хранится лишь его название) и выводить значение этого дисплейметода у текущего курсора.

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

Если я правильно понимаю, будет m таблиц, на каждой из которых n методов с одинаковой сигнатурой

Я бы реализовал это так:
Отмапить таблицы и реализовать на мапе n методов, которые делегируют поведение соответствующим методам таблиц.
На форме показывать мап. На форме же реализовать дисплей, который выберет один из n методов мапы и делегирует ему свое поведение.

В чем приемущество: легко дебажить и код читаемый т.к. нет метапрограммирования. Подозреваю, что и работать будет быстрее
P.S. А еще лучше вывести все n методов в грид и просто управлять видимостью

[mazzy]

Цитата:

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

На форме же реализовать дисплей, который выберет один из n методов мапы и делегирует ему свое поведение.

Эх... Еще одну попытку сделаю, поддержку Alex_KD

Написано "который веберет"
Кто выберет? Пользователь? Как он выберет? По названию метода? А пользователю что-нибудь говорит название метода?

Т.е. на самом деле варианта два:
1. машиноориентированный: Заставлять пользователя выбирать из названий методов. Никаких хелпов, подсказок, описаний. Если пользователю что-то непонятно, то он должен лезть в код. Т.е. этот подход рассчитан на программиста, а не на пользователя.
2. человекоориентированный: сделать обертку над методами, чтобы дать описания, инструкции, хелпы, подсказки и прочую мутотень. Скорее всего, описания должны быть не на программистком матерном, а на пользовательском языке - языке предметной области.

Если все равно делается обертка, то поставленная в исходном сообщении задача НЕ ИМЕЕТ практического смысла.
В обертке все равно будет switch/case по заранее предусмотренным пунктам.

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

[Владимир Максимов]

Цитата:

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

Т.е. на самом деле варианта два:
1. машиноориентированный:
2. человекоориентированный:

Эх... Тоже не удержался

На самом деле, вариант один: программистский! Поскольку все-равно, рано или поздно, но программисту придется лезть в код, чтобы понять, "как оно тикает".

Всякие там "человекоориентированные" настройки - это кажущаяся автоматизация. Количество разных птичек и галочек в Axapte просто безумное. Ни один человек не в состоянии их всех упомнить. Вот и получается такое "гуано". Птичек уж больно много .

А если еще вспомнить про текучку кадров, изменение ТЗ в процессе разработки, постянные авралы и т.д. и т.п., то ... Нет, лучше не вспоминать

Собственно, написание "человекоориентированного" интерфейса задача сопоставимая с написанием подробной справки по данному функционалу. Сопоставимая по результату. Хотя "настоящие программисты", конечно, не пишут не то, что справку, а даже комментарии в коде

Я бы рассмотрел задачу написание ОДНОГО метода, но который возвращает разные значения в зависимости от переданных параметров. Ну, или метод-диспетчер (класс-диспетчер), который вызывает соответствующие методы через switch/case. А в качестве параметра использовать BaseEnum, который "человеческим" языком объясняет какой метод надо вызывать.

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

[macklakov]

Цитата:

Сообщение от Владимир Максимов

Количество разных птичек и галочек в Axapte просто безумное. Ни один человек не в состоянии их всех упомнить.

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

Мне недавно пришлось столкнуться с настройкой, в которой нужно выбрать класс, который будет производить рассчет. Ни консультанту ни программисту от таких решений не легче. Консультант все равно до конца не понимает, чем один класс от другого отличается. А разработчику совсем беда, дебажить рассчет, который эти классы использует, практически не реально.
И даже писатель стоящих скилзов не получил. Писать такие модификации не сложно, гордиться здесь нечем

[Владимир Максимов]

Цитата:

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

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

Так я с этим и не спорю. Я "прицепился" к делению интерфейса на "машино-" и "человеко-" ориентированный в том понимании, как это описал Сергей. Как мне кажется, разница между ними в такой постановке весьма условная.

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Количество разных птичек и галочек в Axapte просто безумное.

Я и не говорил, что стандартная Аксапта - идеал человекоориентированного подхода. И российская, и международная.

Цитата:

Сообщение от Владимир Максимов

Ни один человек не в состоянии их всех упомнить. Вот и получается такое "гуано". Птичек уж больно много

Мне кажется, что птичек мало.
Но они так по-дурацки расставлены

Цитата:

Сообщение от Владимир Максимов

Собственно, написание "человекоориентированного" интерфейса задача сопоставимая с написанием подробной справки по данному функционалу.

А вот здесь категорически не согласен.
Написание человекоориентированного интерфейса - самая простая задача, если понять что же человек на самом деле хочет. Просто решайте ЕГО проблемы, а не свои собственные.

Цитата:

Сообщение от Владимир Максимов

Так я с этим и не спорю. Я "прицепился" к делению интерфейса на "машино-" и "человеко-" ориентированный в том понимании, как это описал Сергей. Как мне кажется, разница между ними в такой постановке весьма условная.

Может быть, не спорю.

[Lucky13]

Цитата:

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

Написание человекоориентированного интерфейса - самая простая задача, если понять что же человек на самом деле хочет. Просто решайте ЕГО проблемы, а не свои собственные.

А если человек хочет большую красную кнопку "СЧАСТЬЕ"?

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Так я с этим и не спорю. Я "прицепился" к делению интерфейса на "машино-" и "человеко-" ориентированный в том понимании, как это описал Сергей. Как мне кажется, разница между ними в такой постановке весьма условная.

Просто уже неделю приходится заниматься налоговым учетом в Аксапте...
Уровень желчи от этого резко поднимается...

[TasmanianDevil]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

[Yprit]

Цитата:

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

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

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

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

[TasmanianDevil]

Цитата:

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

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

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

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

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

[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-семейства ...

[mazzy]

Цитата:

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

Я бы реализовал это так:
Отмапить таблицы и реализовать на мапе n методов, которые делегируют поведение соответствующим методам таблиц.
На форме показывать мап. На форме же реализовать дисплей, который выберет один из n методов мапы и делегирует ему свое поведение.

Если на проекте сознательно выбирается машиноориентированный программистский подход, то я бы предпочел такое решение, нежели динамическое программирование (DictTable-CallObject) без проверок и с постоянной угрозой runtime-ошибок.