Interfaces are the starting point for designing any service oriented architecture – whether they be externally facing web services or internally facing local services. Hence, the correct design of interfaces is an important step in achieving scalability down the road. Too often, when we see an interface class, it looks something like this (an example interface for an Account Service)….

interface IAccountServiceLargeInterface
  {
      // These are actions carried out by the user (account holder)
       void CreateAccount();
       void UpdateAccount();
       void DeleteAccount();
      //.....

      // These are actions carried out by the bank
       void BackupAccount();
       void InternalAuditAccount();
      //.....
  }

The Problem

The problem with this interface is that it has methods belonging to two different aspects of an account. The first three actions are those that an end user (Account Holder) would need to perform on the Account object. The next two are actions performed by the bank for internal bookkeeping. There is a clear distinction between these two aspects of an Account. Consider what happens if we leave these combined in the form shown above.  An ‘Account Management’ Application used internally by the bank  – and a ‘Web Based User Banking Application’ (which allows the creation, deletion etc. of Accounts), BOTH need to implement this common interface. When they have nothing (no functionality) in common.   This may seem trivial but it leads to maintainability problems down the road.

The Solution

An appropriate way of dealing with this is to simply break this interface up into two separate interfaces (one that captures all the user actions – and one that captures all the bank actions)

interface IAccountServiceUserActions
 {
     // These are actions carried out by the user (account holder)
     void CreateAccount();
     void UpdateAccount();
     void DeleteAccount();
 }
interface IAccountServiceBankActions
  {
      // These are actions carried out by the bank
      void BackupAccount();
      void InternalAuditAccount();
  }

Summary

A typical symptom of a poorly designed interface is the number of methods it contains. In general, if it has a dozen or so methods, chances are there are several different aspects rolled into one interface. It is an ideal candidate for refactoring. This helps avoid code maintainability issues down the road – and provides a better architecture for building multiple applications around the same domain object (Account class in our example above).

Anuj holds professional certifications in Google Cloud, AWS as well as certifications in Docker and App Performance Tools such as New Relic. He specializes in Cloud Security, Data Encryption and Container Technologies.

Initial Consultation

Anuj Varma – who has written posts on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

 Twitter Linkedin