ИОП = Сотворение исполнителей.

Мышление: Декларация vs Империя.

Статические методы работают быстрее, потому что нет необходимости создавать новый объект. Вызовите статический метод, он сделает дело, вы получите результат и будете работать дальше. Нет необходимости возиться с объектами … Дали компьютеру инструкцию, и он её выполняет. Просто и понятно? Когда путь решения прост и прямолинеен — да, на реальных, жизненных НЕТ!

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

«Процедурное мышление» или «мыслить как компьютер» описывает проблему = мы унаследовали образ мышления из первых языков программирования =  компьютер работает на нас, а мы указываем ему, что делать, давая ему явные инструкции.
Мы думаем, что если мы указываем компьютеру, что делать на понятном ему языке, то мы у руля? Хрен там! Программист может думать как компьютер в очень ограниченных пределах. Когда он думает, что он умеет думать как компьютер, и пытается решить сложные задачи как компьютер — он резко отрекается от своего  природного, антропологического, божественного дара мышления и начинает двигаться к выгоранию.

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

Cтатический это метод или исполнитель, мы должны где-то написать if? Да, Как статический метод, так и исполнитель — они лишь обертки над оператором if, который выполняет задачу сравнения.
Разница в том, как эта функциональность используется другими исполнителями. И это реально разница. Стиль будет декларативным, поскольку я не указываю процессору, что вычисления нужно выполнить сразу. Я определил, что это такое, и оставил на усмотрение пользователя решение о том, когда (и нужно ли вообще) вычислять переменную. Может, она никогда не будет вычислена и мой процессор никогда не узнает, что это.
Всё, что я сделал, — объявил. Просто объявил. Я ещё не дал никакой работы процессору. Выразил логику, не описывая процесс.

Императивное (процедурное, структурное) программирование «описывает вычисления в терминах операторов, изменяющих состояние программы».
ИОП = естественный образ мышления: исполнители и отношения между ними — базар.
ИОП мощный, природный подход, но императивный (от лукавого) понятнее процедурным программистам.

ИОП не указывает процессору, что ему делать, позволяет процессору решить, когда и где вычислять по требованию.

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

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

Большинству разработчиков проще понимать имперский подход. Он очень похож на то, что вы ежедневно видите в коде.
Это обманчивое ощущение. Начните думать в терминах исполнителей и их поведения, а не алгоритмов и их исполнения, и вы приобретете полезное восприятие.
ИОП — поведения, а императивный — алгоритмы и их исполнения.

В длинной имперской портянке трудно понять какие строки кода связаны друг с другом.

Имперский стиль нельзя совместить с ИОП чисто технически. Когда вы начинаете использовать императивный подход, вы обречены — постепенно весь ваш код станет имперским.
Что же делать? Изолируйте имперскую заразу оборачиванием в исполнителей — и вы сможете творить общаясь с исполнителями, а не с компьютером.

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

Глобальные переменные однозначно нарушают принцип инкапсуляции. Несмотря на доводы против глобальных переменных, нашли способ использовать их через паттерн «Синглтон».
Чем их заменить? Если нам нужно, чтобы нечто было доступно нескольким исполнителям в рамках всего программного продукта?
У нас нет классов-утилит и синглтонов. Что у нас есть? Инкапсуляция!
Инкапсулируйте во все классы-матки, в которых это нужно.
Всё, что нужно вашему исполнителю для работы, должно быть передано посредством конструктора и инкапсулировано внутри матки. Без исключения.
Исполнитель не должен затрагивать ничего, кроме своих инкапсулированных свойств.
Вы можете сказать, что придется инкапсулировать слишком много: подключения к базам данных, вошедшего в систему пользователя, аргументы командной строки и т. п. Да, действительно, всего этого может оказаться слишком много, если матка большая и не цельная — переработайте матку — уменьшите.

Если исполнители внутри краткие и не задействуют статические методы, почему бы не использовать функциональное программирование (фп)?
ИОП более выразительно и имеет большие возможности, поскольку оперирует исполнителями и методами, тогда как фп — лишь функциями.

Компонуемые декораторы (Бугаенко Егор)

Исполнители-обёртки над другими исполнителями. Они являются декораторами — известным паттерном объектно-ориентированного проектирования, — но становятся компонуемыми, когда мы объединяем их в многослойные структуры, к примеру:

names = new Sorted(
    new Unique(
        new Capitalized(
            new Replaced(
                new FileNames(
                    new Directory(
                        "/var/users/*.xml"
                    )
                 ),
                 "([^.]+)\\.xml",
                 "$1"
             )
         )
     )
);

Код чист и исполнителе-ориентирован. Он исключительно декларативен
Он ничего не делает, а лишь объявляет исполнителя names, который является отсортированной коллекцией уникальных строк верхнего регистра, представляющих имена файлов в каталоге, измененных определенным регулярным выражением. Я объяснил, чем является этот объект, не говоря ни слова о том, как он устроен. Я просто объявил его.
Исполнители Directory, FileNames, Replaced, Capitalized, Unique и Sorted — декораторы, поскольку их поведение полностью обусловлено инкапсулируемыми ими исполнителями. Они добавляют им некоторое поведение. Их состояние совпадает с состоянием инкапсулированных.

Большая часть кода в чистом исполнителе-ориентированном ПО должна быть похожа на приведённый. Мы должны композировать декораторы друг в друга.
Вся иерархия исполнителей взаимодействует.
В коде совсем не должно быть процедурных операторов вроде if, for, switch и while. Звучит как утопия, но это не утопия.

Не нужны операторы, унаследованные из процедурных языков вроде С. Не нужны if, for, switch и while. Нам нужны классы If, For, Switch и While. Чувствуете разницу?
Мы ещё не дошли до таких языков.

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

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