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接口。

接口实现 - 为参数创建接口

2 个答案: