Question

我开始看到Interfaces vs.的价值让我们说一个抽象类。

目前我正在开发一个PayPal Wrapper项目。我们也可能会使用Google Payments，BillMeLater和Amazon包装器。我被要求确定一些我们可以全面使用的共性（方法，属性，等等），在我们所做的任何Web服务的大多数Web Service SOAP Wsdl Wrapper项目中。

因此，当我编写我的PayPal包装器时，我创建了一个新类来保存从任何PayPal响应中收到的错误：

public class ApiError
{

    #region Constructors

    /// <summary>
    /// Disallow default instantiation.
    /// </summary>
    private ApiError()
    {
    }

    internal ApiError(ErrorType error)
    {
        if(error.ErrorCode != null)
        {
            this._errorCode = error.ErrorCode;
        }
    }

    #endregion

    #region member variables

    private string _errorCode = string.Empty;
    private string _erorMessage = string.Empty;

    #endregion

    #region Properties

    public string ErrorCode
    {
        get { return _errorCode; }
        set { _errorCode = value; }
    }

    public string ErrorMessage
    {
        get { return _errorMessage; }
        set { _errorMessage = value; }
    }

    #endregion

}

无论如何，我说过，这些ErrorMessage和ErrorCode属性最有可能出现在每个第三方API中。那么为什么不在名为[MyCompany] .WebServices.Common的新项目中创建一个接口，并在该接口中添加这两个属性。然后，我创建的具有进行API代理调用功能的任何类包装器都可以实现此接口，然后我知道任何Web服务项目中的任何类型的包装类都将保证具有这些类型的属性。被充实并充满了从API响应中返回的任何错误。

如果他们这样做，那就太好了，因为我可以开始创建一些帮助方法，如果我能以某种方式接收一般的响应对象并填充错误数组并设置属性，我们就可以全面使用这些方法。 / p>

无论如何，我的问题是，我是新手接口。因此，例如上面的错误数组属性是自定义类型。

好吧，如果我在一个单独的物理项目中创建接口，我就不能使用那个自定义类型，因为它不存在..到目前为止只存在于我的PayPal包装器项目中。

那么当把这个界面打断时，我该如何处理呢？

namespace [MyCompany].WebServices.Common
{
    interface IRequest
    {

        public ApiError Type { get; set; } //whoops, that's a custom type that this project does not know about (ApiError)
    }

}

Answer 1

您应该考虑ApiErrors将取决于特定的Web服务实现。那么，如果它们是特定于实现的，那么仅使用接口的客户端将如何使用ApiErrors？

它不能 - 因为这意味着它与这个特定的实现相结合。

相反，您需要从特定的API错误代码中抽象出来，并定义自己的抽象错误代码。

Answer 2

软件中的每个问题都可以用另一层间接解决!!!只需为每个付费服务错误类型添加另一个名为IAPIError的接口。

interface IRequest
{
   public IApiError Type { get; set; } 
}

Answer 3

您可以将共享类型放在单独的共享程序集中：[MyCompany] .WebServices.Shared

修改
想想看，你已经有了。 [MyCompany] .WebServices.Common应该和你的共享类型一样好。把它移到那里。或者我误解了你想做什么？

Answer 4

确切的错误号和消息对每个提供商都非常具体。因此，虽然可以创建一个通用接口，但它不会提供足够的抽象来以有意义的方式处理错误。

我通过将预期的错误（其中一个是“未知错误”定义为意外错误的全部错误）作为单独的类或甚至是一组异常来添加另一个抽象。然后，让每个提供者返回或使用那些已经与您的应用程序兼容的提供者，并允许您以相同的方式处理所有提供者的常见错误。

将这些常见类型放入一个单独的程序集中，这是一个纯粹的“接口”程序集，供提供程序和使用它们的实际代码使用。因此，您将能够松散地耦合提供程序，而无需在主应用程序中添加对它们的引用（允许您在不重新编译应用程序的情况下添加或修改提供程序）。

帮助创建界面

4 个答案: