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

14.04.25

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

+23 –1
> > > > > > > > > > >
  • Gemini_Generated_Image_i3v4pei3v4pei3v4.jpg
  • Gemini_Generated_Image_oumemeoumemeoume.jpeg
  • 498c326612d811f0bf362ec7f0e890f6_4.jpeg
  • b8cebd1212d911f08c57f600b5cb441c_2.jpeg
  • Screenshot 2025-04-10 191330.png
  • df96082312fb11f0bf905e3ebe269240_2.jpeg
  • Screenshot 2025-04-08 131259.png
  • Screenshot 2025-04-10 190858.png
  • Screenshot 2025-04-10 195146.png
  • Screenshot 2025-04-11 140424.png
  • Screenshot 2025-04-11 150446.png
  • Screenshot 2025-04-11 150919.png
Разбираем принципы SOLID в контексте 1С: как укротить хаос в коде, сделать его гибким, расширяемым и предсказуемым. Практические примеры, механизмы платформы помогающие в этом и шаги к чистой разработке для новичков и профи.

Предисловие

Когда я впервые услышал про принципы SOLID в контексте 1С, моя реакция была простой: "Что это такое?" И, судя по всему, не у меня одного. Стоит завести разговор о SOLID среди 1С-разработчиков, как в ответ, либо недоуменные взгляды, либо попытки найти хоть что-то в интернете, после которых вопросов становится только больше. Сегодня эти слова всё чаще мелькают на собеседованиях, в требованиях компаний и в поисковых строках разработчиков. Материалов, которые бы ясно объясняли, как эти принципы работают в нашей платформе, почти нет. В лучшем случае попадаются общие материалы про ООП, не учитывающие специфику платформы. В худшем, разрозненные публикации, оставляющие больше вопросов, чем ответов. И вот вы уже сидите, уставившись в экран, пытаясь понять, как эти принципы вообще применимы к 1С? А ведь на самом деле SOLID давно живёт в типовых конфигурациях.

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

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

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

Что такое SOLID

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

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

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

Начнём с первого принципа — и посмотрим, как одна простая мысль меняет всё.

 
 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, вы увидите код по-новому, вместо набора процедур он превратится в систему взаимосвязанных компонентов, где каждая часть играет свою роль. Это как переключиться с хаотичного "пишу как получится" на структурированное "проектирую с целью". Используйте материал как чек-лист при проектировании:

  1. Анализируйте задачи с точки зрения ответственности: один модуль — одна цель.
  2. Проектируйте код с возможностью доработки через расширения или переопределение.
  3. Проверяйте, чтобы подмена типовой логики не ломала контракт с вызывающим кодом.
  4. Упрощайте интерфейсы, убирая из них всё лишнее для конкретного клиента.
  5. Внедряйте абстракции, чтобы разорвать жёсткие связи между слоями.

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

Послесловие

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

Также хочется отметить, что статью я писал в одиночку, и наверняка она не лишена недостатков. Сейчас её просматривают тысячи новых людей, тысячи свежих взглядов и мнений, поэтому я, и, надеюсь, многие, будем благодарны за вашу вовлечённость и улучшение этого материала. Если у вас есть свои примеры или идеи, как можно было бы сделать лучше, не стесняйтесь принимать участие и делиться ими! До новых встреч!

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

+23 –1

См. также

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

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

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

26.03.2025    404    ksuman    6    

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

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

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

19.03.2025    2836    EFSOL_oblako    9    

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

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

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

17.03.2025    2427    Bukaska    5    

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

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

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

11.03.2025    5293    mrXoxot    52    

53
Тестирование после рефакторинга платформеннозависимого кода

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

В последней статье по докладу Александра Кириллова, с которым он выступил на конференции INFOSTART TECH EVENT 2024, обсудим особенности тестирования после завершения рефакторинга платформеннозависимого кода

11.03.2025    552    it-expertise    0    

3
Оформлятор модулей 1С

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

Расширяемый форматтер структуры модулей 1С. Умеет автоматически расставлять стандартные области и раскидывать по ним процедуры и функции модуля, оформлять стандартные комментарии к методам с помощью ИИ. Также умеет анализировать модуль - извлекать структуру вызовов, используемые поля и т.д. Реализован в виде расширения (.cfe). Можно использовать как платформу для обработки кода в своих задачах автоматизации разработки.

12.02.2025    7370    466    wonderboy    44    

119
Подходы к рефакторингу платформеннозависимого кода

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

В третьей статье по докладу Александра Кириллова, с которым он выступил на конференции INFOSTART TECH EVENT 2024, обсудим подходы к рефакторингу платформеннозависимого кода

11.02.2025    1151    it-expertise    0    

3
Анализ конфигурации 1С на наличие платформеннозависимого кода

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

Во второй статье по докладу Александра Кириллова, с которым он выступил на конференции INFOSTART TECH EVENT 2024, поговорим об особенностях анализа конфигурации 1С на наличие платформеннозависимого кода.

31.01.2025    1852    it-expertise    1    

8
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. VGHOST 168 14.04.25 23:00 Сейчас в теме
Теперь понятно, зачем в 1С столько пустых и однострочных процедур и модулей, которые друг друга вызывают по кругу, перегружая стек)
Я то думал, это азы программирования, а вона оказывается - SOLID, высшая пилотажа...
pavlov_dv; lone_mayson; +2 – Ответить
5. RPGrigorev 713 15.04.25 08:14 Сейчас в теме
(1) Согласен, в других языках программирования, это действительно азы. Но если взять классический путь разработчика 1С, самые популярные книги, курсы для старта, там ни слова о стандартах написания кода и каких-то общепринятых принципах, поэтому для многих в 1С, SOLID это действительно новое слово, даже спустя годы работы...А по поводу стека, со множеством вызово, как по мне, все это перекрывается преимуществами
VGHOST; +1 – Ответить
12. starik-2005 3171 15.04.25 10:59 Сейчас в теме
(1) Проблема множества вызовов - это, во-первых, попытка преодолеть все эти "цикломатические" и "когнитивные" "сложности" сонара, а уже во-вторых - поверхностное понимание архитектурных изысков и попытка сделать хоть как-то, чтобы удовлетворить на минималках архитектурную группу (если она вообще есть и в этом принимает участие).

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

Оставалось ограничение сохранности переменных между вызовами функций, ибо локальные переменные грохались, а глобальные переменные увеличивали связанность. В итоге придумали классы, экземпляры которых (объекты) сохраняют свои локальные переменные между вызовами. И тут уже можно и в SOLID. В 1С объекты, которые могут сохранять свои данные - это или персистентные объекты, связанные с записями в СУБД - справочники, документы и прочее, или обработки и отчеты, которые могут сохранять свои состояния без СУБД, но теряют их, выходя из зоны видимости переменных, в которых они записаны.

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

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

Золотая середина - это не наши методы )))
VGHOST; zen_daya; awk; RPGrigorev; +4 – Ответить
13. RPGrigorev 713 15.04.25 13:37 Сейчас в теме
(12) Спасибо за такой развернутый и полезный комментарий, очень интересные мысли! Благодарю за интерес к статье и участие в обсуждении
+ – Ответить
2. gybson 14.04.25 23:34 Сейчас в теме
Я бы не стал модуль менеджера обзывать низкоуровневыми. Тем более, что это реализация первого принципа. А так очень даже и неплохо, хотя и ощущается помощь ИИ.
+ – Ответить
6. RPGrigorev 713 15.04.25 08:25 Сейчас в теме
(2) Соглашусь, низкоуровневый для модуля менеджера, скорее не самое точное слово, спасибо за комментарий, рад положительной оценке
+ – Ответить
3. kumga99 26 15.04.25 06:30 Сейчас в теме
SOLID можно применять там где есть серийное приложение например конфигурации 1С а когда ты штатный программист 1С вряд ли получится придерживаться SOLID тупо потому что тебя будут торопить и соблюдая сроки многие программисты будут говнокодить жестко чтобы бизнес смог быстро решить свои проблемы
+ – Ответить
4. RPGrigorev 713 15.04.25 08:05 Сейчас в теме
(3) Соглашусь, если вся команда гонится за сиюминутными задачами, качественный код остаётся на втором плане, но в свою очередь, это порождает технический долг, который, как мне кажется, потом ударит всех больнее...Думаю, что это будет хорошо работать, не при героизме одного разработчике, а комплексно, при должной культуре разработки внутри компании. Но в целом, считаю, что даже, не применяя это целиком всё сразу, а делая небольшие шаги, например немного увеличив время на разработку, разбив одну большу процедуру на модули и методы, уже сэкономит время и нервы в будущем.
VGHOST; +1 – Ответить
7. VAAngelov 540 15.04.25 08:47 Сейчас в теме
Отличная статья! Нужно постепенно привыкать все-таки чистокодить, выдвигая на первое место качество продукта, а не только хотелки бизнеса сиюминутно получить закрытую задачу. Жду продолжения! Успехов и удачи в развитии! Спасибо за проделанный труд! Моя искренняя благодарность!
RPGrigorev; +1 – Ответить
8. RPGrigorev 713 15.04.25 09:01 Сейчас в теме
(7) Спасибо большое за постоянную поддержку, благодарен в ответ!
VAAngelov; +1 – Ответить
9. adamx 37 15.04.25 09:25 Сейчас в теме
"валидация данных, введённых пользователем, — это одна задача. Сохранение их в базу — уже другая. Смешивать их в одном модуле или методе — всё равно что ситуация на изображении."
А у нас в 1С дерево модулей появилось что ли?
Если данные одни и те же однотипные - что мешает их в одном модуле и записывать в базу и проверять?
Общих модулей уже штук 300 наверное в ERP. И непонятно как искать нужный...
Вернее понятно, поиск сверху, отбор по подсистемам... Но все равно - перебор с модулями. Зачем их плодить?
+ – Ответить
10. RPGrigorev 713 15.04.25 10:39 Сейчас в теме
(9) в этом еще помогает хороший нейминг
в основном, нахожу таким образом, например, смотрю для какого уровня задачи я ищу методы, если мне нужны методы конкретно на уровне заказов, значит предполагаю, что общий модуль, так или иначе, скорее всего должен содержать в наименовании "заказы", если мне нужен уровень выше, например общая работа с документами, я ищу по ключевым словам "документы" или под конкретные задачи "проведение" и т.п.
Но если мы спрячем общий метод для работы с уровнем документов, например в модуль "заказы", вот тогда, его действительно сложно будет найти
+ – Ответить
11. booksfill 15.04.25 10:55 Сейчас в теме
Надо бы придумать какое-нибудь другое модное слово, например, KISSIsАboveAll.

Не буду спорить с SOLID, ибо в принципе верно.

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

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

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

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

- ПроверитьСумму - генерирует исключительную ситуацию. Почему вы решили, что это не нарушает тот же первый принцип?
Кто сказал, что проверка суммы должна приводить к иcключению?
А если уж приводит, то как из названия метода это понять?
А ничего, что вы своими руками, создали метод, который, мягко говоря, не является универсальным, и если, например, надо только проверить сумму, без исключения, то придется создать еще один метод.
А ничего, что проверка суммы в вакууме никому не нужна, и вы, вынеся эту проверку в отдельный метод, добились, только того, что одна строчка превратилась где-то в 5 и еще уехала в другое место?
И т.д.

Но еще раз я за SOLID, но только при разумном подходе.
starik-2005; +1 – Ответить
14. RPGrigorev 713 15.04.25 14:03 Сейчас в теме
(11)
умудрились нарушить другой принцип - не рекомендующий плодить однострочные методы

Принципа, который прямо запрещает однострочные методы, в SOLID или классических практиках нет. Есть, скорее, рекомендации по здравому смыслу, например, в книгах вроде "Чистый код" Роберта Мартина, где рекомендуют избегать избыточной декомпозиции, наверное Вы это имели ввиду

Вы хотя бы текст в Нстр обернули.

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

ПроверитьСумму - генерирует исключительную ситуацию. Почему вы решили, что это не нарушает тот же первый принцип?
Кто сказал, что проверка суммы должна приводить к иcключению?
А если уж приводит, то как из названия метода это понять?

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

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

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

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

Как Вы определили, что она никому не нужна? Суть в том, что это переехало в модуль "ПроверкаЗаказов" т.е. разделило ответственность между модулями и методами

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

Исключительно согласен, все в меру и разумно! И благодарю за неравнодушие к материалу!
VAAngelov; +1 – Ответить
15. booksfill 15.04.25 18:20 Сейчас в теме
(14) Непонятно причем здесь "разделило ответственность между модулями и методами". Это как бы вообще разные понятия. Наверное имелось в виду, хм... нет кратко сформулировать не могу. Бог с ним.

Давайте, например, посмотрим метод 
Процедура ПроверитьСумму(ЗаказОбъект) Экспорт
   
    Если ЗаказОбъект.СуммаДокумента < 0 Тогда
        ТекстОшибки = СформироватьТекстОшибкиСуммы(ЗаказОбъект.СуммаДокумента);
        ВызватьИсключение ТекстОшибки;
    КонецЕсли;

КонецПроцедуры
Показать


Т.е. вместо 
Если ЗаказОбъект.СуммаДокумента < 0 Тогда
        Сообщить("Сумма " + ЗаказОбъект.СуммаДокумента + " недопустима!");
        ТекущийСтатус = "Ошибка";
    Иначе
        ТекущийСтатус = "Подтверждён";
    КонецЕсли;


1. Почему-то вызываем метод, выбрасывающий исключение, хотя в исходном коде этого вообще не было,

2. В первоначальном случае, в зависимости от суммы заказа менялся статус, теперь меняться он при "не той сумме" не будет. А для вызывающего внешнего метода зато будет сюрприз типа возникшего неоткуда исключения.

Из 1 и 2 следует, что вы (тут у меня страшное подозрение - а не c DeepSeek ли я я беседую?) неверно вынесли код в принципе, поменяв поведение первоначального метода.

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

4. Метод жестко привязан к типу метаданных и виду проверки. Именно это я имел в виду под "никому не нужен" - не нужен никому, кроме родительского метода.

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

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

Но и это еще не все, вынеся все в отдельные методы, мы никак не упростили поведение первоначального, он все также занимается несколькими делами сразу, просто вместо прямого безобразия дергает сразу несколько НЕУНИВЕРСАЛЬНЫХ методов. Ключевое слово "неуниверсальных".

И еще, выдавая нечто вроде 
Процедура УстановитьКомментарий(ЗаказОбъект, ТекстКомментария) Экспорт
    ЗаказОбъект.Комментарий = ТекстКомментария;
КонецПроцедуры


Мы по сути переносим декомпозицию на уровень интерпрератора,
Это ничем не отличается от: 
Процедура СложитьЧисла(результат, а, в);
   результат = а + в;
КонецПроцедуры


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

P.S.
Ах, да, будет интересно посмотреть на демонстрацию Liskov substitution principle на примере 1С.
+ – Ответить
16. RPGrigorev 713 16.04.25 08:49 Сейчас в теме
(15) Действительно в примере принципа S, я напортачил c сохранением исходной логики метода, также согласен, что декомпозиция по установке комментария и статуса излишняя, сейчас этот пример модифицирован.

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

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

Добавил вот такой абзац в статью:
Также хочется отметить, что статью я писал в одиночку, и наверняка она не лишена недостатков. Сейчас её просматривают тысячи новых людей, тысячи свежих взглядов и мнений, поэтому я, и, надеюсь, многие, будем благодарны за вашу вовлечённость и улучшение этого материала. Если у вас есть свои примеры или идеи, как можно было бы сделать лучше, не стесняйтесь принимать участие и делиться ими!


И хочу сказать спасибо за вовлеченность! Благодаря Вашему комментарию удалось по другому взглянуть на первый пример и выявить ошибку. Буду рад любым замечаниям или даже примерам, как бы Вы сделали, по улучшению этого материала
VAAngelov; +1 – Ответить
17. vandalsvq 1608 16.04.25 16:20 Сейчас в теме
Пример для демонстрации инверсии зависимостей крайне неудачный. Ключевым (тут я не прав, не ключевым, но важным) моментом является тот факт, что метод возвращает не только данные номенклатуры (справочника), но и цену, которая к объекту номенклатуры не имеет отношение (в нашей реализации), и хранится в другом объекте.

Причина по которой нам надо сделать 2 общих модуля не до конца раскрыта. Общий модуль НоменклатураСервер решает задачу D, а вот РаботаСНоменклатурой это скорее про S.

По-моему куда более качественный вариант было бы показать на примере общения между разными методами (модулями, подсистемами) на основе "контракта".

Ну и наконец, а название метода ПолучитьДанныеНоменклатуры ничего не нарушает?

пы.сы. не претендую на истину
+ – Ответить
Оставьте свое сообщение