We consider 1C programming as the work with objects and classes.
The first thing that amazed me when learning 1С is the lack of object-oriented programming. No descriptions of classes, inheritance, private methods. But any code should be logically structured. And the classes are the tools that will allow doing that with the lowest nerves.
Then, after working with 1С, I understood that the objects of course exist.

They are predefined (like «Documents», «Information registers»), while others depend on the imagination of programmer («Data processors»). Of course, there is no polymorphism, inheritance, but it is possible to build an object model.

But another problem: most 1С programmers write everything in the «procedural style». The language by itself incites to create the general module. Then put in this module a bunch of procedures for data processing and support this «spaghetti» from the procedure call.

The similar problem occurs in Delphi. There the programmer may also know nothing about OOP and write the applications. No division into classes, the whole code was often placed in the form module. But the plus of Delphi is that all comes with experience, because the object model is promoted in the books.

Consider 1С in the object-oriented approach. Predefined objects (Document, Register,..) contain the code of 3 types:

• «Object module» - The code is responsible for the certain object instance, or rather the data processing of this object.
• «Form module» - The code is responsible to process the user actions.
• «Manager module» - The code is responsible for the operations with predefined object type, without reference to a particular instance. In general languages it is called «static methods»

All procedures and functions in these modules can be interpreted as the class methods. The visibility of these procedures and functions is regulated by the key word «Export» (hello, encapsulation). However, the attributes cannot be private, but this is solved by creation of global variables in the module.

And the existence of «Form module» is a feature of 1С at all which can be proud of. This module allows separating the code responsible to process the user actions from the code which processes the data.

The only problem is that most developers «put» in the form module the coda responsible for the general logic to work with data that is not entirely correct.

Now, about the objects created by the programmer. I have seen various articles on emulation of object-oriented model. But you must admit that the manipulation with structures to store data is a dreary and not intuitive work. I believe that the best solution is to interpret the «processors» as description of your own classes.

An illustrative example. In «ValueList» I do not like a dialog called by the method «CheckItems». There are not enough buttons that check (or uncheck) all the points. And the processor ValueListDP just gives such dialog. Add the processor to the designer and then call:

ValueListDP = DataProcessors.ValueListDP.Create();
ValueListDP.Add("Example1");
ValueListDP.Add("Example2");
If ValueListDP.CheckItems() Then
    ValueListDP.Data.CheckItems();
EndIf;

Unfortunately, there is no inheritance in 1С. So, the methods and properties that are in ValueList must be either duplicated or access an attribute which stores the initial value list (in my case, this is ValueListDP.Data).

Now proceed to the designer. Find the processor ValueListDP and, calling for it the context menu, go to the «manager module». Add the following function.

Function CheckItems(Title=Undefined, OperatingData) Export

    Result = False;

    FormE = GetForm("FormCheckItems");
    FormE.ReadData(OperatingData);
    FormE.ReadDataWhenOpening = False;
    If Title  Undefined Then
        FormE.Title = Title;
    EndIf;

    ResultForm = FormE.DoModal();
    Result = (ResultForm = DialogReturnCode.OK);
    Return Result;

EndFunction

Now we may call the dialog much easier.

VLData = New ValueList;
VLData.Add("Example1");
VLData.Add("Example2");
DataProcessors.ValueListDP.CheckItems("Title", VLData);

Is it not a static class?
there are several drawbacks in the approach to use the processor as the classes.

• No inheritance. I want to be able to specify like the parent at least the simplest types (ValueList, ValueTable, Date, String…)
• Class-processor is shown in the general list of processors. I would like to have an individual object type.

That is all for now. I hope, this article allowed you to see in 1С the first stages of OOP 🙂