What is the best way to create a factory object (processing, not xdto) with state persistence between calls?

Question

1C

Good afternoon.
I really wanted to get away from working with a common module, in the procedures of which with each call it will be necessary to pass some parameters (often the same ones).
Wrote code in the Processing object module. Processing works like a factory ; well, or trying to be one :)
The essence of this factory is to modify the form of any other object (in my case, it is a DirectoryObject), from which the factory is called. For example, create or delete elements, change color, etc.
The main problem for me is saving the state of the factory object between button presses.
At the current moment, the state (an instance of the created processing object) is written totemporary storage (at the very beginning, in the procedure Initialization (Structure of Parameters) ) and from there I take it every time.

Tell me, how much this path, in your opinion, is dead ?
I would like to know if anyone has done this kind of "obscurantism". Please share your experience or some links.

Answer 1

Your pain, which prompted you to search for an answer to this question, is understandable and even close to me. But 1C cannot in OOP, and the main style of writing code is procedural. Mixing styles is usually taboo, as you will inevitably end up with the worst parts of both styles. If you don't care about performance, and you really really want to. You can take this concept. 1C can use external processing, to use the code, it is not necessary to store the processing in the configuration, from here there will be no clutter of functions, and we can separately use their functionality in the code as classes, literally importing each functionality. Just like classes, we will create instances of classes (processing), there is literally 1 minus, this is some amount of resource loss with sufficient code complexity and the number of these classes, and also a potential memory leak.

Answer 2

Tell me, how dead is this path, in your opinion?

Write at your convenience.
More than 10 years ago, we solved a similar problem on ordinary forms, but with common modules and storing settings in directories, and the states of the forms of various objects were recorded in the information register. In those days, each form had to be modified by calling common modules on opening and closing. Now on managed forms, everything has become much easier - up to creating a global subscription to receive the form.

Answer 3

I re-read it several times, I didn’t understand anything (
Toly, there is a problem with calling the Procedure / Function that is written to the processing.
So the last typical confs abound with examples.