#Interface segregation code#

Since I cannot think of another real world example, let’s look at a completely bogus example. I’m not going to go into the details of splitting this up, but I think you get the idea. A better approach would have been to break it up into smaller interfaces that allow the implementers to only worry about the parts that they need. This interface is extremely fat and not cohesive. It turns out that you don’t have to implement the parts you don’t need, but this clearly violates the Interface Segregation Principle. Hopefully you didn’t get tired of scrolling through that and you’re still with me.

#Interface segregation code#

Sorry for the code puke there, but wanted you to feel a little pain as I did trying to actually implement this thing. Public override bool ValidateUser( string username, string password) Public override void UpdateUser(MembershipUser user) Public override bool UnlockUser( string userName) Public override string ResetPassword( string username, string answer) Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one submodule. The Interface Segregation Principle states that clients should not be forced to implement interfaces they dont use. Public override bool DeleteUser( string username, bool deleteAllRelatedData) Having an interface pollution is not a good solution and might induce inappropriate behavior in the system. Instead, interfaces should be broken down into smaller, more specific interfaces to prevent clients from being dependent on methods that are irrelevant to their needs. Martin, states that clients should not be forced to implement interfaces they do not use.

String passwordQuestion, string passwordAnswer, bool isApproved, object providerUserKey, The Interface Segregation Principle, introduced by Robert C. Public override MembershipUser CreateUser( string username, string password, string email,

String newPasswordQuestion, string newPasswordAnswer) Public override bool ChangePasswordQuestionAndAnswer( string username, string password, Public override bool ChangePassword( string username, string oldPassword, string newPassword) Throw new Exception( 'The method or operation is not implemented.') Public class CustomMembershipProvider : MembershipProvider In order to implement your own Membership Provider you “simply” implement the abstract class MembershipProvider like so: For me, it ended up being a lot more trouble than it was worth, but it turns out to be a good example of a fat interface. The Membership Provider was a way to integrate with some of the ASP.NET’s built in management of users and its associated server controls. I had completely blocked that monstrosity out of my mind (for good reason). I was having trouble thinking of a real world example for ISP but then was reminded about implementing a custom Membership Provider in ASP.NET 2.0.

In other words, if you have an abstract class or an interface, then the implementers should not be forced to implement parts that they don’t care about. As Chad pointed out with LSP, the ISP is also one of Robert ‘Uncle Bob’ Martin’s S.O.L.I.D design principles.īasically ISP tells us that clients shouldn’t be forced to implement interfaces they don’t use. In following suite with the The Los Techies Pablo’s Topic of the Month – March: SOLID Principles, I chose to write a little about the The Interface Segregation Principle (ISP). PTOM: The Interface Segregation Principle 15 March, 2008.