Принципы SOLID для 1С: Путь к чистому коду. Часть 1

12.05.25

Разработка - Рефакторинг и качество кода

+48 –
Разбираем принципы SOLID в контексте 1С: как укротить хаос в коде, сделать его гибким, расширяемым и предсказуемым. Практические примеры, механизмы платформы помогающие в этом и шаги к чистой разработке для новичков и профи.

Предисловие

Стоит завести разговор о SOLID среди 1С разработчиков, как в ответ, либо недоуменные взгляды, либо попытки найти хоть что-то в интернете, после которых вопросов становится только больше. Сегодня эти слова всe чаще звучат на собеседованиях, мелькают в требованиях компаний и в поисковых строках разработчиков. Материалов, которые бы ясно объясняли, как эти принципы работают в нашей платформе, почти нет. В лучшем случае попадаются общие материалы про объектно-ориентированное программирование, не учитывающие специфику платформы. В худшем, разрозненные публикации, оставляющие больше вопросов, чем ответов.

Интерес к этим принципам растeт, и не зря. Наверное, каждый сталкивался с кодом, который превратился в хаос. Методы, переплетeнные, как клубок, где правка одной строки, вызывает ошибку в другом модуль, влечет за собой часы отладки, и исправлений. Был похожий опыт? Или хоть раз приходили мысли: "Всe, пора искать новую работу, этот код меня доконает"?

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

Эта статья для опытных разработчиков, которые ищут способ укротить сложные проекты и сделать их гибкими. Для новичков, стремящихся с самого начала заложить крепкую основу. Для тех, кто хочет углубиться и понять, какие принципы помогают сложным конфигурациям оставаться устойчивыми и масштабируемыми. Для всех нас, кто не любит заплатки в коде в духе "и так сойдет", и хочет понять, как принципы SOLID могут в этом помочь. Мы разберем каждый принцип SOLID на примерах 1С разработки, которые вы сможете взять за основу для своих задач. 

Это про наше общее желание сделать код чище, а работу эффективнее и приятнее. И если после этих страниц у вас появится ощущение или даже легкий азарт, что SOLID не просто модное слово, а реально полезный инструмент на пути к порядку, значит, всe было не зря.

Возможно, целиком и сразу, объем информации покажется большим, для тех, кто впервые знакомится с ней. Для удобства я разделил каждый принцип на независимые блоки, которые можно читать отдельно друг от друга. Начнём.

 

Что такое SOLID

SOLID - это пять принципов объектно-ориентированного программирования, которые помогают создавать код, способный расти, меняться и оставаться понятным.

Вместе эти правила формируют подход, где структура программы становится не просто набором строк, а продуманной системой.

Зачем это нужно? Программирование, это не только написание кода, но и его развитие. Без чeтких принципов даже простая задача может превратиться в головоломку, когда требования меняются, а сроки поджимают. SOLID помогает решить эту проблему, давая инструкции для написания кода, который легко поддерживать, расширять и передавать другим. Это не абстрактная теория, а практическая основа, которая помогает избежать путаницы и сделать разработку предсказуемой.

 

Немного о контрактах

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

Контракт - это формальное описание ожидаемого поведения метода, задающее его интерфейс и определяющее, как он взаимодействует с вызывающим кодом. Это позволяет использовать метод, опираясь на гарантированный результат, не зная его внутренней реализации.

Например, в приведенном примере метод ПодготовитьТекстЖурналаРегистрации находится в области ПрограммныйИнтерфейс и имеет четко описанную сигнатуру. Это задает контракт.

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

Методы в таких областях, как ПрограммныйИнтерфейс, СлужебныйПрограммныйИнтерфейс задают публичные контракты для других подсистем. Размещение методов в этих областях обязывает разработчиков не вносить в них изменения, которые приведут к изменению условий контракта, например добавление нового обязательного параметра. Лучше добавлять необязательные параметры, либо создавать новые методы, перенося старые в область УстаревшиеПроцедурыИФункции. При этом, если вы используете SonarQube или EDT, использование устаревших методов будет анализироваться.

Пример заданного контракта:

#Область ПрограммныйИнтерфейс

// Получает события журнала регистрации по отбору, выполняет проверку получения и передает результат
// в виде текста.
//
// Параметры:
//  ПараметрыОтбора - Структура - структура с ключами:
//   * ДатаНачала    - Дата - начало периода журнала;
//   * ДатаОкончания - Дата - конец периода журнала;
//   * Событие       - Массив - массив событий;
//   * Метаданные    - Массив, Неопределено - массив метаданных для отбора;
//   * Уровень       - УровеньЖурналаРегистрации - уровень важности событий журнала регистрации;
//  ДанныеВложений - Массив Из Структура - подготовленные данные вложений:
//   *Представление - Строка - представление вложения;
//   *Текст - Строка - текст файла вложения;
//   *Размер - Число - размер файла вложения в байтах.
//
// Возвращаемое значение:
//  Структура - результат подготовки:
//    *КодОшибки - Строка - идентификатор ошибки при отправки:
//    *СообщениеОбОшибке - Строка, ФорматированнаяСтрока - сообщение об ошибке для пользователя.
//
Функция ПодготовитьТекстЖурналаРегистрации(ПараметрыОтбора, ДанныеВложений) Экспорт
	
	// Логика метода, обеспечивающая исполнение контракта.
	
КонецФункции

#КонецОбласти

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

Теперь, вернемся к SOLID, начнeм с первого принципа и посмотрим, как одна простая мысль меняет всe.

 
 S (Принцип единственной ответственности / Single Responsibility Principle / SRP)
 
 O (Принцип открытости/закрытости / Open/Closed Principle / OCP)
 
 L (Принцип подстановки Барбары Лисков / Liskov Substitution Principle / LSP)
 
 I (Принцип разделения интерфейсов / Interface Segregation Principle / ISP)
 
 D (Принцип инверсии зависимостей / Dependency Inversion Principle / DIP)

 

Как применять на практике

Весь этот материал, не просто теория, а руководство к действию, которое может изменить ваш взгляд на код. Начав мыслить принципами SOLID, вы увидите код по-новому, вместо набора методов, он превратится в систему взаимосвязанных компонентов, где каждая часть играет свою роль. Это, как переключиться с хаотичного "пишу как получится" на структурированное "проектирую с целью". Используйте материал как чек-лист при проектировании.

   S: Анализируйте задачи с точки зрения ответственности, одна программная сущность - одна цель.

   O: Проектируйте код с возможностью добавления функциональности через точки расширения.

   L: Проверяйте, чтобы подмена базовой логики не нарушала контракт.

   I: Упрощайте интерфейсы, убирая из них всe лишнее для конкретного клиента.

   D: Внедряйте абстракции, чтобы разорвать жeсткие связи между "высокоуровневой" логикой и "низкоуровневыми" деталями реализации.

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

 

Послесловие

Мы начинали с вопроса "что это такое?" и применимы ли эти принципы к нашей платформе. Теперь, разобрав каждый из них, от разделения ответственности до инверсии зависимостей на примерах из 1С, я надеюсь, показал, что SOLID не только применим в разработке 1С, но и может стать отличным ориентиром на пути к порядку в коде, для всех нас. Если после этой статьи у вас загорелись глаза применить эти принципы в своих проектах, значит, мы вместе сделали шаг к порядку, чистому коду. Спасибо, что прошли этот путь со мной, надеюсь, материал вдохновил вас!

 

Автор: Григорьев Руслан

 

SOLID 1С принципы SOLID разработка 1С чистый код архитектура кода единственная ответственность открытость закрытость подстановка Лисков разделение интерфейсов инверсия зависимостей типовые конфигурации гибкий код устойчивость кода проектирование кода тестирование кода гибкость системы хаос кода рефакторинг 1С примеры SOLID

+48 –

См. также

Загрузка, редактирование и сохранение в PDF стандартов 1С

Рефакторинг и качество кода Программист Платформа 1С v8.3 Абонемент ($m)

Конфигурация для хранения стандартов и сохранения их в формате PDF.

2 стартмани

05.05.2025    2054    comptr    4    

13
Собеседование, интервью, отбор кандидата-программиста

Рефакторинг и качество кода Платформа 1С v8.3 Абонемент ($m)

Методический материал для собеседования. Помогает облегчить общение между кандидатом и работодателем.

5 стартмани

05.05.2025    1669    vasilev2015    50    

18
Cursor IDE для 1С. Кодревью и рефакторинг с помощью AI

Рефакторинг и качество кода Программист Платформа 1С v8.3 Россия Бесплатно (free)

Цель статьи: кратко показать инструмент и возможности Cursor IDE.

21.04.2025    8438    dimzfresh    33    

37

Рефакторинг и качество кода Обновление 1С Программист Платформа 1С v8.3 Бесплатно (free)

Методика, описанная в статье, выработана при переезде с 1С:ДО 2.1 на 1С:ДО 3.0. Может также применяться при переходе с 1С:УПП на 1C:ERP, 1C:ERP на 1C:ERP УХ и т. п. Учтены все необходимые доработки при переезде на новую конфигурацию и предупреждены возможные ошибки.

21.04.2025    1227    PROSTO-1C    4    

4
Аналог синхронного вызова диалога "Вопрос" для рефакторинга кода из ранних версий 1С

Рефакторинг и качество кода Программист Платформа 1С v8.3 Россия Бесплатно (free)

Диалог "Вопрос" использовался очень интенсивно в старых версиях кода и также его используют в УФ довольно часто. Иногда очень неудобно использовать рефакторинг через асинхронные вызовы ПоказатьВопрос и ВопросАсинх по разным причинам. Есть ещё одно решение, как избежать больших переделок кода, когда Вы не планируете его использовать где-то на других платформах и Веб-клиентах.

26.03.2025    934    ksuman    7    

3
Автоматизация сбора данных по проблемам производительности 1С для проведения диагностики в одном окне

HighLoad оптимизация Рефакторинг и качество кода Технологический журнал Программист Платформа 1С v8.3 Россия Бесплатно (free)

Технологии бегут вперёд, но боль производительности 1С остаётся вечной: инфраструктура, код или настройки? Пока ИИ не научился чинить всё «на лету», мы автоматизировали ключевое — диагностику. Читайте статью — показываем, как превратить хаос диагностики в понятные графики и цифры. Спойлер: это работает даже если ваша 1С — «чёрный ящик» на старом железе.

19.03.2025    3638    EFSOL_oblako    9    

9
Различные ошибки при разработке в предприятии

Рефакторинг и качество кода Программист Стажер Платформа 1С v8.3 Бесплатно (free)

В процессе обучения студенты бывает, что по невнимательности или торопливости допускают кучу ошибок. Далеко не у всех  преподавателей есть на это время, но новички допускают поначалу прилично  много ошибок и как всегда идет "крик души" в общем чате обучения. Поэтому я решила  немного рассказать и показать в надежде, что данная статья кому-нибудь  "облегчит страдания" студента.

17.03.2025    3036    Bukaska    5    

8
Код-ревью с помощью ИИ. Текущие возможности и тренды

Нейросети Рефакторинг и качество кода Тестирование QA Программист Платформа 1С v8.3 Бесплатно (free)

Искусственный интеллект в код-ревью – это не фантастика, а реальность, которая уже сегодня помогает разработчикам улучшать свои проекты. Расскажем о том, как ИИ может автоматически находить баги и предлагать улучшения, экономя ваше время и ресурсы.

11.03.2025    6515    mrXoxot    53    

55
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. VAAngelov 545 21.04.25 12:34 Сейчас в теме
Отличная статья! Спасибо за проделанный труд.
rozer; NorraSaltolinen; ivnik; user1948830; RPGrigorev; +5 – Ответить
2. RPGrigorev 783 21.04.25 12:46 Сейчас в теме
(1) Спасибо за помощь и поддержку!
ivnik; VAAngelov; +2 – Ответить
3. brr 184 21.04.25 16:35 Сейчас в теме
Наличие ОМ ОбщегоНазначения зачеркивает букву S в SOLID.
+ – Ответить
4. brr 184 21.04.25 16:42 Сейчас в теме
С L забавно получилось, выдавать костыль за реализацию принципа это сильно.
Должно быть вот так: 

Функция ПодбиратьВидыЗапасовПоИнтеркампани(Документ) Экспорт
	
	Результат = Документ.ДополнительныеСвойства.ПодбиратьВидыЗапасовПоИнтеркампани;
	
	Возврат Результат;
	
КонецФункции


То есть все документы которые попадают в эту функцию в ДополнительныеСвойства должны иметь инициализированное свойство ПодбиратьВидыЗапасовПоИнтеркампани.
+ – Ответить
9. VAAngelov 545 21.04.25 17:15 Сейчас в теме
(4) Интересно. А можно вас попросить какие-то примеры? Как неправильно и как правильно. Чтобы наглядно это было видно сразу. Просто очень хочется понять, что же тут неправильно, но я пока не понимаю. Это просьба.
RPGrigorev; +1 – Ответить
18. reset2 17 22.04.25 10:37 Сейчас в теме
(9)
1. Очевидно, что в "правильном" блоке ломается функциональность.
В "неправильном" для реализации свойство берётся из реквизита объекта, а в "правильном" из доп. свойств объекта.
Либо где-то еще должен быть код, который заполняет доп. свойство по реквизиту(ам) документа?
2. Возвращать "Ложь" если свойства нет тоже нарушает функциональность, почему возвращаем Ложь, а не Истина, или Неопределено? Если разработчик "забыл" установить это доп.свойство, то оно и должно обрабатываться как ошибка, а не закрываться костылём.

Часы же нам не возвращают время "по-умолчанию", если у них стрелка отвалилась, или они стоят.
brr; +1 – Ответить
20. RPGrigorev 783 22.04.25 13:41 Сейчас в теме
(18) (4)
1. Очевидно, что в "правильном" блоке ломается функциональность.
В "неправильном" для реализации свойство берётся из реквизита объекта, а в "правильном" из доп. свойств объекта.
Либо где-то еще должен быть код, который заполняет доп. свойство по реквизиту(ам) документа?

1. Суть в том, что метод с контрактом, принимающим на вход параметр с типом "ДокументОбъект", должен работать одинаково со всеми подтипами, поэтому особая логика для конкретного типа "выброшена" из "правильного" примера. Подразумевается однотипное поведение, а эту логику можно вынести в отдельный метод, либо контролировать транспорт значения реквизита в дополнительные свойства заранее, до вызова этого метода.

2. Возвращать "Ложь" если свойства нет тоже нарушает функциональность, почему возвращаем Ложь, а не Истина, или Неопределено? Если разработчик "забыл" установить это доп.свойство, то оно и должно обрабатываться как ошибка, а не закрываться костылём.

2. Здесь акцент не на то, что разработчик может забыть, а на контракт базового метода, который ничего не упоминает об этом свойстве, а лишь требует входящий параметр типа "ДокументОбъект", обещая вернуть значение типа "булево". Мы сохраняем контракт базового в метода в "наследуемом", поэтому возвращаем "булево".

Часы же нам не возвращают время "по-умолчанию", если у них стрелка отвалилась, или они стоят.

Интерпретация отсутствия свойства, как "ложь" - осознанный выбор в бизнес-логике, вызывающий код ожидает значение типа булево и не получает "истина". Т.е. если не истина, то однозначно не подбирать.

(18) (4) Если есть предложения, какие примеры, на ваш взгляд, лучше продемонстрируют "наследование" с сохранением ожидаемого поведения для всех подтипов - буду рад.
+ – Ответить
5. shalik 21.04.25 16:46 Сейчас в теме
Спасибо за статью. Жду комментарии от гуру1спрожженых программистов что всякие паттерны, солиды в 1с не нужны и не работают!
quazare; VAAngelov; RPGrigorev; +3 – Ответить
8. VAAngelov 545 21.04.25 17:07 Сейчас в теме
(5) Сейчас тут будет море таких комментов).
RPGrigorev; +1 – Ответить
14. quazare 3925 22.04.25 05:01 Сейчас в теме
(5) не понятно - нужны или нет, - заказчику точно не нужны… вылизовать код - это привилегия
triviumfan; +1 –2 Ответить
15. shalik 22.04.25 09:20 Сейчас в теме
(14) Заказчику в принципе до фонаря что там в коде и как написано, если решение работает)
+ – Ответить
16. quazare 3925 22.04.25 09:30 Сейчас в теме
(15) категорически согласен) но вот автор статьи считает иначе походу
+ – Ответить
19. VAAngelov 545 22.04.25 12:02 Сейчас в теме
(15) Заказчику-то может быть и пофигу. Но статья ведь не о заказчиках. Статья ведь о том, как прийти к Чистому коду ,чтобы в дальнейшем было удобно расширять, дорабатывать, чтобы другой программист, не имея контекста - мог бы разобраться и допилить новую хотелку заказчика минимальными средствами и трудозатратами. Да, реальность, пока, к сожалению, отличается от желаемого, но это ведь первые шаги, постепенно можно прийти к тому, что код повсеместно будет писаться чисто, тогда везде и дорабатывать его будет легче. Конечно, когда приезжаешь в автосервис, и тебя говорят, что эта работа стоит неделю, то конечно заказчик требует, а давай за 1 день и если мастер на это соглашается - то скорее всего да, он сделает, но как? на скотче и изоленте? и оно даже работать будет, какое-то время, но если эту итерацию повторять снова и снова - то рано или поздно случится ой-ой, и потом скажут - просто на помойку выкини свою машину. Заказчик в недоумении, как так? Ведь все делалось и работало. С докторами то же самое, ведь ни один пациент не станет сейчас спорить, что перед тем, как провести операцию - врач должен тщательно вымыть руки, но ведь были времена в истории, и это реальность, что тоже спорили пациенты - мы же теряем время на помывку рук. Так может быть надо все-таки начинать смотреть в сторону Чистого кода? И пробовать делать первые трудные, тяжелые шаги, но делать, а не просто говорить, ой да ничего это не работает в реальности. Вопросы риторические. Просто для подумать и задуматься. И конечно я понимаю, что сейчас я тоже получу свою порцию против.
IgorS; dvsidelnikov; exitel; annamol; 1cmailru; kirillkr; shalik; RPGrigorev; +8 – Ответить
6. brr 184 21.04.25 16:49 Сейчас в теме
Нет инверсии в примере D, добавьте в ДанныеУстановленнойЦены третий параметр и передавайте модуль, и не обязательно общий, можно и модуль менеджера и объект. Будет инверсия. В зависимости от переданного модуля у вас по разному будут считаться центы. Передаваемый модуль естественно должен содержать интерфейс ДанныеУстановленнойЦены.
+ – Ответить
7. brr 184 21.04.25 16:50 Сейчас в теме
В примерах ТС ненавязчиво использует паттерн Информационный эксперт. За что ему респект. :)
RPGrigorev; +1 – Ответить
10. RPGrigorev 783 21.04.25 17:31 Сейчас в теме
(7) Пожалуйста, аргументируйте и приведите "правильные" примеры.
+ – Ответить
12. brr 184 21.04.25 17:42 Сейчас в теме
(10) СкладПоУмолчанию в ММ справочника Склады. Типичное применение информационного эксперта. Ответственность за выполнение задачи должен нести класс, который обладает всей необходимой для этого информацией.
RPGrigorev; +1 – Ответить
11. ivnik 618 21.04.25 17:32 Сейчас в теме
Статья очень полезная, на простом "крестьянском" языке. Спасибо!
RPGrigorev; VAAngelov; +2 – Ответить
13. maxrubtsoff 20 21.04.25 21:00 Сейчас в теме
Только легенды знают, что это перезалив. Рад, что статья снова доступна)
rpgshnik; VAAngelov; RPGrigorev; +3 – Ответить
17. Red_Devil 181 22.04.25 10:13 Сейчас в теме
все это хорошо максимум в самописке. Когда дорабатываешь типовую там порой другие требования.
Механизм расширений от 1С например вписывается в solid? Когда их несколько десятков) Или сотни подписок на события(
+ – Ответить
21. Alxby 1129 23.04.25 08:13 Сейчас в теме
Автором проделана немалая работа, но статья оставляет странное впечатление...
SRP. В корне неверно описан принцип. Принцип ничего не говорит о том, сколько задач выполняет модуль, функция или класс. Он говорит о том, кто может повлиять на его изменение, и это должен быть один актор. Другими словами, если два заказчика попросили сделать одинаковую функцию, надо сделать две разные функции. На это особо обращает внимание Роберт Мартин. Он как раз приводит пример нарушения принципа: одна функция расчета не сверхурочных часов используется в двух разных отделах. Разумеется, в некоторых случаях, этот принцип может противоречить принципу повторного использования кода.
OCP. В целом описан верно, только расширения конфигурации не имеют отношения к принципам SOLID в коде. Да и настройки в метаданных можно отнести к ним весьма условно. Проблема с этим принципом в другом: не всегда можно заранее определить, где именно возникнет потребность изменения и заранее предусмотреть возможность расширения. Т.е. не будешь же в каждую функцию вставлять обращение к переопределяемому модулю. Таким образом неумеренное следование этому принципу может нарушить принципы KISS, YAGNI, усложнить код и затруднить его понимание и поддержку.
LSP. В 1С практически не применим. В принципе говорится об объектах базового типа и объектах подтипа, а в примере статьи используются объекты разных подтипов. Здесь уместно говорить о нарушении более общего принципа: нельзя передавать в функцию неверные параметры. Этот принцип гораздо более очевиден, чем LSP, пришедший к нам из ООП. Если уж действительно хочется продемонстрировать LSP, тогда надо создать "базовый тип" - структуру, унаследовать от него "подтип" - структуру с дополнительными полями и написать функцию, которая с первой структурой работать будет, а со второй - нет.
ISP. В том смысле, в котором он используется в ООП, в 1С не применим. В ООП требуется упрощение интерфейса, для того, чтобы класс, имплементирующий интерфейс, не реализовывал ненужные функции. Это как будто для документов без проведения пришлось бы обязательно реализовывать ОбработкаПроведения. Если же под интерфейсом понимать более общее понятие (API, UI...) то соблюдение/нарушение принципа зависит от точки зрения. В примере "Соблюдение принципа" если я захочу узнать наименование контрагента, мне одновременно с ним придет ИНН, который в данный момент мне не нужен - явное нарушение. И наоборот, если для конкретной задачи всегда вместе со свойствами контрагента надо получать его заказы, то нарушения нет.
DIP. В "плохом" примере статьи уже нет нарушения: функции зависят от абстракции - структуры с помощью которой передаются данные о цене. Если изменится способ хранения данных, то достаточно в функции нижнего уровня вернуть точно такую же структуру - и функция верхнего уровня ничего не заметит. И наоборот, если на верхнем уровне цена будет использоваться по-другому, это не потребует изменения функции верхнего уровня. Нарушением был бы возврат функции нижнего уровня записи регистра или объекта справочника. В примерах хорошо бы показать прямую зависимость, обратную зависимость и зависимость от абстракции. Сам принцип хорош ровно до того момента, пока не произойдет изменение абстракции - например изменение формата данных для интеграции.
А вообще, что такое принципы? Это не законы, это не правила, обязательные для исполнения. Принципы это ... принципы. Их много. SOLID, DRY, YAGNI, Оккама, WISIWYG, KISS, BDUF и множество безымянных. Они разные. Иногда они противоречат друг другу. Они по разному влияют на код. Применение какого-либо принципа может как "улучшить" так и "ухудшить" код. Причем это "улучшение" и "ухудшение" очень субъективно. К сожалению, в погоне за соблюдением модных принципов многие забывают о главной задаче: создании надежного ПО, удовлетворяющего потребностям человека и имеющего высокие эксплуатационные характеристики. Маркетинг побеждает инженерию.
brr; +1 – Ответить
25. booksfill 23.04.25 17:11 Сейчас в теме
(21)
Он говорит о том, кто может повлиять на его изменение, и это должен быть один актор.


Подпишусь под каждым словом.

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

Когда пытаются создать наглядный пример, почему-то стараются запихать как можно больше ежей с ужами,
после чего их "успешно" разводят. На практике это обычно выглядит "слегка" иначе.

P.S.
Никто не мешает, выделить часть кода в отдельные методы, например, если эта часть может быть повторно использована (и ее изменение маловероятно) или её надо отдельно покрыть тестами. Но к SRP это отношения не имеет. Скорее уж наоборот - увеличивает зависимость от шаловливых ручек.

LSP. В 1С практически не применим.

Вот именно. Да и попытка типа: "создать "базовый тип" - структуру, унаследовать от него "подтип" - структуру с дополнительными полями и написать функцию, которая с первой структурой работать будет, а со второй - нет", по-моему, на практике все только усложнит.
Хотя сам принцип, точнее, согласен, более общий вариант, пояснит, да.

(21)
Маркетинг побеждает инженерию.

Скорее не маркетинг, а мода и хайп.
В технике - это крайне вредное явление.
Ибо одно дело носить штаны фасона "обделался и горжусь", а другое делать что-то, условно говоря, приводящее к тому, что мощность двигателя снизится на 40%, а стоимость его обслуживания вырастет на 10%, просто потому, что так написал (точнее так мы это поняли) великий N.
Для большего отрицательного эффекта желательно минимально задумываться о смысле написанного этим самым N, и не обращать внимания на великих X,Y,Z (ибо уже на модно), главное, чтобы похоже получилось.
+ – Ответить
22. NicolasCage 23.04.25 09:21 Сейчас в теме
В 1С нет ООП. Какие-то отдельные принципы применить можно. Но не все. Ведь в таком случае по большей части это натягивание совы на глобус.
+ – Ответить
23. lada2011 23.04.25 09:34 Сейчас в теме
Думаю пройдет немного времени и искусственный интеллект будет помогать программисту создавать чистый код.
Допустим создаем обработку заполнения табличной части документа из внешнего файла. Создаю первую процедуру выбора файла , делаю запрос к ИИ и он выдает оптимальный код выбора и обработки файла в зависимости от выбранного расширения. Следующая процедура - заполнение табличной части документа - запрос к ИИ и он выдает оптимальный код в котором уже предусмотрена проверка на наличие номенклатуры в справочнике номенклатуры, при отсутствии заполняет справочник номенклатуры, делает запрос в регистр цена номенклатуры и получаем готовый оптимальный код. Программисту остается только тестирование и эту задачу можно отдать ИИ.
Вижу , что ИИ заменит классы в ООП и получим совершенное ООП_ИИ.
"Каменный век закончился не потому -что камни исчезли". С развитием ИИ профессия программиста не исчезнет, разработка будет проходить быстрее т к в ИИ уже будет накоплен опыт программистов, да и задачи усложнятся.
VAAngelov; +1 – Ответить
24. kuzyara 2147 23.04.25 11:53 Сейчас в теме
Опять натягивание паттернов ООП на 1с.
А простыми словами можно? Вот чтобы на лист А4 влезало правило. Как в bsl-ls или на ИТС

На хабре даже статья появилась по этому поводу: Пиши простой код
triviumfan; +1 – Ответить
26. booksfill 23.04.25 17:29 Сейчас в теме
(24)
А простыми словами можно?

Нельзя.
1. Сова на глобус натягивается трудно и долго. Ну плохо приспособлен 1С к ООП.

Это как салатом оливье: можно заменить рябчиков колбасой, черную икру зеленым горошком, и залить все вместо соуса "соя-кабуль" магазинным майонезом, только не надо потом все это выдавать за оливье.

2. Понять как плохо, еще можно, а как хорошо иногда зависит от 100500 вариантов потребностей.

И ссылка на хабр это демонстрирует, там вариантов "хорошо/плохо" в комментариях накидали, намного больше, чем заняла сама статья. Причем каждый своим долгом считает создать свой вариант совы и подобрать свой глобус.
+ – Ответить
27. пользователь 25.04.25 00:05
Сообщение было скрыто модератором.
...
28. Asmody 28.04.25 13:12 Сейчас в теме
Сначала мы выкидываем реализацию ЗаполнитьДанныеЦены куда-то в глубину общих модулей, и радуемся какие мы "принципиальные", а потом в модуле документа пишем: 

Для каждого стрТовары из Товары Цикл
      стрТовары.Цена = Ценообразование.ДанныеУстановленнойЦены(стрТовары.Номенклатура);
КонецЦикла;


- принципиально?
- дА!!
- архитектурно?
- да ваще!
brr; +1 – Ответить
29. Rasylit 04.05.25 17:52 Сейчас в теме
Руслан ну разделили вы одну процедуру
Процедура ОбработатьЗаказ(ЗаказОбъект) Экспорт

на 5 разных процедур
но Вы не показали как именно Вы ожидаете должна выглядеть процедура ОбработатьЗаказ ?
после раскидывания по модулям её кусков ?

Вопрос то в том, что процедура ОбработатьЗаказ теперь будет представлять вызов 5 процедур в определенной последовательности и снова этот метод:

-вызывает несколько разнородных задач
-у метода более одной причины для изменения
-читабельность кода точно не улучшается, т.к. нужно скакать по процедурам

я не за спагетти код , я не пониманию как в рамках процедурного программирования избавиться, от того, что дели не дели по процедурам всё равно будет процедура в которую напихано куча функциональности подобно обработать заказ ?
RPGrigorev; +1 – Ответить
30. RPGrigorev 783 05.05.25 18:49 Сейчас в теме
(29) Хороший и правильный вопрос, Андрей. Поделюсь своим мнением на этот счет.

Прежде всего, мы получаем модульность после того, как разместили потенциально универсальные методы в модулях, соответственно, дополнительно страхуемся от дублирования кода и гарантируем одинаковую логику для всех вызывающих методов.
Основной метод ОбработатьЗаказ() будет вызывать другие, но он больше не будет отвечать, например, за определение текущего пользователя, он переложил эту ответственность на другой модуль и метод. В свою очередь, все методы находятся в программных интерфейсах модулей, это значит, что их контракт не должен изменяться, и вызывающий код может на него полагаться. Таким образом, если логика определения пользователя изменится, то контракт останется прежним, и мы не будем править основной метод ОбработатьЗаказ() и все другие, полагающиеся на контракт.

Да, один метод будет вызывать несколько других после рефакторинга из примера S, но это также нормально, от этого не избавиться и даже не нужно, если выполняется единая задача.
Например, есть отдельные методы: ПодключитьТерминал(), ОткрытьЧек(), ПробитьПозициюЧека(), ЗакрытьЧек() и т.д.
В случае пробития чека все они являются неотъемлемой частью одной задачи, и очень даже хорошо сделать один метод ПробитьЧек(), в котором разместить соответствующие вызовы.

К слову, есть такие паттерны проектирования, как "Фасад" или "Шаблонный метод", чтобы скрывать сложность за простым интерфейсом, рекомендую также изучить, пример с пробитием чека как раз пример такого "Фасада".

Как итог, всегда нужно подходить осмысленно к каждому конкретному случаю.
+ – Ответить
31. Cyberhawk 135 09.05.25 09:18 Сейчас в теме
разделим обязанности между модулями и методами
Не понял, а куда делся изначальный метод 
ОбработатьЗаказ()
?
+ – Ответить
Оставьте свое сообщение