В колонках играет - Чиж.ДомойХотим мы того или нет, но эволюция не стоит на месте и к тому же, движется в одном направлении.
Если весь западный мир уже перешел на ООП, а 1С упорно не хочет замечать этого факта, то это еще не значит, что она открыла свой новый путь.
Рано или поздно это случится, 1С посыпет свою голову пеплом и перейдет на ООП.
Рассмотрим факты, которые говорят нам о неуклонном движении 1С к ООП. Для этого будем изучать классических представителей вида 1С - типовые конфигурации и стиль программирования в них.
В первых типовых конфигурациях 77 все было завязано на документ. Большинство кода находилось в документе. Конфигурации были простыми и такой подход был возможен.
При дальнейшем увеличении сложности повторяющиеся куски кода для различных документов выносились в одну функцию.
Однако у каждого документа были свои особенности и в таких функциях часто эти особенности определялись по виду документа - для приходной накладной один способ, для расходной - другой.
Помню, однажды мне нужно было добавить один документ, который делал бы такие же движения, как расходная накладаная, мне пришлось найти все места, где встречается проверка вида на расходную накладную и добавить туда:
Вид="РасходнаяНакладная" ИЛИ Вид="МояНакладная"
Вскоре однако прогресс дошел до того, что анализ опирался не на вид документа, а на характер документа, потому что, например, оплата покупателю могла осуществляться как расходным кассовым ордером, так и выпиской, так и корректировкой долга. Проще было передавать в процедуру характер документа, а не строить всю процедуру проведения исходя из вида документа.
Теперь можно было использовать типовые функции уже не для проведения целого документа, а для совершения отдельных движений по отдельным регистрам учета, например по взаиморасчетам.
Надо однако заметить, что такие модули практически никогда не документированы и не всегда изолированы, под этим я понимаю то, что сложно вызвать такую процедуру из другого места, где нам нужно совершить такое движение, потому что часто используются какие-либо глобальные переменные или неявные условия и т.п.
Параллельно с кастомизацией модулей проведения произошла еще одна эволюция - от переменных к структурам. Если раньше ситуация описывалась набором переменных Склад, Товар, Фирма и было все окей, то теперь ситуация порой описывается десятками различных переменных и передавать их от процедуры к процедуре стало накладным. Так практически во всех серьезных модулях для передачи данных между процедурами используются структуры и таблицы значений - уже почти объекты.
Очень медленно, но верно идет процесс абстракционирования кода. Адепты быстродействия еще сильны - они твердят, что программы написанные на ассемблере - самые быстрые. Поэтому порой ради скорости теряется прозрачность кода, но это временное явление. Для примера приведу сравнение, что Java в десятки раз медленнее ассемблера, но сложные приложения почему-то не пишутся на ассемблере. Таким образом от оптимизации по скорости 1С медленно кочует к оптимизации по пониманию кода. Это в частности выражается в том, что между процедурами уже передаются не специфические данные типа результата запросов или выборки из бух итогов, а более простые и предсказуемые структуры типа таблиц значений.
Процесс эволюции обусловлен не желанием 1С усовершенствовать свой код, а скорее невозможностью продолжать дальнейшее развитие без универсализации и упрощения структур, участвующих в программировании. Стиль, который мог себе позволить один программист, поддерживающий всю конфигурацию, уже не позволителен для конфигураций типа УПП, где ни один человек не может целиком охватить пониманием весь массив кода.
Таким образом, 1С потихоньку усовершенствует свои подходы к программированию и когда она встанет перед лицом того факта, что не успевает писать и тестировать код, где каждый программист пишет, как бог на душу положит, она внедрит стандарты и добавит таки ООП к своему языку программирования.
Видимо это произойдет тогда, когда проекты на 1С будут ограничены по сложности не мощностью железа, а своей структурой кода. Тогда 1С опять сделает шаг в сторону и внедрит ООП или какой-нибудь другой вариант универсализации кода из доступных на наше время.
