Справка Создание интерфейса

Question

Я начинаю видеть значение интерфейсов vs. позволяет говорить абстрактным классом.

В настоящее время я работаю над проектом PayPal Wrapper. Вероятно, мы также будем делать обложку Google Payments, BillMeLater и Amazon. Мне было предложено определить некоторые общие черты (методы, свойства и т. Д.), Которые мы могли бы использовать по всем направлениям, в большинстве проектов веб-службы 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 и в этом интерфейсе добавить эти 2 свойства. Тогда любая оболочка класса, которую я создаю, которая имеет функциональность для создания запросов API-прокси, может реализовать этот интерфейс, и тогда я знаю, что любой из этих классов оболочек в любом из наших проектов веб-сервисов будет гарантированно иметь такие свойства в них, которые будут быть уничтожены и заполнены любыми ошибками, которые возвращаются из ответа API.

И если это так, то это здорово, потому что я могу начать создавать вспомогательные методы, которые мы можем использовать по всем направлениям, если я могу как-то взять общий объект ответа и заполнить массив ошибок и установить свойство.

В любом случае, моя проблема в том, что я новичок в интерфейсах litte. Таким образом, свойство массива ошибок сверху, например, имеет собственный тип.

Ну, если я создаю интерфейс в отдельном физическом проекте, я не могу использовать этот настраиваемый тип, потому что он не существует ... он существует только в моем проекте-оболочке 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

Каждая проблема в программном обеспечении может быть решена с помощью другого слоя без указания направления !!! Просто добавьте еще один интерфейс под названием IAPIError, который вы реализуете для каждого типа ошибки оплаты.

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

Answer 2

Вы можете поместить ваши общие типы в отдельной общей сборки: [MyCompany] .WebServices.Shared

Редактировать
Давай думать об этом, у вас уже есть что. [MyCompany] .WebServices.Common должен быть таким же хорошим местом, как и для ваших общих типов. Просто переместите его туда. Или я не понимаю, что вы хотите сделать?

Answer 3

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

Я бы добавил еще одну абстракцию, указав ожидаемые ошибки (одна из которых является «неизвестной ошибкой» как обломок для неожиданных ошибок) как отдельный класс или даже как набор исключений. Затем, каждый провайдер возвращает или использует те, которые уже совместимы с вашим приложением и позволяют обрабатывать распространенные ошибки для всех провайдеров одинаково.

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

Answer 4

Вы должны учитывать, что ApiErrors будут зависеть от конкретной реализации веб-сервиса. Итак, как клиент, который использует только интерфейсы, будет использовать ApiErrors, если они специфичны для реализации?

Этого не может быть - потому что это будет означать, что оно связано с этой конкретной реализацией.

Вместо этого вам необходимо отвлечься от конкретных кодов ошибок API и определить свои собственные коды ошибок.