Приводит ли SRP по принципу SOLID к коду лазаньи?

С принципом SOLID, особенно с SRP, у нас очень много классов ..
Я имею в виду, это как если бы вы хотели создать класс базы данных.
Затем у вас есть класс DatabaseHandler, который обрабатывает базу данных (выберите, вставьте , обновить, удалить и т. д.),

Класс DatabaseAdapter, который является расширенным классом PDO (может устанавливать предпочтительный режим по умолчанию при построении, новый метод подготовки, который непосредственно подготавливает оператор, связывает его с параметром и выполняет it,

Класс QueryBuilder, который является родительским для класса SelectStatementBuilder, класса InsertStatementBuilder, класса DeleteStatementBuilder, класса UpdateStatementBuilder (для создания SQLStatement),

Класс Expression, который создает выражение, необходимое в предложении WHERE

Класс SQLStatement (который действует как обычная строка, но его интерфейс - это SQLStatementInterface, поэтому мы можем знать, что это оператор SQL и т. д.

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

Приводит ли реализация принципа SRP к коду лазаньи? Код лазаньи в порядке?


php oop solid-principles software-quality single-responsibility-principle
person Terry Djony    schedule 03.05.2015    source источник

Ответы (1)


arrow_upward
5
arrow_downward

В общем, SRP - это принцип проектирования, который требует от вас продумать различные обязанности (также известные как причины для изменения) вашей системы. Его цель - помочь улучшить целостность вашей системы. Другими словами, вещи, которые меняются вместе, остаются вместе.

Дядя Боб определил SRP как:

У класса должна быть только одна причина для изменения.

Если взять неправильный уровень детализации, SRP можно интерпретировать как класс, который должен выполнять только одну очень маленькую, низкоуровневую вещь, что приводит к чрезмерной абстракции без явных преимуществ. Прочитав его статью, вы заметите, что «причина изменений» определяется на уровне требований пользователя / клиента / потребителя. Упрощенный пример заключается в том, что если изменение в моем требовании к пользовательскому интерфейсу заставляет меня изменить класс, содержащий некоторые коды уровня доступа к данным, тогда у этого класса есть несколько причин для изменения (например, пользовательский интерфейс и доступ к данным), что нарушает SRP.

В вашем случае, если вы не создаете инструмент управления базой данных, нет причин разбивать исходный класс базы данных на множество более мелких классов. Если это типичное (веб-приложение), то если вы хотите изменить базовую реализацию базы данных (скажем, с MySQL на базу данных в памяти во время тестирования), тогда все эти классы все равно придется заменить. Можно просто сделать это проще.

person ivan.sim    schedule 03.05.2015