Котаны, я тут давно одну мысль вынашиваю, вот решил поделиться. Речь пойдет о DRY и инкапсуляции в ООП.
Все 100 раз слышали мантру, что дублировать код грешновато и надо инкапсулировать дублирующуюся функциональность, используя все имеющиеся для этого средства вашего любимого ЯП(наследование, композицию, все чудеса GoF и т.п.). Обычно тут аппелируют к расширяемости, поддерживаемости и т.д.
В теории все шоколадно конечно, но в постоянно меняющейся среде все эти замечательные абстракции могут превратиться в тыкву протекающие, коллеги начнут путаться в этих бесконечных "фабриках сервисов стратегий" и в один прекрасный день кто-то все это снесет, построив на руинах еще одну такую же башню из слоновой кости. Знакомо?
Более того, в модных нынче микросервисах дублирование считается нормальным(ну по-крайней мере меньшим грехом чем связность сервисов как в классическом SOA). Оттуда же растет популярность сервисных каркасов(шаблонов проектов типа create-react-app или dotnet new), где через cli создается костяк проекта, который можно менять как душе угодно.
Кароч вот такая мысль, что думаете?
Мое мнение, что тут отлично работает правило 3х: 3 раза задублировал, значит надо инкапсулировать, а до этого нинада.
UPD: речь тут не про выделение кода в методы, а скорее, про ООП головного мозга с абстрактными классами, хелперами и всякими мутными стратегиями на каждый чих