Каждая парадигма имеет свои сильные и слабые стороны. ООП предлагает замечательные функции, такие как инкапсуляция, абстракция или полиморфизм. Это помогает писать более качественный и безопасный код.

Вопрос в том, почему функции ООП вообще существуют, если мы используем Фасады, Сервисы и Репозитории. Это шаг назад к процедурному коду.

Просто, какие они? Репозиторий — это уровень базы данных для выбора — не удаление, обновление или вставка, а только выбор данных. Фасад — это место, где вызывается репозиторий и где можно выполнить некоторые вычисления с возвращенными данными из репозитория ИЛИ выполнить операцию вставки, обновления или удаления. , Service — это просто помощник — что не подходит к указанным двоим, то идет к Service. Просто и глупо.

Это просто контейнеры для функций. Это никак не связано с ООП.

Большинство людей не видят недостатков, которые это приносит, пока не увидят аналогичное подробное описание:

СРП — нет; ОКП — нет; ISP — нет; Высокая сплоченность — нет; Низкое сцепление — нет; полиморфизм — нет; Количество методов растет; Количество классов осталось прежним; Составные имена (большой охват) — Да; Защитный подход — нет; Ориентирован на домен — нет; Независимость от конкретной реализации — Нет; Длина тестов растет; Подготовка к тестам растет; Усложненные тестовые двойники — да; Поддержка ДИК — Да;

Есть подробное объяснение.

SRP — это означает, что у класса должна быть только одна обязанность. Если учесть, что репозиторий — это просто класс для возврата данных из базы данных и более того, он просто извлекает данные, то его можно рассматривать как SRP. НО SRP также означает только одну причину для изменения — я хочу изменить эту выборку и в следующий раз я хочу изменить другую выборку. Это не СРП.

OCP — это означает, что если мы хотим добавить какую-то новую функцию, мы не должны копаться в текущем классе. Это может сломать наши тесты и другие объекты, которые зависят от объекта. Вместо этого мы должны представить другой объект с новыми возможностями. Опять же, в случае FSR (Facade Service Repository) это не более чем концепция без использования.

ISP — у нас должен быть какой-то интерфейс, и интерфейс должен быть как можно меньше. Интерфейсы невозможны в FSR, потому что было бы слишком много изменений. Более того, интерфейс не может быть маленьким, потому что нам нужны все эти методы findBySheet.

Высокая связность — см. SRP

Низкая связанность — это означает, что классы не должны слишком сильно зависеть от других частей. Мы можем реализовать интерфейс, и у нас все в порядке, но в случае с FSR это невозможно, потому что наши интерфейсы со временем будут меняться. Это перебор.

Полиморфизм — такой замечательной концепцией злоупотребляет FSR. Есть только один огромный класс, содержащий множество методов, так где же полиморфизм — сила всех ОО-языков. Поэтому количество методов все еще растет, а количество классов остается прежним. Со всеми этими методами и такой большой областью действия нам приходится заботиться о дублирующихся методах, поэтому мы используем составные имена — например, findProjectById, findProjectByName или хуже. Это не кажется хорошей идеей.

Защитный подход. Мы хотим доверять каждой строке кода, но не хотим иметь классы с тысячей строк кода. Жаль, вам лучше использовать полиморфизм.

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

Независимо от конкретной реализации. Если я внедрил какой-то объект в другой класс и внезапно получил возможность использовать все эти 20 методов, которые вы мне предлагаете, что мне делать? Такой беспорядок, что я должен использовать? Что достаточно хорошо для меня? Я не знаю.

Тесты. В соответствии с растущими методами внутри класса я буду добавлять, добавлять и добавлять новые наборы тестов и новые препараты в свой тестовый класс. Теперь в моем тестовом классе 2 тысячи строк кода, и я забыл, что на самом деле тестирую. Наигранных ожиданий, приготовлений и частных методик больше, чем тестов! Сервисы и фасады обычно могут иметь до 20 параметров в конструкторах. Вы можете себе представить издевательство над всем этим? И нет, вы не можете использовать подделки, потому что у них нет интерфейса, и, как мы знаем, наследование — это просто плохая идея.

DIC — поддержка DIC есть, и это, пожалуй, единственное преимущество для процедурных программистов.

Резюме

Фасады, сервисы и репозитории — это процедурный подход к не объектно-ориентированным языкам. Избегайте их, и вы станете гораздо лучшим программистом.