Зачем дублируются процедуры и функции по разным модулям
По теме из базы знаний
- Мой адрес не дом и не улица… Размышления об адресном классификаторе
- Создаем свою библиотеку для OneScript
- Как управлять качеством кода 1С, используя платформу SonarQube
- Описание почти всех событий технологического журнала
- Подсистема прав доступа (анализ ролей, отладка RLS, английский код, обычные и управляемые формы)
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
В 1С нет ООП, поэтому приходится "эмулировать" подход с наследованием, полиморфизмом (неактуально, ибо типизация в 1С не жесткая и объект всегда вызывает свои методы) и инкапсуляцией (экспортные и "приватные" функции и процедуры).
Но обычному 1С-негу - да, это неудобно. Ну так обычный 1С-нег и не разрабатывает конфигурации, а просто дорабатывает их. При разработке подобный подход позволяет решать множество проблем, при доработке - да, для низкоквалифицированного персонала, плохо знакомого с продуктовой разработкой и при отсутствии у него документации по программному коду, поддержка некоторым образом усложняется.
По крайней мере в ЕРП и прочих конфигурациях на последних версиях базовых библиотек от 1С, которые понемножку адаптируются под такой подход в разработке, общих модулей плодится очень много. В итоге много похожего кода, разбросанного по конфигурации и множество таких вот обращений к "предкам" объектов.
В чём смысл таких цепочек?
Попытка следовать некоторым стандартам разработки, где общий модуль - это один "объект". Если нужно вызвать заимствованный метод (наследование), то вызывается "базовый" "объект" - другой модуль, из которого через наследование вызывается "еще более" "базовый" "объект".
В 1С нет ООП, поэтому приходится "эмулировать" подход с наследованием, полиморфизмом (неактуально, ибо типизация в 1С не жесткая и объект всегда вызывает свои методы) и инкапсуляцией (экспортные и "приватные" функции и процедуры).
Но обычному 1С-негу - да, это неудобно. Ну так обычный 1С-нег и не разрабатывает конфигурации, а просто дорабатывает их. При разработке подобный подход позволяет решать множество проблем, при доработке - да, для низкоквалифицированного персонала, плохо знакомого с продуктовой разработкой и при отсутствии у него документации по программному коду, поддержка некоторым образом усложняется.
По крайней мере в ЕРП и прочих конфигурациях на последних версиях базовых библиотек от 1С, которые понемножку адаптируются под такой подход в разработке, общих модулей плодится очень много. В итоге много похожего кода, разбросанного по конфигурации и множество таких вот обращений к "предкам" объектов.
Я думаю, что это последствия разрастания подсистем. Сначала был просто модуль КадровыйУчет. Когда он разросся до 10000 строк, решили из него выделить модуль КадровыйУчетВнутренний. Потом решили разделить его функции по модулям КадровыйУчетБазовый и КадровыйУчетРасширенный. Чтобы не лазить по всей конфигурации и не переделывать вызовы, оставляли заглушку.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот