Как можно наиболее оптимально создать объект-фабрику (обработку, не xdto) с сохранением состояния между вызовами?

Question

[hloya_ram]

Добрый день.
Очень хотелось уйти от работы с общим модулем, в процедуры которого с каждым вызовом необходимо будет передавать некоторые параметры (часто -- одни и те же).
Написала код в модуле объекта Обработки. Обработка работает, как фабрика (factory); ну или пытается ею быть :)
Суть данной фабрики -- видоизменять форму любого другого объекта (в моем случае это СправочникОбъект), из которой осуществляется вызов фабрики. Например, создавать или удалять элементы, изменять цвет и т.п.
Основная проблема для меня -- это сохранение состояния объекта-фабрики между нажатиями тех или иных кнопок.
На текущий момент состояние (экземпляр созданного объекта обработки) записываю во временном хранилище (в самом начале, в процедуре Инициализация(СтруктураПараметров)) и оттуда каждый раз беру.

Подскажите, насколько этот путь, по вашему мнению, является мертвым?
Хотелось бы узнать, занимался ли кто-либо подобного рода "мракобесием". Поделитесь, пожалуйста, опытом или некоторыми ссылками.

Comments

[Sgr_A]

Стало любопытно. Тоже не совсем понял проблему. Можно подробнее объяснить? )

[hloya_ram]

Алексей Петров, проблема (на текущий момент) заключается в том, что у меня уж никак не получается хранить во временном хранилище (или где-либо еще, помимо явной передачи при каждом вызове функции модуля объекта) значение ЭтаФорма, к которому я в следствие обращаюсь -- оно просто ломается (при обращении получаю "Неопределено" -- и 1С падает).
Как я понимаю, 1С просто так делать не умеет.
Тогда единственный вариант -- передавать значение ЭтаФорма при каждой итерации функции? Бесконечно хотелось этого избежать. Или же сделать это чем-то неявным (чтобы неведомым образом объект обработки узнавал о том, что он был вызван из формы справочника), но это уже немного волшебство получается :)

[Sgr_A]

hloya_ram, что-то у меня с сознанием произошло, никак "не въеду" :D
А что вы с формой хотите делать в этой обработке?

[hloya_ram]

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

[Sgr_A]

hloya_ram, видимо не могу до конца понять "вашу боль" из-за пробелов в знаниях ООП.

И при каждом вызове того или иного метода передавать значение текущей формы, группы элементов, имени реквизита и т.п. в качестве аргументов функции в общем модуле -- это делает год чрезмерно замусоренным

Тут смотря что для вас является "замусоренным" ))
Хотя, когда в типовом решении видишь какой-нибудь блок, который отвечает за перерисовку формы - хочется биться головой об стену.

[Sgr_A]

hloya_ram,

С другой стороны, вспоминаются классы в иных языках (как минимум, возможность хранения состояния в LocalStorage, что касается JavaScript).

Правильно ли понимаю, вы хотите сохранить крайний вид формы? Чтобы при открытии в следующий раз вам программно не приходилось её восстанавливать?

Answer 1

[stictt]

Вашу боль, которая вас с подвигла на поиск ответа этого вопроса, мне понятна и даже близка. Но 1С не может в ООП, и основной стиль написания кода, процедурный. Смешивать стили обычно табу, ибо неизбежно получишь наихудшие моменты обоих стилей. Если вам все равно на производительность, и вот прям очень хочется. Можете взять такой концепт. 1С может использовать внешние обрабработки, для использования кода, не обязательно хранить обработку в конфиграции, от сюда не будет загромождения функций, и мы можем обособлено использовать функционал их в коде как классы, буквально импортируя каждый функционал. Так же как и классы мы будем создавать экземпляры классов(обработок), есть буквально 1 минус, это е* кое кол потерь ресурсов при достаточной сложности кода и количества этих классов, а еще и потанциальная утечка памяти.

Answer 2

[Дмитрий Кинаш]

Подскажите, насколько этот путь, по вашему мнению, является мертвым?

Пишите как вам удобно.

Мы больше 10 лет назад решали похожую задачу на обычных формах, но с общими модулями и хранением настроек в справочниках, а состояния форм различных объектов записывали в регистр сведений. В те дни нужно было каждую форму модифицировать вызовами общих модулей при открытии и закрытии. Сейчас на управляемых формах все стало намного легче - вплоть до создания глобальной подписки на получение формы.

Answer 3

[Константин]

Перечитал несколько раз, ничего непонял(
Толи проблема с вызовом Процедуры/Функции что написана обработке.
Так примерами изобилует последние типовые конфы.

Comments

[stictt]

Человек говорить про ООП, это то чего нет в 1С

[Константин]

Ааа,
У чтож у каждой среды разработки (языка) есть свои ограничения/преимущества