Как спроектировать класс Validator в отношении SRP?
Лучше ли иметь класс валидатора, который имеет методы, такие как validateUrl (), validateEmail (), validateInt () и т. Д.?
Или класс URLValidator, класс EmailValidator и класс INTValidator?
Решение
Хотя я согласен с тем, что это прежде всего основано на мнении, я думаю, что у вас должен быть один класс на валидатор. В противном случае, какова единственная ответственность вашего класса? Чтобы сделать все проверки? Как и предполагалось, вы могли бы начать с Validator это сделало все и позже перешло к отдельным классам, иначе ваш валидатор мог быть просто фасадом для всей валидации с определенной валидацией в отдельных классах.
Что касается статического вопроса, это, вероятно, будет зависеть от того, нужно ли вам заглушить эти валидаторы в ваших тестах. В этом случае их статичность будет болью.
Другие решения
Я думаю, что было бы лучше разделить общую логику проверки (Validator класс) и конкретная логика проверки (ValidationRule класс и его потомки). Это тот случай, в рамках Symfony.
Способ встраивания наиболее активно используемых правил проверки в Validator класс используется в фреймворке Laravel, но он мне действительно не нравится, потому что он нарушает SRP и делает Validator класс раздутый с несвязанной логикой.