Implementing an Interface on Client and Server Sides

Question

I have a client (Android app), and a server (WebApi REST web-service).

The app has a service layer it calls to communicate with the web-service for reading and writing records. Return values are sent back from the web-service's controllers (ie, when a new record is written to the DB and the associated record-id is generated).

I have many different controllers, each having multiple methods that all return a different number and type of values (they mostly return int array's, but occasionally I return an object array if there non-integer values mixed in).

The Service layer on the app side does a few checks to validate the parameters, such a checking the argument count (array elements) and checking for pre-defined invalid/uninitialized values (like -9999).

I wan't to formalize these parameter operations by defining an interface so that things like the count and type of the parameters used on both sides are explicitly specified in one location (so I'm not "winging it" on both sides).

However, the dilemma I'm running into is deciding on whether to define one interface that specifies both the client and server related methods, or to define two separate interfaces, each specifying methods specific that side of communication.

If I have a single interface, like so:

public interface IServiceParams
{
   object[] CreateParams(int recordId, string recordNumber);

   bool ParseParams(object[] paramz, out int recordId, out string recordNumber);
}

then since CreateParams is only used on the WS side, and ParseParams on the App side, I would have to declare empty implementations on either side

Web Service Side:

public class RecordController : ApiController, IServiceParams
{
   object[] IServiceParams.CreateParams(int recordId, string recordNumber)
   {
      return new[] { newRecordId, newRecordNumber };
   }

   bool IServiceParams.ParseParams(object[] paramz, out int recordId, out string recordNumber)
   {
      throw new NotImpementedException();
   }

   ////////////////////////////////////////////////////////////////////////////////////////////

   public object[] Put( Record record )
   {
      if( !DbLayer.Update(record) )
      {
         return null;
      }

      return CreateParams(record.RecordId, record.RecordNumber);
   }
}

App Side:

public class RecordService : IServiceParams
{
   object[] IServiceParams.CreateParams(int recordId, string recordNumber)
   {
      throw new NotImpementedException();
   }

   bool IServiceParams.ParseParams(object[] paramz, out string recordNumber)
   {
      if( paramz == null || paramz.Count != 4 )
      {
         return false;
      }

      if(!ParseInt(paramz[0].ToString(), out recordId) || recordIdNew == DEFAULT_RECORD_ID)
      {
         return false;
      }

      // ...

      return true;
   }

   ////////////////////////////////////////////////////////////////////////////////////////////

   public bool UpdateRecord( Record record )
   {
      object[] paramz = WebService.Put( record );

      int recordId; 
      string recordNumber;

      if(!ParseParams(paramz, out recordId, out recordNumber))
      { 
         return false;
      }

      record.RecordId = recordId;
      record.RecordNumber = recordNumber;

      return true;
   }
}    

---

Or, should I define two interfaces, and implement each on their respective sides, thus eliminating the need to have empty implementations:

public interface IServiceParamsClient
{
   bool ParseParams(object[] paramz, out int recordId, out string recordNumber );
}

public interface IServiceParamsServer
{
   object[] CreateParams(int recordId, string recordNumber);
}

Thanks a lot for the help!

Answer 1

Is there any reason you'd need both methods to be declared in one interface? If not, make two separate interfaces that each reflect their intent. Having to implement a method as "not supported" is a design smell. See: What's the right way to design my interface when I have operations that aren't supported by all implementers?

Answer 2

Go for two interface design. By doing so, you're doing yourself a favour with a cleaner API. The one suggestion is you can encapsulate the parameter logic in one class, so that now you have a stronger types statically checked which is not a small thing. Secondly I'm not sure if Web service coming to know of App client is a good thing. I think it should be the other way around. So here is how I would do it:

public class Param //at server side
{
   public int recordId { get; set; }
   public int transToPropId { get; set; }
   public int receivedViaTypeId { get; set; }
   public string recordNumber { get; set; }
}

public interface IParamParser //at client
{
   //I do not know what object[] paramz is; I leave that to you; 
   //may be it needs encapsulation as well
   bool Parse(object[] paramz, Param p);
}

public interface IParamCreator //at server
{
   Param CreateParams(int recordId, int transToPropId, int receivedViaTypeId, 
                      string recordNumber);
}