Сколько существует платформа 1С8, столько у разработчиков было пожелание добавить туда ООП. И каждое обсуждение таких просьб было поводом для холиваров, в которых правы были одновременно все стороны. Действительно ООП для 1С-программирования не хватает, и действительно чистое ООП в 1С не нужно, и действительно частично ООП в 1С даже есть.

Лично я был в лагере "ничего добавлять не надо" пока не попробовал строгое типизирование в 1С:ЕДТ. К тому моменту я уже знал TypeScript (типизирование в JavaScript) и решение из 1С:ЕДТ на базе комментариев на контрасте сразу выглядело ужасно. А когда стал применять, то от реализации ужаснулся еще сильнее...

Пример. Нельзя просто взять и использовать поля в выборке из запроса - получи одновременно ошибки несуществующего свойства и несоответствия типов, которые нужно или подавлять или при присвоении выборки в переменную сделать комментарий с отсылкой на конструктор-функцию, в комментариях которой описать поля твоего запроса и их типы (главное не забывать потом обновлять это описания при смене запроса). Это все? - Нет, теперь варнинги, что функция-конструктор нигде не применяется. Хочешь описать тип для входящего параметра в другом модуле? - Уже нужно ставить признак экспорта для неиспользуемой пустышки 🤯

Как не крути, весь код будет усеян или подавлением проверок, или знаками предупреждений. Многие варианты (получении значений из соответствия по явному ключу или по ключу из переменной) текущая типизация просто не умеет ни описывать (как типы ключей и значений), ни хотя бы аккуратно пропускать. Из-за отключений череды ложных срабатываний высок риск, что контроль типов не увидит реальную ошибку.

К чему я вспомнил ООП? А к тому, что нормального синтаксического контроля не хватает возможности описывать свои классы/интерфейсы. Есть определяемые типы, но это маленький огрызок от потребности - просто комбинация ссылочных и примитивных типов, когда нужны более сложные структуры. Нужно единое описание заказов для множества коннекторов с различными CRM, единое описание чека для управления драйверами разных фискальных принтерах, единое описание файла для различных хранилищ... Сейчас в типовых библиотеках такие описания эмулируются или через упомянутые функции-конструкторы, или вообще не описаны (используются по факту), или применяют смесь подходов - как в БИД, где одни типы в нескольких имплементациях, а других вообще нет.

Возможность описать собственные типы сильно уменьшило бы размер дублирования кода, уменьшило бы риски ошибок по невнимательности или из-за сайд-эффектов, а так же позволило бы сделать нормальное проверяемое типизирование! А если уже делать модуль для программного формирования структуры нового типа, то почему бы сразу не реализовать методы, которые бы жили только в рамках модулей менеджеров этого типа?

Вот и готово полноценное ООП с Инкапсуляцией, Абстракцией, Наследованием и Полиморфизмом!

При чем новые типы не ломают логику платформы и не требует кардинальных переработок - это просто синтаксический сахар. При компиляции в оп-коды все упоминания новых типов можно сразу заменить на их реализацию:

▫️ вместо Новый Ордер() условно подставить Новый Структура("Номер, Дата")
▫️ вместо МойОрдер.ПроверитьЗаполнение() подставить Тип_Ордер_Модуль.ПроверитьЗаполнение(МойОрдер), где внутри заменить работу с локальным контекстом на входящую переменную

Элементарно же!

#1С #пятница