Question

I’m starting to see the value of Interfaces vs. lets say an Abstract class.

Currently I’m working on a PayPal Wrapper project. We’ll also be probably doing a Google Payments, BillMeLater, and Amazon wrapper. I’ve been asked to identify some commonalities (methods, properties, whatever) that we could use across the board, in most any Web Service SOAP Wsdl Wrapper project for any web services we do.

So as I was coding out my PayPal wrappers, I created a new class to hold Errors received back from any PayPal response:

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

}

Anyway, I said hey, these ErrorMessage and ErrorCode properties are most likely going to be in every third party API. So why not create an Interface in a new project called [MyCompany].WebServices.Common and in that interface add those 2 properties. Then any class wrapper that I create that has functionality to make API proxy calls can implement this interface and then I know any of those kinds of wrapper classes in any of our web service projects will be guaranteed to have these kind of properties in them that will be impolemented and filled with any errors that come back from an API response.

And if they do, then that’s great because I can then start to create some helper methods that we can use across the board if I can somehow take in a generic response object and fill the array of errors and set the property.

Anyway, my problem is, I’m new to interfaces a litte. So the error array property from above for example is of a custom type.

Well if I create interface in a seperate physical project, I can’t use that custom type because it doesn’t exist..it only exists so far in my PayPal wrapper project.

So then when stubbing this interface out, how would I handle this?

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

Every Problem in Software can be Solved with Another Layer of Indirection!!! Just add another interface called IAPIError that you implement for each pay service error type.

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