десяток тривиальных функций, каждая из который принимает аргумент определенного типа и возвращает соответствующее значение. Или одна функция в которую передает базовы класс, а через него определяет какой тип у ножного элемента (свитч) и потом еще (свчит) для создания нужного возвращаемого значения ?) PS. а если к этому добавить, что создание сложной функции позволит написать еще одну универсальную функцию, вместо того чтобы еще в некоторых других 8-ми функциях не дублировать почти одинаковый набор строк ? PPS. возвращающийся объект строка.
свитч не по ООП-фэншую Одинаковый код в виртуальный метод базового класса, остальное определяют наследники ЗЫ Ну это если ты придерживаешься ооп-подхода
вся заковырка в том что код "почти одинаковый", т.е. идет 250 строк кода по формированию отчета, и в 2-3 местах либо цикл начинается не от 0 а от 1, либо заканчивается не на count а на count - 2, либо форматная строка имеет вид не "property{0}" а "property{0}key". Функции формирования отчета вынесены в отдельный класс, у которого есть метод принимающий некий базовый класс, член которого указывает на другой некий базовый клас от которого унаследованно еще пяток, и в базовом классе есть поле по которому можно определить элемент какого потомка содержит этот класс %) Переделать это все это значит честно переписать часть проекта )) А если начать это то это 100% приведет к необходимости переписать другие компоненты проекта, ну и так до самых верхов )). Воот о феншуе тут не слыхали )) А благодаря паре свитчей я смог сократить код 4 функций с наверно строк 1000, до этак 120 (и еще строк 300 на вспомогательные функции) Код конечно очень быдлокодый, зато анализировать стало проще
вообще всегда стоит следовать принципам ООП, но в некоторыхх ситуациях (как в твоей) это себя не оправдывает, по этому стоит прибегать к использованию более удобных способов, в частности switch/case. главное не злоупотреблять и перед этим проанализировать, действительно ли невозможно организовать всё на уровне классов.