Приводит ли SRP по принципу SOLID к коду лазаньи?
С принципом SOLID, особенно SRP, у нас очень много классов.
Я имею в виду, это так же, как вы хотите создать класс базы данных
Тогда у вас есть
Класс DatabaseHandler, который обрабатывает базу данных (выбрать, вставить, обновить, удалить и т. Д.),
Класс DatabaseAdapter, который является расширенным классом PDO (может устанавливать предпочтительный режим по умолчанию при создании, новый метод подготовки, который напрямую подготавливает оператор, связывает его с параметром и выполняет его,
Класс QueryBuilder, который является родителем класса SelectStatementBuilder, класса InsertStatementBuilder, класса DeleteStatementBuilder, класса UpdateStatementBuilder (для построения SQLStatement),
Класс выражения, который создает выражение, необходимое в предложении WHERE
Класс SQLStatement (который действует как обычная строка, но его интерфейс — SQLStatementInterface, поэтому мы можем знать, что это оператор SQL и т. Д.).
И я знаю, что будет больше классов, если я буду копать глубже, и снова проведу рефакторинг.
Приводит ли реализация принципа SRP к коду лазаньи?
Код лазаньи в порядке?
Решение
В целом, SRP — это принцип проектирования, который требует от вас продумать различные обязанности (причины изменения AKA) вашей системы. Его цель — помочь улучшить целостность вашей системы. Другими словами, вещи, которые меняются вместе, оставайтесь вместе.
У класса должна быть только одна причина для изменения.
В случае неправильного уровня детализации SRP можно интерпретировать как класс, который должен выполнять только одну очень маленькую вещь низкого уровня, что приводит к чрезмерной абстракции без явных преимуществ. Прочитав его статью, вы заметите, что «причина для изменения» определяется на уровне требований пользователя / клиента / потребителя. Упрощенный пример состоит в том, что если изменение в моем требовании к пользовательскому интерфейсу побуждает меня изменить класс, содержащий некоторые коды уровня доступа к данным, то у этого класса есть несколько причин для изменения (т. Е. Пользовательский интерфейс и доступ к данным), которые нарушают SRP.
В вашем случае, если вы не создаете инструмент управления базой данных, нет причин разбивать исходный класс базы данных на эти более мелкие классы. Если это типичное (веб) приложение, то если вы хотите изменить базовую реализацию базы данных (скажем, с MySQL на базу данных в памяти во время тестирования), то все эти классы должны быть заменены в любом случае. Может быть, просто будь проще.
Другие решения
Других решений пока нет …