Refactoring Interfaces– separating concerns

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).

Specializing in high volume web and cloud application architecture, Anuj Varma’s customer base includes Fortune 100 companies (dell.com, British Petroleum, Schlumberger).
Anuj’s training as a mathematical physicist followed by years of advanced computer programming is unique in the industry.

For Anuj’s popular technology seminars and science and scientific computing seminars, please visit ANUJ.COM

For Anuj’s Mathematical Models and Math Modeling related consulting , please visit anuj.com.

All content on this site is original and owned by AdverSite Web Holdings, Inc. – the parent company of anujvarma.com. No part of it may be reproduced without EXPLICIT consent from the owner of the content.

Anuj Varma – who has written posts on Anuj Varma, Technology Architect.


Leave a Reply

Your email address will not be published. Required fields are marked *