Противоречит ли реализация нескольких интерфейсов одним классом принципам SOLID

#шаблоны_проектирования #интерфейс #solid

Вопрос немного философский. Для начала 1 и 4 принципы SOLID из wiki:


  Существует лишь одна причина, приводящая к изменению класса.


и


  Много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс
общего назначения.


Иначе говоря - один класс должен выполнять свою узко-направленную задачу и никакие
другие.  Тоже и интерфейс - лучше разделять один общий интерфейс(аналог класса "помойки")
на составные, содержащие обьявления полей и методов необходимых для выполнения своей
конкретной задачи, причем только одной. Из 1+4 принципов можно сделать вывод, что один
класс должен реализовывать 1 интерфейс что бы не противоречить 1 принципу. Если же
1 класс реализует несколько интерфейсов, то следовательно обязан реализовать выполнение
нескольких задач что никак не вяжется с 1 принципом. 

Есть ли здесь противоречие, или я неправильно понял эти принципы (если да, то прошу
обьяснить где именно)? 
    

Ответы

Ответ 1

Если же 1 класс реализует несколько интерфейсов, то следовательно
  обязан реализовать выполнение нескольких задач что никак не вяжется с
  1 принципом


Считаю, это не следует воспринимать с фанатизмом.

Во-первых, как сказал @АлексейШиманский, Если у интерфейса задача "чтение", то он
и должен "читать". А у класса задача - работа с json строками, например.

Во-вторых, классы, которые взаимозависимы друг от друга, не могут быть разделены
по одной простой причине, что вы не сможете внедрить один в другой и наоборот одновременно.
Пример:

Есть интерфейсы:

public interface IAuthInfo
{
    bool IsAuthorized { get; }

    IUser CurrentUser { get; }
}

public interface IAuthorizer
{
    Task LogUserInAsync(string email, SecureString password);
}


И их реализация:

public class AuthService : IAuthorizer, IAuthInfo
{
    public bool IsAuthorized => CurrentUser != null;

    public IUser CurrentUser { get; private set; }


    public async Task LogUserInAsync(string email, SecureString password)
    {
        // some actions to set CurrentUser property
    }
}


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