Интерфейс реализация - Создание интерфейса для параметров

Question

Это первая мысль, которую я получил во время чтения Interface Implementation (Interface Segregation Principle)

Мысль

Чтобы ввести новый интерфейс, представляющий бы параметры метода вместо передачи отдельных значений параметров. Как показано ниже:

interface IServiceProviderInput 
{ 
    string Username { get; } 
    string Password { get; } 
    string AgentId { get; } // XYZServiceProvider needs this. 
    // Similarly add props here to represent new parameters 
    // required by future service provider implementations. 
} 

interface IServiceProvider 
{ 
    bool Authenticate(IServiceProviderInput parameters); 
} 

class ABCServiceProvider : IServiceProvider 
{ 
    public bool Authenticate(IServiceProviderInput parameters) 
    { 
     return true; 
    } 
} 

class EFGServiceProvider : IServiceProvider 
{ 
    public bool Authenticate(IServiceProviderInput parameters) 
    { 
     return true; 
    } 
} 

class XYZServiceProvider : IServiceProvider 
{ 
    public bool Authenticate(IServiceProviderInput parameters) 
    { 
     return true; 
    } 
} 

Вопрос

бы это имеет смысл или каковы недостатки в этом? Есть предположения?

Редактировать

Еще одна мысль, чтобы добавить более конкретный интерфейс для поставщика XYZ:

interface IServiceProviderInput 
{ 
    string Username { get; } 
    string Password { get; } 
} 

interface IXYZServiceProviderInput : IServiceProviderInput 
{ 
    string AgentId { get; } 
} 

class XYZServiceProvider : IServiceProvider 
{ 
    public bool Authenticate(IXYZServiceProviderInput parameters) 
    { 
     return true; 
    } 
} 

Вполне возможно, что и мысли неправильны или есть недостатки, я не уверен, поэтому вопрос ,

Answer 1

Вы, конечно, могли бы это сделать, но если ВСЕ методы не принимали и не нуждались во всех параметрах, определяемых интерфейсом, это была ужасная идея. Никогда не передавайте больше информации методу, тогда НУЖНО, иначе вы не поймете, что нужно для работы, а что нет - от интерфейса.

Answer 2

Мой единственный вопрос с вашей реализацией - почему вы используете тот же метод аутентификации с XYZServiceProvider, но не используете интерфейс IServiceProvider, который вы определили?

Проблема с этим, когда у вас есть клиенты, которые вызывают IServiceProvder для аутентификации, они не смогут использовать XYZServiceProvider, но смогут использовать только два других. Если они хотят использовать XYZServiceProvider, им нужно будет указать его по имени (тесно связанное).

Если вы собираетесь вносить изменения в свою программу и переключаться с XYZServiceProvider на EFGServiceProvider для аутентификации, то индивидуальным клиентам также необходимо будет изменить их код, чтобы они могли использовать нового поставщика. Это особенно неприятно при попытке создания модульных тестов для ваших услуг, потому что вам придется индивидуально создавать тестовые приборы для XYZServiceProvider.

Если бы у вас был альтернативный вид обслуживания для XYZServiceProvider, я бы рекомендовал создать другой интерфейс, такой как IServiceProvider, который используется для других служб.