Tuesday, December 07, 2010 #

The Interface Segregation Principle (ISP)

The Interface Segregation Principle (ISP) is another principle about OOD.

It simply states that:

“CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES
THAT THEY DON’T USE”

If we return back to the first OOD principle, the Single Responsibility Principle, it can be said that this principle should also apply to interfaces or to abstract class, in addition to the concrete classes.

Therefore, one interface should mean one responsibility, without creating the so-called “fat interfaces”, i.e. interfaces that contain too many methods/properties that relate to more than 1 responsibility.

To find an example of violation of this principle does not need to go too far, just peek inside the .Net framework itself smile_regular.

If we take a look inside the abstract class MembershipProvider, which is the class which all providers, default and custom,  inherit from, we’ll be looking at 28 abstract methods, which must be provide an implementation in case of creation of custom membership provider.

   1: public abstract void Initialize(string name, 
   2:     NameValueCollection config)
   3: public abstract string ApplicationName { get; set; } 
   4: public abstract bool EnablePasswordReset { get; }
   5: public abstract bool EnablePasswordRetrieval { get; } 
   6: public abstract bool RequiresQuestionAndAnswer { get; } 
   7: public abstract bool RequiresUniqueEmail { get; } 
   8: public abstract int MaxInvalidPasswordAttempts { get; } 
   9: public abstract int PasswordAttemptWindow { get; } 
  10: public abstract MembershipPasswordFormat PasswordFormat { get; }
  11: public abstract int MinRequiredNonAlphanumericCharacters { get; }
  12: public abstract int MinRequiredPasswordLength { get; }
  13: public abstract string PasswordStrengthRegularExpression { get; }
  14: public abstract bool ChangePassword(string username, 
  15:     string oldPwd, string newPwd)
  16: public abstract bool ChangePasswordQuestionAndAnswer(
  17:     string username, string password, string newPwdQuestion, 
  18:     string newPwdAnswer)
  19: public abstract MembershipUser CreateUser(string username, 
  20:     string password, string email, string passwordQuestion, 
  21:     string passwordAnswer, bool isApproved, object      
  22:     providerUserKey, out MembershipCreateStatus status)
  23: public abstract bool DeleteUser(string username, 
  24:     bool deleteAllRelatedData)
  25: public abstract MembershipUserCollection GetAllUsers(int pageIndex, 
  26:     int pageSize, out int totalRecords)
  27: public abstract int GetNumberOfUsersOnline()
  28: public abstract string GetPassword(string username, string answer)
  29: public abstract MembershipUser GetUser(string username, 
  30:     bool userIsOnline)
  31: public abstract MembershipUser GetUser(object providerUserKey, 
  32:     bool userIsOnline)
  33: public abstract bool UnlockUser(string username)
  34: public abstract string GetUserNameByEmail(string email)
  35: public abstract string ResetPassword(string username, 
  36:     string answer) 
  37: public abstract void UpdateUser(MembershipUser user)
  38: public abstract bool ValidateUser(string username, 
  39:     string password)
  40: public abstract MembershipUserCollection FindUsersByName(
  41:     string usernameToMatch, int pageIndex, int pageSize, 
  42:     out int totalRecords)
  43: public abstract MembershipUserCollection FindUsersByEmail(
  44:     string emailToMatch, int pageIndex, int pageSize, 
  45:     out int totalRecords)
  46:  
  47: 

This methods has to do with authentication, persistence, retrieve of user based on various criteria, password management, and so on.

All these abstract methods must be implemented even if the client code that uses the feature is only interested in some of these aspects mentioned above.

In this way, the methods that you do not care end up being defined as follows:

   1: public override int GetNumberOfUsersOnline()
   2: {
   3:     throw new NotImplementedException();
   4: }

This approach has several problems, including:

  • Indirect and especially useless  coupling between clients that use the functionality. If additional functionality is required, all clients must be modified, even those not interested in new features;
  • Clients are misled because some methods explicitly raise an exception;
  • Code maintenance is more difficult;

posted @ Tuesday, December 07, 2010 3:38 PM | Feedback (0)