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

12.05.25

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

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

Предисловие

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

Вступайте в нашу телеграмм-группу Инфостарт

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

+59 –

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

Рейтинг обработок базы по качеству кода, худшие сверху

Инструментарий разработчика Рефакторинг и качество кода Программист 1С 8.3 Абонемент ($m)

Обработка читает исходники других внешних обработок и отчётов прямо из базы и отвечает на два вопроса: с какой из них начинать смотреть и что именно в ней смотреть. На выходе HTML-отчёт: индекс качества от 0 до 100, светофор, оценка технического долга в минутах и находки с номером строки, фрагментом кода и подсветкой синтаксиса. Двадцать восемь правил: запрос в цикле, транзакция без отката, небезопасное выполнение строки, тяжёлые схемы компоновки. Считается всё на чистом BSL, без интернета, внешних компонент и отдельного сервиса рядом, поэтому анализируемый код не покидает машину. Прогон по двум десяткам обработок выстраивает их по индексу качества, худшие сверху, и сразу видно, с чего начинать разбор.

10 стартмани

20.08.2026    252    1    nedomolkov.ivan    2    

2
Проверил свои обработки: 15 рабочих дней на починку

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

Библиотека из 6 слоев анализа, от внешней обработки до готового отчёта. Каталог из двадцати восьми правил, у каждого свой уровень и вес. И всё это крутится на чистом BSL, без Java, без git, без какого-то внешнего сервера анализа и без отправки чужого кода наружу. Разбираю, как устроен этот анализатор внешних обработок и по каким признакам он решает, что код плохой. Почему запрос в цикле получает шестьдесят баллов, как правило вообще проходит фильтр перед релизом и почему часть правил у меня помечена как сломанные. Проверял я его на себе: взял семнадцать своих обработок, которые лежат на площадке и продаются. Получил 239 замечаний и пятнадцать рабочих дней технического долга. У самой худшей индекс качества - 20 из 100 и красный светофор. А ещё расскажу, где у инструмента границы, за которые он не заходит, и про грабли - самая дорогая из них молчала.

20.08.2026    355    nedomolkov.ivan    0    

1
Сопряжение 1С и Cursor AI для сравнения модулей

Рефакторинг и качество кода Нейросети Программист Бесплатно (free)

Передача двух модулей BSL в Cursor AI для классического сравнения без использования искусственного интеллекта (ИИ) и для проведения code review с помощью ИИ.

12.08.2026    2434    ScaNNer    0    

5
Как не потерять доработки 1С при обновлении форм-копий: алгоритм сравнения через внешние файлы

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

К нам на проект сложного обновления пришла конфигурация «1С:ERP УХ» с доработанным отчетом, построенным на базе типового «Задолженность поставщикам по срокам». После обновления целевая форма открывалась без учета переданных данных.

05.08.2026    781    1c-izh    4    

4
Аудитор кода 1С

Инструментарий разработчика Рефакторинг и качество кода Программист 1С 8.3 1С 8.5 1С:Документооборот 1С:Бухгалтерия 3.0 1С:Управление нашей фирмой 3.0 Россия Абонемент ($m)

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

2 стартмани

08.07.2026    848    8    NikolayMaerov    0    

4
С 659 до 43 часов: как мы ускорили установку обновления «1С:ERP» 2.4 на 2.5

Рефакторинг и качество кода Обновление 1С Программист 1С:Предприятие 8 1С:ERP Управление предприятием 2 Бесплатно (free)

На проекте сложного обновления 1С:ERP 2.4.14.181 до версии 2.5.22.106 нам было нужно уложить обновление в технологическое окно 48 часов (выходные). Исходный замер, с учетом промежуточных релизов 2.5.8.443, 2.5.12.270, 2.5.17.234, 2.5.22.106, показал требуемое время в 659 часов…

07.07.2026    5202    1c-izh    20    

21
«Чистые» доработки: как обновить доработанную роль в поставляемом расширении 1С

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

Обновление ролей в расширении 1С отличается от аналогичного процесса в основной конфигурации. Ситуация осложняется, когда доработки вносятся не в «обычное», а в поставляемое расширение.

26.06.2026    2254    1c-izh    3    

5
Code review в 1С без токсичности

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

Code review в 1С часто превращается в спор вкусов: “мне не нравится”, “переделай”, “так не делают”. В статье разбираю другой подход: проверять не разработчика, а риск для системы. Показываю, как формулировать замечания без токсичности, где заканчивается личное предпочтение и начинается реальная проблема, почему ревью должно развивать разработчика, а не только исправлять код

24.06.2026    1420    NikolayMaerov    4    

6
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. VAAngelov 566 21.04.25 12:34 Сейчас в теме
Отличная статья! Спасибо за проделанный труд.
rozer; NorraSaltolinen; ivnik; user1948830; RPGrigorev; +5 – Ответить
2. RPGrigorev 812 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 566 21.04.25 17:15 Сейчас в теме
(4) Интересно. А можно вас попросить какие-то примеры? Как неправильно и как правильно. Чтобы наглядно это было видно сразу. Просто очень хочется понять, что же тут неправильно, но я пока не понимаю. Это просьба.
RPGrigorev; +1 – Ответить
18. reset2 20 22.04.25 10:37 Сейчас в теме
(9)
1. Очевидно, что в "правильном" блоке ломается функциональность.
В "неправильном" для реализации свойство берётся из реквизита объекта, а в "правильном" из доп. свойств объекта.
Либо где-то еще должен быть код, который заполняет доп. свойство по реквизиту(ам) документа?
2. Возвращать "Ложь" если свойства нет тоже нарушает функциональность, почему возвращаем Ложь, а не Истина, или Неопределено? Если разработчик "забыл" установить это доп.свойство, то оно и должно обрабатываться как ошибка, а не закрываться костылём.

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

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

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

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

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

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

(18) (4) Если есть предложения, какие примеры, на ваш взгляд, лучше продемонстрируют "наследование" с сохранением ожидаемого поведения для всех подтипов - буду рад.
+ – Ответить
5. shalik 21.04.25 16:46 Сейчас в теме
Спасибо за статью. Жду комментарии от гуру1спрожженых программистов что всякие паттерны, солиды в 1с не нужны и не работают!
ktb; quazare; VAAngelov; RPGrigorev; +4 – Ответить
8. VAAngelov 566 21.04.25 17:07 Сейчас в теме
(5) Сейчас тут будет море таких комментов).
RPGrigorev; +1 – Ответить
14. quazare 4011 22.04.25 05:01 Сейчас в теме
(5) не понятно - нужны или нет, - заказчику точно не нужны… вылизовать код - это привилегия
triviumfan; +1 –2 Ответить
15. shalik 22.04.25 09:20 Сейчас в теме
(14) Заказчику в принципе до фонаря что там в коде и как написано, если решение работает)
+ – Ответить
16. quazare 4011 22.04.25 09:30 Сейчас в теме
(15) категорически согласен) но вот автор статьи считает иначе походу
+ – Ответить
33. korvintorson 88 21.02.26 19:25 Сейчас в теме
(16) Заказчику перестанет быть до фонаря, когда окажется, что для внесения пустякового изменения в функциональность он должен будет оплатить сотни человеко-часов работы.
+ – Ответить
19. VAAngelov 566 22.04.25 12:02 Сейчас в теме
(15) Заказчику-то может быть и пофигу. Но статья ведь не о заказчиках. Статья ведь о том, как прийти к Чистому коду ,чтобы в дальнейшем было удобно расширять, дорабатывать, чтобы другой программист, не имея контекста - мог бы разобраться и допилить новую хотелку заказчика минимальными средствами и трудозатратами. Да, реальность, пока, к сожалению, отличается от желаемого, но это ведь первые шаги, постепенно можно прийти к тому, что код повсеместно будет писаться чисто, тогда везде и дорабатывать его будет легче. Конечно, когда приезжаешь в автосервис, и тебя говорят, что эта работа стоит неделю, то конечно заказчик требует, а давай за 1 день и если мастер на это соглашается - то скорее всего да, он сделает, но как? на скотче и изоленте? и оно даже работать будет, какое-то время, но если эту итерацию повторять снова и снова - то рано или поздно случится ой-ой, и потом скажут - просто на помойку выкини свою машину. Заказчик в недоумении, как так? Ведь все делалось и работало. С докторами то же самое, ведь ни один пациент не станет сейчас спорить, что перед тем, как провести операцию - врач должен тщательно вымыть руки, но ведь были времена в истории, и это реальность, что тоже спорили пациенты - мы же теряем время на помывку рук. Так может быть надо все-таки начинать смотреть в сторону Чистого кода? И пробовать делать первые трудные, тяжелые шаги, но делать, а не просто говорить, ой да ничего это не работает в реальности. Вопросы риторические. Просто для подумать и задуматься. И конечно я понимаю, что сейчас я тоже получу свою порцию против.
nagimo; IgorS; dvsidelnikov; exitel; annamol; 1cmailru; kirillkr; shalik; RPGrigorev; +9 – Ответить
6. brr 184 21.04.25 16:49 Сейчас в теме
Нет инверсии в примере D, добавьте в ДанныеУстановленнойЦены третий параметр и передавайте модуль, и не обязательно общий, можно и модуль менеджера и объект. Будет инверсия. В зависимости от переданного модуля у вас по разному будут считаться центы. Передаваемый модуль естественно должен содержать интерфейс ДанныеУстановленнойЦены.
+ – Ответить
7. brr 184 21.04.25 16:50 Сейчас в теме
В примерах ТС ненавязчиво использует паттерн Информационный эксперт. За что ему респект. :)
RPGrigorev; +1 – Ответить
10. RPGrigorev 812 21.04.25 17:31 Сейчас в теме
(7) Пожалуйста, аргументируйте и приведите "правильные" примеры.
+ – Ответить
12. brr 184 21.04.25 17:42 Сейчас в теме
(10) СкладПоУмолчанию в ММ справочника Склады. Типичное применение информационного эксперта. Ответственность за выполнение задачи должен нести класс, который обладает всей необходимой для этого информацией.
RPGrigorev; +1 – Ответить
11. ivnik 631 21.04.25 17:32 Сейчас в теме
Статья очень полезная, на простом "крестьянском" языке. Спасибо!
RPGrigorev; VAAngelov; +2 – Ответить
13. maxrubtsoff 22 21.04.25 21:00 Сейчас в теме
Только легенды знают, что это перезалив. Рад, что статья снова доступна)
CyberCerber; top_1c; VAAngelov; RPGrigorev; +4 – Ответить
17. Red_Devil 182 22.04.25 10:13 Сейчас в теме
все это хорошо максимум в самописке. Когда дорабатываешь типовую там порой другие требования.
Механизм расширений от 1С например вписывается в solid? Когда их несколько десятков) Или сотни подписок на события(
+ – Ответить
21. Alxby 1159 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 и множество безымянных. Они разные. Иногда они противоречат друг другу. Они по разному влияют на код. Применение какого-либо принципа может как "улучшить" так и "ухудшить" код. Причем это "улучшение" и "ухудшение" очень субъективно. К сожалению, в погоне за соблюдением модных принципов многие забывают о главной задаче: создании надежного ПО, удовлетворяющего потребностям человека и имеющего высокие эксплуатационные характеристики. Маркетинг побеждает инженерию.
user1829375; nagimo; brr; +3 – Ответить
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 Сейчас в теме
Думаю пройдет немного времени и искусственный интеллект будет помогать программисту создавать чистый код.
Допустим создаем обработку заполнения табличной части документа из внешнего файла. Создаю первую процедуру выбора файла , делаю запрос к ИИ и он выдает оптимальный код выбора и обработки файла в зависимости от выбранного расширения. Следующая процедура - заполнение табличной части документа - запрос к ИИ и он выдает оптимальный код в котором уже предусмотрена проверка на наличие номенклатуры в справочнике номенклатуры, при отсутствии заполняет справочник номенклатуры, делает запрос в регистр цена номенклатуры и получаем готовый оптимальный код. Программисту остается только тестирование и эту задачу можно отдать ИИ.
Вижу , что ИИ заменит классы в ООП и получим совершенное ООП_ИИ.
"Каменный век закончился не потому -что камни исчезли". С развитием ИИ профессия программиста не исчезнет, разработка будет проходить быстрее т к в ИИ уже будет накоплен опыт программистов, да и задачи усложнятся.
baranchikov; VAAngelov; +2 – Ответить
24. kuzyara 2263 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 процедур в определенной последовательности и снова этот метод:

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

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

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

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

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

Как итог, всегда нужно подходить осмысленно к каждому конкретному случаю.
VAAngelov; +1 – Ответить
31. Cyberhawk 135 09.05.25 09:18 Сейчас в теме
разделим обязанности между модулями и методами
Не понял, а куда делся изначальный метод 
ОбработатьЗаказ()
?
+ – Ответить
32. user1081668 21.05.25 15:07 Сейчас в теме
Главный принцип - это ВСЁ ХОРОШО в МЕРУ.
И задача главная - это правильно определить МЕРУ для каждого случая
+ – Ответить
Для отправки сообщения требуется регистрация/авторизация