Использование программных перечислений
Комментарии
Хорошее решение, разве что только скобки () глаза мусолят, но это терпимо.
Вот бы сделали "свойства", как в C#. С виду, обычные поля, а на деле - методы.
Хотя, если уж вносить изменения в встроенный язык 1С, то относительно этой задачи, надо сразу enum'ы делать.
Вот бы сделали "свойства", как в C#. С виду, обычные поля, а на деле - методы.
Хотя, если уж вносить изменения в встроенный язык 1С, то относительно этой задачи, надо сразу enum'ы делать.
Главная проблема, что для этого перечисления не сработает контекстная подсказка. Т.е. все равно придется идти и смотреть, какие значения бывают, копировать, вставлять...
Актуальная проблема. Исходя из собственного опыта, лучше все настройки, в том числе и сравнения "повесить" на пользователя. Назначить ответственных за механизмы/процессы. Для этого лучше всего сделать справочник или несколько с набором реквизитов/табличных частей для различных настроек. И настройки получать, например, ПриНачалеРаботыСистемы()
(4) Ну, тут речь не совсем об этом. Вам к уже введенным настройкам надо как-то обращаться в коде. То что должен быть момент передачи ответственности - полностью согласен, как и с тем что лучше такое реализовать пользовательской настройкой. Только имхо, это не взлетит в 90% случаев фикси. Но это уже тема для отдельной беседы)
(13) Основной профит - в удобной структуре кода. Кроме того, автоматически получается оптимизация - в том смысле что коллекция параметров не будет рассчитываться по 10 раз подряд. Неоднократно видел как люди в цикле пишут что-то вроде сч70_1_1 = ПланыСчетов.Хозрасчетный.НайтиПоКоду("70.1.1").
В каких случаях использовать - я теперь только так работаю, если есть несколько строковых констант, даже не задаюсь вопросом "надо ли". Это похоже на рассуждение: "зачем оформлять код по правилам ИТС, для своей разовой доработки?" - т. е. человек не понимает зачем вообще его нужно оформлять, не видит в чем удобство. Я например даже для небольших работ все оформляю - это копейки времени, которые окупаются с лихвой если из разовой доработки понадобится ваять что-то серьезное, или передать кому-то на анализ, или вспомнить что делалось через полгода. Это на подкорке. Чтобы я забыл код оформить - никогда такого не было. Также и здесь. Но это конечно мое "имхо")
В каких случаях использовать - я теперь только так работаю, если есть несколько строковых констант, даже не задаюсь вопросом "надо ли". Это похоже на рассуждение: "зачем оформлять код по правилам ИТС, для своей разовой доработки?" - т. е. человек не понимает зачем вообще его нужно оформлять, не видит в чем удобство. Я например даже для небольших работ все оформляю - это копейки времени, которые окупаются с лихвой если из разовой доработки понадобится ваять что-то серьезное, или передать кому-то на анализ, или вспомнить что делалось через полгода. Это на подкорке. Чтобы я забыл код оформить - никогда такого не было. Также и здесь. Но это конечно мое "имхо")
(15) "Основной профит - в удобной структуре кода". Не согласен. "Структура кода" удобнее не становится. Я не про счета и кэширование (это уже несколько про другое), а про саму идею программных перечислений. В плане удобства - получаем сомнительный аргумент "красивенько" против дополнительного времени на реализацию и въезжание постороннего программиста в этот код. Вот своевременное падение в рантайме для легкого поиска ошибки - это профит. Если бы во время компиляции ругалось - это вообще был бы всем профитам профит. А если бы еще и автокомплишн в конфигураторе - практически полноценные перечисления бы вышли.
(17) Именно в нем. "Тупой код с хорошей структурой, лучше чем тупая структура с гениальным кодом". Про время на реализацию - расхожее заблуждение. Дровосек рубит деревья, у него спрашивают - мужик, че ты мучаешься, у тебя ж топор тупой. Наточи топор. А он отвечает: "мне НЕКОГДА! мне надо РУБИТЬ". И все "рубят". Код должен читаться как книга.
По приоритету, для меня так:
- "въехать" в это можно достаточно быстро
- при этом можно быть уверенным что коллекция заполняется только в одном конкретном месте, благодаря использованию фиксированной структуры
По приоритету, для меня так:
- "въехать" в это можно достаточно быстро
- при этом можно быть уверенным что коллекция заполняется только в одном конкретном месте, благодаря использованию фиксированной структуры
Идея хорошая, но все же ИМХО лучше один раз вызвать функцию и вернуть в локальную переменную структуру и работать с ней, чем 10 раз вызывать и проверять, проиницилизирована ли нужная нам структура.
Но это так просто придирка, хотя когда подобных структур будет достаточно много (хотя я даже не представляю себе род такой задачи), поиск и копирование структур может стать достаточно ощутимым.
Но это так просто придирка, хотя когда подобных структур будет достаточно много (хотя я даже не представляю себе род такой задачи), поиск и копирование структур может стать достаточно ощутимым.
(20) Тут как раз все в порядке.
Во-первых, ленивая инициализация - это само по себе хорошо.
Во-вторых, явная инициализация на старте - это еще одна "точка привязки" в коде для реализации этой концепции. Абсолютно лишняя.
ЗЫ. Поиск в структуре по ключу не должен стать ощутимым, даже если ключей будет много. Если я правильно помню - это хэшированная структура данных. Ну, разве что свопить начнет :) А копирования тут нет.
Во-первых, ленивая инициализация - это само по себе хорошо.
Во-вторых, явная инициализация на старте - это еще одна "точка привязки" в коде для реализации этой концепции. Абсолютно лишняя.
ЗЫ. Поиск в структуре по ключу не должен стать ощутимым, даже если ключей будет много. Если я правильно помню - это хэшированная структура данных. Ну, разве что свопить начнет :) А копирования тут нет.
А можно функцию СтатусыЗаявок() разместить в глобальном общем модуле с повторным использованием возвращаемых значений на время сеанса?
Тогда и переменная мСтруктураКэшПрограммныхПеречислений не нужна и можно будет использовать СтатусыЗаявок() в других модулях.
Например если я хочу передать СтатусыЗаявок().Отказ в качестве параметра из другого модуля, то в другом модуле функцию СтатусыЗаявок() не видно. А если разместить ее в глобальном модуле, то будет видно.
unichkin, Что об этом думаете?
Тогда и переменная мСтруктураКэшПрограммныхПеречислений не нужна и можно будет использовать СтатусыЗаявок() в других модулях.
Например если я хочу передать СтатусыЗаявок().Отказ в качестве параметра из другого модуля, то в другом модуле функцию СтатусыЗаявок() не видно. А если разместить ее в глобальном модуле, то будет видно.
unichkin, Что об этом думаете?
(0) Более другой вариант.
Заполнять такие перечисления в таблицы на форме, проводить программное сопоставление, окончательную корректировку оставлять пользователю.
Обработку данных производить с учетом полученных таблиц соответствий (количество значений в которых неопределено и разработчика не волнует - он работает со стандартным справочником/перечислением из соответствия)
в таком варианте снижается требование к качеству заполнения таблицы для загрузки.
тавар ф пути
номенклатуро в перевозке
и ТоварВпути
обработаются одинаково корректно.
Заполнять такие перечисления в таблицы на форме, проводить программное сопоставление, окончательную корректировку оставлять пользователю.
Обработку данных производить с учетом полученных таблиц соответствий (количество значений в которых неопределено и разработчика не волнует - он работает со стандартным справочником/перечислением из соответствия)
в таком варианте снижается требование к качеству заполнения таблицы для загрузки.
тавар ф пути
номенклатуро в перевозке
и ТоварВпути
обработаются одинаково корректно.
(23)
(24) Я думаю, если дорабатываете конфу - то добавьте нормальное перечисление.
Этот способ хорош для константных значений, уникальных в каком-то определенном алгоритме (внешнем или внутреннем). Например - статусы заявок приходят к нам в виде текста. Но в конфигурации это наверняка перечисление. Здесь структура нужна только для того, чтобы удобно и качественно проверять все входящие значения статусов.
Еще пример с потолка (кривая методология, просто чтобы отразить суть вопроса): скажем в документе оператор заполняет строковое поле "Причина отказа". Причина может вводиться как из заранее определенного списка, так и произвольно - если установлен соотв. флаг. Так вот - если не добавлять в конфигурации нормальное перечисление (а лучше добавить, сделав "причину" составным полем), то да, наверное логично так сделать. Только модуль ПовтИсп хранит кэш 20 минут. Возможно лучше использовать какие-то существующие кэши конфигурации. И "мСтруктураКэшПрограммныхПеречислений" не будет нужна только для этого конкретного случая.
(25) Если рассуждать только с позиции загрузки заявок - то конечно, да, лучше дать на откуп пользователю. А еще лучше проговорить это все в ТЗ. Потом при формировании структуры перечисления собрать данные из таблицы формы - да, логично, почему нет. Но загрузка заявок - это ведь частный случай, я его использовал для примера. У меня например была задача, в которой я создавал программное перечисление для событий журнала регистрации. Т.е. было примерно так:
Потом для фильтров использовал СобытияЖР().Проведение и т.п.
Мне кажется, что автор начиная со первого примера "СтруктураСтатусыЗаявок" забыл про своё-же замечание: (буква "О" <> "о").
- не вижу ошибки, ткните пальцем если не сложно.
(24) Я думаю, если дорабатываете конфу - то добавьте нормальное перечисление.
Этот способ хорош для константных значений, уникальных в каком-то определенном алгоритме (внешнем или внутреннем). Например - статусы заявок приходят к нам в виде текста. Но в конфигурации это наверняка перечисление. Здесь структура нужна только для того, чтобы удобно и качественно проверять все входящие значения статусов.
Еще пример с потолка (кривая методология, просто чтобы отразить суть вопроса): скажем в документе оператор заполняет строковое поле "Причина отказа". Причина может вводиться как из заранее определенного списка, так и произвольно - если установлен соотв. флаг. Так вот - если не добавлять в конфигурации нормальное перечисление (а лучше добавить, сделав "причину" составным полем), то да, наверное логично так сделать. Только модуль ПовтИсп хранит кэш 20 минут. Возможно лучше использовать какие-то существующие кэши конфигурации. И "мСтруктураКэшПрограммныхПеречислений" не будет нужна только для этого конкретного случая.
(25) Если рассуждать только с позиции загрузки заявок - то конечно, да, лучше дать на откуп пользователю. А еще лучше проговорить это все в ТЗ. Потом при формировании структуры перечисления собрать данные из таблицы формы - да, логично, почему нет. Но загрузка заявок - это ведь частный случай, я его использовал для примера. У меня например была задача, в которой я создавал программное перечисление для событий журнала регистрации. Т.е. было примерно так:
СтруктураСобытийЖурнала = Новый Структура();
СтруктураСобытийЖурнала.Вставить("НачалоСеанса", "_$Session$_.Start");
СтруктураСобытийЖурнала.Вставить("КонецСеанса", "_$Session$_.Finish");
СтруктураСобытийЖурнала.Вставить("Проведение", "_$Data$_.Post");
// ну и т. д.
...Показать СкрытьПотом для фильтров использовал СобытияЖР().Проведение и т.п.
Если инвертировать проверку свойства в мСтруктураКэшПрограммныхПеречислений, то это позволит уменьшить уровни вложенности и код будет читаться легче. Сравните:
Функция СтатусыЗаявок()
Если мСтруктураКэшПрограммныхПеречислений.Свойство("СтатусыЗаявок") Тогда
Возврат мСтруктураКэшПрограммныхПеречислений.СтатусыЗаявок;
КонецЕсли;
СтруктураСтатусыЗаявок = Новый Структура;
СтруктураСтатусыЗаявок.Вставить("НаУтверждении", "НаУтверждении");
СтруктураСтатусыЗаявок.Вставить("ТоварвПути", "ТоварВПути");
СтруктураСтатусыЗаявок.Вставить("КОтгрузке", "КОтгрузке");
СтруктураСтатусыЗаявок.Вставить("Отказ", "Отказ");
мСтруктураКэшПрограммныхПеречислений.Вставить("СтатусыЗаявок", Новый ФиксированнаяСтруктура(СтруктураСтатусыЗаявок));
Возврат мСтруктураКэшПрограммныхПеречислений.СтатусыЗаявок;
КонецФункции...Показать Скрыть
(28) Я обычно стремлюсь к сокращению "Возвратов", если можно рассчитать значение внутри функции и вернуть результат в конце метода - так и делаю; приведенный вами код не кажется мне более читабельным решением, может дело вкуса. Делайте как вам удобнее) Я останусь при своем.
Кстати, сейчас подумал - что в функциях обычно минимизирую возвраты, а в процедурах как раз наоборот - если есть условие прерывания, стараюсь выполнить его в самом начале, чтобы не использовать лишних расчетов.
Кстати, сейчас подумал - что в функциях обычно минимизирую возвраты, а в процедурах как раз наоборот - если есть условие прерывания, стараюсь выполнить его в самом начале, чтобы не использовать лишних расчетов.
(29) Единая точка выхода, ага, нас тоже так в школе учили. Но если уж вы предлагаете способы, как улучшить читаемость кода, идите дальше. Согласен, в приведённом мной примере данное изменение не сильно улучшит читаемость, но примените его к вашей функции ИспользуемыеСчета(), и там такое улучшение будет уже более актуально. Матчасть:
(30) Да нет в "ИспользуемыеСчета()" ветка условия всего одна, так что принцип тот же что и в (29). То, что описывает приведенная вами статья я стараюсь соблюдать, и это как-то всегда на уровне спинного мозга осознавал - что не стоит допускать дебрей Case-Of Если-Тогда. Однако за наводку и интерес к моей статье - спасибо)
Мне в данном конкретном случае кажется более логичным заполнять структуру именно внутри условия. Возможно потому, что основные цели этих методов (для вызова программного перечисления) - это заполнение соотв. кэша, и более логично в начале алгоритма видеть инициализацию коллекции по условию ее отсутствия. Тут с т.з. рефакторинга было бы неплохо вынести код по заполнению структуры счетов в внешний метод, но я не люблю перегружать программный интерфейс методами (пусть даже и служебный). Т.е. использоваться -то он будет все-равно только в одном месте. Вот если его глобальным сделать, тогда другое дело. Было бы нечто вроде такого:
Мне в данном конкретном случае кажется более логичным заполнять структуру именно внутри условия. Возможно потому, что основные цели этих методов (для вызова программного перечисления) - это заполнение соотв. кэша, и более логично в начале алгоритма видеть инициализацию коллекции по условию ее отсутствия. Тут с т.з. рефакторинга было бы неплохо вынести код по заполнению структуры счетов в внешний метод, но я не люблю перегружать программный интерфейс методами (пусть даже и служебный). Т.е. использоваться -то он будет все-равно только в одном месте. Вот если его глобальным сделать, тогда другое дело. Было бы нечто вроде такого:
Функция ИспользуемыеСчета()
Если НЕ мСтруктураКэшПрограммныхПеречислений.Свойство("ИспользуемыеСчета") Тогда
СтруктураИспользуемыеСчета = Новый Структура;
// Чтобы добавить счет, добавьте сюда его код
СтрокаКодовСчетов = "10, 10.3, 19, 60.1, 60.2, 62, 51, 51, 70, 70.1, 76.АВ, 90, 90.01, 90.02";
СтруктураИспользуемыеСчета = ОбщегоНазначенияБП.СтруктураСчетовПоСтрокеКодов(СтрокаКодовСчетов );
мСтруктураКэшПрограммныхПеречислений.Вставить("ИспользуемыеСчета", Новый ФиксированнаяСтруктура(СтруктураИспользуемыеСчета));
КонецЕсли;
Возврат мСтруктураКэшПрограммныхПеречислений.ИспользуемыеСчета;
КонецФункции
...Показать Скрыть
Понимаю что поздновато отписываюсь, но как вам такой вариант?
Плюсы:
1. Можно использовать в формах &НаСервере, вместо того чтобы каждый раз инициализировать переменную после клиента;
2. Есть автодополнение и контекстная подсказка;
3. Если даже набрать имя функции неправильно - ошибка всплывет на этапе синтаксической проверки (при отладке вашего способа не всегда может получится все ветки прогнать, и до ветки с ошибочно набранным значением можно не добраться)
4. По идее возвращаемое значение таких функций должно "инлайниться" в место использования, так что производительность должна быть такая же как при обычном сравнении со значением, а если и нет то что у меня, что у Вас накладные расходы на вызов функции так или иначе идут.
Минусов с ходу могу назвать только два:
1. Засорение контекстной подсказки, для чего и добавил в начало _;
2. Такое "перечисление" не передашь в другой модуль, разве что вместе со всем текущим контекстом (ЭтотОбъект придется передавать из общего модуля или формы) и делать данные функции экспортными.
#Область ПрограммноеПеречисление_СтатусыЗаявок
Функция _СтатусыЗаявок_НаУтверждении() Возврат "НаУтверждении" КонецФункции
Функция _СтатусыЗаявок_ТоварВПути() Возврат "ТоварВПути" КонецФункции
Функция _СтатусыЗаявок_КОтгрузке() Возврат "КОтгрузке" КонецФункции
Функция _СтатусыЗаявок_Отказ() Возврат "Отказ" КонецФункции
#КонецОбласти
Функция ДанныеФайлаУспешноСчитаны() Экспорт
//...
СтатусЗаявки = СокрЛП(Excel.Cells(1, Сч).Text);
Если СтатусЗаявки = _СтатусыЗаявок_НаУтверждении() Тогда
//...
ИначеЕсли СтатусЗаявки = _СтатусыЗаявок_ТоварВПути() Тогда
//...
ИначеЕсли СтатусЗаявки = _СтатусыЗаявок_КОтгрузке() Тогда
//...
КонецЕсли;
Возврат Истина;
КонецФункции
...Показать СкрытьПлюсы:
1. Можно использовать в формах &НаСервере, вместо того чтобы каждый раз инициализировать переменную после клиента;
2. Есть автодополнение и контекстная подсказка;
3. Если даже набрать имя функции неправильно - ошибка всплывет на этапе синтаксической проверки (при отладке вашего способа не всегда может получится все ветки прогнать, и до ветки с ошибочно набранным значением можно не добраться)
4. По идее возвращаемое значение таких функций должно "инлайниться" в место использования, так что производительность должна быть такая же как при обычном сравнении со значением, а если и нет то что у меня, что у Вас накладные расходы на вызов функции так или иначе идут.
Минусов с ходу могу назвать только два:
1. Засорение контекстной подсказки, для чего и добавил в начало _;
2. Такое "перечисление" не передашь в другой модуль, разве что вместе со всем текущим контекстом (ЭтотОбъект придется передавать из общего модуля или формы) и делать данные функции экспортными.
(32)
1. Объявляете реквизит формы "СтруктураКэшПрограммныхПеречислений", с произвольным типом реквизита... А остальное все то-же) Это если для формы. Вообще правильнее все-же к форме относить то, что касается *формы* - интерактив, все расчеты лучше отправлять на сервер, т.е. в модуль объекта. Ну тут можно много рассуждать и говорить - по всякому можно. Если говорим о внешней обработке можно сделать реквизит обработки произвольного типа - он будет доступен и с сервера и с клиента. Если о объекте конфигурации - сделайте реквизит формы. Или - вызов из модуля ПовтИсп.
2. Если учесть что различие только в префиксе - имхо, не очень удобно для набора, когда много коллекций.
С моей точки зрения, когда перечисление обосабливается в свой метод - это и нагляднее и удобнее. Ну да, синтакс контроль не заругается. Пишите аккуратнее) Каждому свое конечно, используйте то что вам больше подходит. Но мне с таким кодом было бы работать тяжеловато. Подчеркивание в начале метода - это нарушение правил образования имен переменных. Ну и плюшки с ленивой инициализацией теряются.
1. Объявляете реквизит формы "СтруктураКэшПрограммныхПеречислений", с произвольным типом реквизита... А остальное все то-же) Это если для формы. Вообще правильнее все-же к форме относить то, что касается *формы* - интерактив, все расчеты лучше отправлять на сервер, т.е. в модуль объекта. Ну тут можно много рассуждать и говорить - по всякому можно. Если говорим о внешней обработке можно сделать реквизит обработки произвольного типа - он будет доступен и с сервера и с клиента. Если о объекте конфигурации - сделайте реквизит формы. Или - вызов из модуля ПовтИсп.
2. Если учесть что различие только в префиксе - имхо, не очень удобно для набора, когда много коллекций.
С моей точки зрения, когда перечисление обосабливается в свой метод - это и нагляднее и удобнее. Ну да, синтакс контроль не заругается. Пишите аккуратнее) Каждому свое конечно, используйте то что вам больше подходит. Но мне с таким кодом было бы работать тяжеловато. Подчеркивание в начале метода - это нарушение правил образования имен переменных. Ну и плюшки с ленивой инициализацией теряются.
Разделы |
|---|
Платформа |
Конфигурации |
Заказ-проекты
Доработка конфигурации Драйвер Wi-Fi ТСД PRO от Клеверенс
бюджет 15 000руб.
Обмен 1С - Телеграм
бюджет 5 000руб.
Доработка обработки для облачного сервиса
бюджет 2 500руб.