1C, ООП, DDD и дальше

Сегодня я хочу пригласить вас немного помечтать. А то что это мы все за код да за код. Давайте о жизни. Ну и о коде, конечно, тоже. Потому что какая жизнь у программиста без кода?

Вот недавно я прочел (если честно, еще дочитываю) очень увлекательную книжку с умным названием «Приемы объектно-ориентированного проектирования» за авторством знаменитой «Gang of Four«. В книге идет речь о шаблонах проектирования. Кстати, рекомендую от всей души, если кто еще не читал. Сложно представить себе, что ООП можно изучать без таких простых и наглядных примеров использования, какие приводятся в этой книге. Честное слово, я бы ввел ее в школьную программу, может, и не в школьную, но в университетскую точно. А пытливому уму везде найдется польза и применение. Хоть 1С и не поддерживает ООП в полной мере, но и нашему брату, 1С-нику, крупицу истины из нее почерпнуть не грех.

А теперь давайте про 1С и ООП. Когда-то (до 19 октября 2005) Википедия про язык 1С утверждала, что:

Данный язык является интерпретируемым объектно-ориентированным языком высокого уровня.

(На самом деле это, конечно же, не так, но об этом позже.)
И добавляла, что:

Платформой предоставляется фиксированный набор базовых классов, на основании которых можно создавать любое количество порожденных классов, наследующих их свойства и методы. Разработчик имеет возможность определять собственные дополнительные процедуры и функции, а также свойства порожденных классов (с некоторыми ограничениями). Допускается только одна ступень наследования классов. Не допускается переопределение процедур, описанных в базовых классах.

Если кто не понял, поясню: есть класс «Документы», от него можно создавать дочерние классы, вроде «Приходная накладная» или «Закрытие месяца», эти классы в свою очередь позволяют создавать конкретные экземпляры классов (объекты) — конкретные документы (ага, с номером и датой), которыми и управляет пользователь в режиме «Предприятие».
Не вполне ООП, но достаточно близко. Тут и один уровень наследования классов и разница между классом и экземпляром. Ну а про статические методы я уже недавно писал. Как говорили древние, «для умного достаточно», но недостаточно для программиста, у которого душа просится в полет, а руки тянутся к клавиатуре. Голова в этом всем никак не участвует, поэтому продолжаем мечтать.

А вот если бы!.. А вот если бы 1С была как Axapta или C++, например. Уж там-то наверняка полноценно поддерживается ООП, можно и шаблонов навертеть, объектную модель отгрохать — закачаешься. Только вот беда, у C++ порог вхождения выше. С 1С все просто: открыл конфигуратор — и ты уж программист. Сначала форму печатную поправил, потом расчет суммы подкорректировал, и пошло-поехало (ботинками не кидайтесь, пожалуйста, сам так начинал и еще кучу народа знаю такого же). А открой проект на C++ (сиплю-сиплю, а ничего не выходит) — чего-то не там переставил, и все — не компилируется в лучшем случае. Сложно и дорого. Потому-то 1С так мил сердцу мелкого бизнесмена, что не нужны заоблачные бюджеты на разработку, да и типовых конфигураций пруд пруди. Ну и нам, 1С-никам, заодно тепло и сухо. Но объектов хочется.

И вот недавно сама 1С подкинула интересную мысль. Помните релиз 8.2.14? Там, где общие реквизиты вернули. Так вот, что такое общие реквизиты с точки зрения ООП? Не что иное, как обычные свойства класса «Документы». Класс документы-то всеми подклассами наследуется, и свойства, стало быть, тоже. А что если разрешить не один уровень наследования от документов, а несколько? Вот это было бы здорово. Захожу я в конфигуратор (1Сv9, конечно же!), добавляю в документы группу «Товарные документы». Сразу в эту группу документов реквизиты добавляю, типа «Контрагент», «Отпустил», «Принял» и ТЧ «Товары» с такими реквизитами — «Номенклатура», «Количество», «Цена». И тут же в модуле группы документов пишу код, что, мол, если количество поменялось — сумму пересчитать, если сумма — цену. Ну, вы все эти процедуры обработки реквизитов и сами по сто раз писали, чего я рассказываю. А потом уже в группе документов «Товарные документы» создаю «Приходную накладную», «Расходную накладную», ну и все, что положено. И у них все эти реквизиты и ТЧ уже есть — унаследовались от товарных документов. Просто волшебство и сплошной «ахалай-махалай» получается. Конечно, кое-где добавляю особенностей для каждого класса, реквизитов специфичных, но каркас работает общий. Удобно, черт возьми. Надо разрядность цены в товарных документах поменять — р-р-р-раз! — и поменял одним махом. Реквизит-то один. И код по обработке один. Так, по мелочи, потом пройтись останется. Ну, естественно, кроме группы «Товарные документы» делаю группу «Кассовые документы» из общего корня — «Документы». Там свои особенности, но общего тоже много. И так далее, и так далее.
Про то, что похожие фокусы со справочниками и другими объектами работают, говорить не буду: сами спокойно дофантазируете, если хотите.
Тут же, кстати, и общие модули немного разгрузятся. Есть модуль группы документов, там и обработки для этой группы документов можно разместить. Например, всякие поиски цен, обработки подборов и прочее. Оно ж все, по логике, к товарным документам относится, верно ведь? Вот пусть в модуле группы «Товарные документы» и лежит, чтобы долго не искать.
И подсистемы тоже как-то оборачиваются в новом свете. Теперь те же документы объединяются в группы с иерархией намного лучше, чем это делали подсистемы. Вот есть группа «Кассовые документы», и все, что относится к кассе, находится в ней. И это обоснованно с точки зрения наследования и структуры кода. Хотя с отношением к нескольким подсистемам проблема получается, но, наверное, и тут какое-то решение есть.
Конечно, это еще не полноценное ООП, но хороший шаг вперед. Или назад?

Давайте посмотрим, что Википедия сейчас пишет про 1С:

Данный язык является предварительно компилируемым предметно-ориентированным языком высокого уровня.

Ключевое слово тут «икра» предметно-ориентированным. На самом деле это очень важно. Именно предметно-ориентированность позволяет быть языку 1С «заумью с человеческим лицом». Когда такие понятия, как «документ» или «проводка», встроены в само ядро платформы, то всякие надуманные абстракции вроде классов и подклассов тихо бледнеют и не отсвечивают. В нормальных «больших» языках программирования тоже хотят так уметь. Даже целое направление придумали — DDD (русская Википедия, извините, об этом еще не в курсе). Так не испортим ли мы 1С, если начнем туда тянуть все эти наследования? Не знаю. Если бы я был разработчиком платформы (во куда хватил! но мы ж тут помечтать договорились, да?), я бы по-тихому все-таки протащил бы такую доменную сущность, как группы документов, не особо афишируя, что оно все торчит из ООП. В принципе, в рамках доменной модели (не путать с объектной) понятие «группа документов» вполне интуитивно понятно, ценно и достаточно функционально. Так что катастрофы тут не предвидится. Катастрофа предвидится, когда мы заговорим о множественном наследовании, но тут могу заметить, что это:

…концепция, поддерживаемая частью объектно-ориентированных языков программирования…

Частью! Так что нам тут бояться нечего, тут еще сами апологеты ООП до конца не определились.
Ну а не хочется вам с этими новомодными «группами документов» разбираться да все конфигурации переписывать — пожалуйста. Не наследуйте от групп, наследуйте от «Документы». И для вас как будто и ничего не поменялось. Вот вам, кстати, обратная совместимость.
Да… Много еще чего можно хорошего намечтать…

Оставляю вас за этим занятием и хочу пожелать вам хорошего дня и хорошего кода.

P.S.: Сильно не ругайте, если кто чем недоволен, о грубых ляпах пишите — буду исправляться.

Оригинал статьи в блоге автора