Конешно есть, ибо это всё придумыввало наше поколение для вас, все это обсуждалось и выводилось на моей памяти.
Мои аргументы за красоту:
Продуманный абстрагированный DSL позволяет делать декларативный код
Единый доменный язык даёт код, понятный программисту, заказчику и доменному эксперту
"С точки зрения теории, ваши рассуждения правильные, вопросов нет: явно описывается поток управления — всё красиво. Однако в проектах,
где над кодом работает большая команда, такие штуки
не работают — слишком сильно увеличивается порог вхождения в код. Чтобы дописать новую возможность или исправить ошибку, надо сначала разобраться с вашим подходом, понять все ваши абстракции, задать кучу вопросов коллегам и т.д. Пока пятый сотрудник научится этим добром пользоваться, первый уже застрелится."
Отделение бизнес-логики от реализации позволяет продумывать логику, не спотыкаясь на лишние детали
Бизнес логика отделяется от реализации .. в ПРИЛОЖЕНИИ разработчика. Сочинять слой "бизнес-логики" в ИНСТРУМЕНТЕ для него - есть ненужная избыточность и снижение КПД реализации.
Инкапсуляция изменчивости за интерфейсы избавляет от жёсткой привязки к инструментам
Словоблудие чистой воды в отношении к фреймворкам. Вы много назовете рабочих проектов (Приложений), которые легко мигрируют с Yii1 на Yii2, Zend1,2, Laravel, Symphony? Да даже наличие драйверов PDO ни разу не упрощает миграцию скажем с MySQL на MS Server!
это чистая демагогия.
Структуры вместо ассоциативных массивов снижают вероятность опечаток
В PHP ассоциативный массив и есть структура. Иных нет. Динамическое создание свойств к объектам ни разу не снижает вероятность ошибок при опечатках. Больше того! массивы и объекты в PHP по большому счету одно и тоже или условно "синтаксический сахар"..
К вероятности опечаток не имеет никакого отношения, впрочем.
Интерфейсы позволяют полиморфно подменять реализации или откладывать выбор реализации на потом
В теории. На практике возникает сермяжный вопрос до какой степени дробить на интерфейсы? До одного метода?
Это как раз то самое место "заставь .."
Ограничения работы через интерфейсы повышают дисциплину программистов
Демагогия, призванная завуалировать низкий уровень разработчика и переплачивать ему в ЗП. Ибо дисциплина программиста и есть значительная часть его "уровня".
Разделение по ответственностям позволяет разрабатывать каждый фрагмент отдельно
Низкая связанность компонентов позволяет менять код компонента без страха сломать окружающий код
Конечно. Только к обсуждаемому вопросу отношения не имеет. Равно применимо как к глубокой ООП разработке так и работе в "чистых глобалах". Ниочем.
Интерфейсы позволяют добавлять новую функциональность через прокси, декораторы и композицию, не влезая старый код
Не смешите. Ровно точно также это все можно делать и без интерфейсов и вообще без ООП. Все эти декораторы, прокси и пр. "паттерны" есть не что иное как добавление очередного уровня косвенности в код, за который платим и очень дорого.
Грамотное проектирование архитектуры приложения, ориентированная на его развитие исключает все это чуть больше чем полностью.
То есть Вы опять ратуете за низкий уровень разработчика.
С маленькими простыми классами удобно проверять их бизнес-логику отдельными простыми юнит-тестами без комбинаторного взрыва
Никак не зависит от размера класса. Просто "лапша на уши". Класс, в котором 20 методов по 2 строки, даже сложнее покрыть тестами, чем класс имеющий 2 метода по 20 строк. Их банально надо писать больше.
Со временем из 50 простых классов по 20 строк проект вырастет до 100 таких же простых классов, а один класс из 1000 строк усложнится до монстра с 2000 строк с сотнями if-ов
Добавление к 50 классам нового 51-го класса с if-ом и тестом никак не ломает предыдущие классы и тесты, а добавление if-а внутрь 1000-строчного класса мгновенно ломает десяток тестов для этого мега-класса
Статические анализаторы мгновенно ловят ошибки несовместимости типов
Функциональные тесты за секунды находит регрессивные поломки при доработке кода
Статические анализаторы и тесты за секунды находят ошибки при переходе на новую версию PHP
При отсутствии анализаторов и автотестов возникает страх обновления проекта
Чётко структурированный на модули и классы код экономит время на знакомство с частями проекта у нового программиста
Использование готовых сторонних компонентов экономит время на разработку
Использование сторонних проверенных сообществом компонентов повышает надёжность проекта
Готовые компоненты пишет, обновляет и исправляет их автор и сообщество
Отделённые классы можно выносить в отдельные пакеты
Использование знакомых фреймворков упрощает поиск новых программистов
Может Вы их просто писать не умеете? "Большие классы"
Можно и детальней, но не так много времени. В целом, ваш набор аргументов - типичен, и не раз обсуждался в Сети. По большей части он связан не с работой команды, а с низким уровнем её участников, когда разраб не способен понять что делает функция в 50 строк кода, и разбивает ее на десяток по 5 строк. Со временем, такое решение разрастается в 100500 классов "ниочем", возникает проблема "сочинить имя ещё одному действию, свойству", в какой интерфейс, класс, хелпер, сервис запихать новый метод .. и т.д.
В реальности, все часто как раз наоборот: одна большая и полностью законченная функция используется в работе гораздо легче чем 100500 её мелких аналогов. Тупо объем требуемого запоминания меньше. И, как ни странно, это также хорошо видно в автопроме: один большой гелентваген удобней в управлении чем лисапед, на котором надо ещё уметь равновесие удерживать.
Но именно подход с аргументами выше - это простоение 100500 мелких лисапедов и объявление их "большим фреймворком".
Истина - посередине. И эта середина определяется из нагрузочных и потребительских требований, а вовсе не "теорией покрытия каждой функции своим интерфейсом". Как раз из такой середины, ещё в 80-х годах прошлого веку и была выведена рекомендация на размер функции в 50 строк. Это - ОПТИМУМ как для исполнителя (PHP в данном случае), так и для писателя (разработчика).
Специально, для вас выводилось..
Все чаще Историки находят следы древней и очень высокоразвитой Цивилизации, со странными буквами .. СССР