Specification виносить бізнес-правило в окремий об'єкт із методом перевірки, який каже, чи задовольняє об'єкт умову.
Яку проблему вирішує
Одні й ті самі умови ("повнолітній", "активний") повторюються по контролерах, сервісах і запитах у вигляді анонімних if. Їх важко перевикористати, назвати й протестувати окремо, а комбінувати - тим паче.
Як вирішує
Кожне правило стає класом-специфікацією з промовистою назвою (AdultUser, ActiveUser) і методом isSatisfiedBy(). Складні умови збираються з простих логічними операціями (AND/OR/NOT).
interface Specification
{
public function isSatisfiedBy(User $user): bool;
}
class AdultUser implements Specification
{
public function isSatisfiedBy(User $user): bool
{
return $user->age >= 18;
}
}
class ActiveUser implements Specification
{
public function isSatisfiedBy(User $user): bool
{
return $user->is_active === true;
}
}
$specs = [new AdultUser(), new ActiveUser()];
$allowed = array_reduce(
$specs,
fn ($ok, $spec) => $ok && $spec->isSatisfiedBy($user),
true
);
Де застосовувати
- Складні фільтри, пошук, бізнес-правила, що повторюються в різних місцях.
- Коли умови треба комбінувати й перевикористовувати як будівельні блоки.
Плюси та мінуси
- + Правила ізольовані, мають назву й тестуються окремо.
- + Комбінуються логічними операціями в складні умови.
- − Більше класів і непрямий код.
- − Для одноразової простої перевірки окремий клас - надмірність; вистачить звичайної умови чи scope-методу Eloquent.
