Ну вот если кому надо подробнее https://habr.com/ru/company/itelma/blog/546372/?

Ну половина просто высосана из пальцев. 1. YAGNI "Если вы занимаетесь рефакторингом метода, класса или файла, не бойтесь удалять лишние методы. Даже если раньше они были полезны – теперь они не нужны." А потом оп, это был не метод, а фм который дергали по RFC ))) По грамотному это закоментить содержимое 2. DRY звучит полезно, но часто как бывает: у заказчик в рамках ускорения/экономии бюджета раздал по 1 задаче из общего по сути блока задач разным программистам/компаниям, они друг о друге ничего не знают - у них оказывается общий набор констант и даже функционал местами пересекается, но раз они не знаю друг о друге, то каждый напишет "свою" версию. Такие момент должен разруливать архитектор у заказчика, но как правило его нет. Даже встречал компании у которых нет ни одного специалиста поддержки по сап, а задачи выдают менеджеры-пользователи ))) 3. KISS Тоже очень размыто... КОд можно сделать под одну задачу, можно сделать более "универсальным" и сложным. Так из принципа "универсальности" и простоты в дальнейшем по сути и рождаются новые библиотеки, и штуки типо zwww. Даже тут Олег скидывал свою ноу-хау по работе с БД типо бобф обертки 4. Big Design Up Front Глобально продумать это хорошо. Но как правило абеперы это аутсорс - которому сказали сделать ТАК и за это столько-то ЧАСОВ. Поэтому оплата за "думать" редко входит и наказуемо. И чем-то противоречит предыдущему пункту ) 5. SOLID Single-responsibility principle /Принцип единственной ответственности звучит уже неплохо. интуитивно так часто и делаю) D) Dependency inversion principle / Принцип инверсии зависимостей Этот пункт опять потиворечит пункту простоты, те делать абстрактно-универсальные программы, которые "возможно" пригодятся, но скорее нет)

Но спасибо за статью. Часто бывают на собесах любят подобное что-то спросить

Ты не понял суть инверсии зависимостей. Там всё про ООП, паттерны и прочие максимальные абстракции.

Не, ну так-то DI действительно противоречит ряду др. принципов из списка. Можно сказать, что расширения в сап это как раз DI. Оставили место, где можно воткнуться. А не нужно? Ну что поделать, а место для этого уже есть (YAGNI и KISS нарушены) Ну так никто и не говорит, что эти принципы должны однозначно выполняться вместе. Как всегда: нужно искать баланс

Про расширения согласен, про то, что это DI - нет.

Ну нет - так нет ) Я ж говорю "можно". Похоже. В темноте и издалека)

Вся суть сводится к фразе "программируйте интерфейсами". Максимально абстрактно. И тогда код будет максимально стабилен и расширяем. Он будет прост, но прост в парадигме ООП.

Интересно, почему это расширения не DI? Возьмём Бади: интерфейс-контракт, при соблюдении которого не страшны любые апдейты с обеих сторон - клиента и поставщика. Стабильно, расширяемо. Другие способы расширения, по сути тоже контракты, только не ООПшные

Бади - да, остальное - нет

Т.е. DI это строго ООП и точка?)

Нет программирования, кроме ООП. 😂

Чёт вики с тобой не согласна https://ru.m.wikipedia.org/wiki/%D0%9F%D1%80%D0%B8%D0%BD%D1%86%D0%B8%D0%BF_%D0%B8%D0%BD%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B8_%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9

Замени модули на интерфейсы и читай моё сообщение про ООП. 😂

Оставь модули как есть и сравни с кастомер-экзитами😜

Нет. Нет. И не уговаривай! (С)

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

Архитектор и архконтроль? Не, не слышал )

Реально редко слышу) Шабашка была, компания имеет САП крупно использует, но нет ни одного сотрудников штате отвечающего за абап код, только базисники немного. Если что-то надо то на аутсорс и там как повезет )))