Что делать с методами интерфейса, которые не нужны в конкретной реализации?

Question

Есть интерфейс, который я имплементирую для реализаций:

interface ICrmClientsRepository
{
    public function create(CreateClientDTO $createClientDTO);
    public function updateById(
        string $id,
        UpdateClientDTO $updateClientDTO
    );
    public function getById(
        string $id
    );

    public function getList($page = 1,$perPage = 50);

    public function getListByCreatedRange($startDate, $endDate);

}

В 1 иплментации репозитория мне нужен только getList(), но не нужна реализация getListByCreatedRange(), ибо в 1 CRM берем только page записи. Во 2 наоборот берем только дате, ибо там нет page и т.д. Что мне делать в этом случае? Универсального метода для этих 2 нет, так как там разные методы, а оставлять нереализованные методы интерфейса - это такое себе.

Answer 1

На эту тему есть однин из принципов SOLID - ISP

Программные сущности не должны зависеть от методов, которые они не используют.

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

Таким образом, резюмирую: не делайте универсальные интерфейсы, делайте узко специализированные. Да, получатся интерфейсы на 1-2 метода, но вы сможете их комбинировать как вам нужно, наследуя класс только от нужных вам интерфейсов.

Хотя на крайний случай конечно можно реализовывать не нужные методы универсального интерфейса затычками по типу NotImplementedException (это исключение в C#, не знаю, есть и такое же в PHP). Но это не есть хорошо, это нарушение принципа разделения интерфейсов.

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

БЛОГ НА HUSL

Что делать с методами интерфейса, которые не нужны в конкретной реализации?

Ответы (1 шт):