Interface Segregation Principle with Example

Overview of Interface Segregation Principle

It states avoid tying a client class to a big interface if only a subset of this interface is really needed. Many times you see an interface which has lots of methods. This is a bad design choice since probably a class implementing. . This can make it harder to understand the purpose of a component, but it can also cause increase coupling, where by components that make use of such a component are exposed to more of that components capabilities that are appropriate.

The Interface Segregation Principle (or ISP) aims to tackle this problem by breaking a components interface into functionally separate sub-interfaces. Although a component may still end up with the same set of public members, those members will be separated into separate interfaces such that a calling component can operate on the component by referring only to the interface that concerns the calling component.

Intenet

Clients should not be forced to depend upon interfaces that they don't use.

Example

Below are the example which violates the rules of Interface segregation Principle. Suppose Our modules is having two different modules Customers and Product. Then in below example IDbService is a Generic Interface which you can pass any type of class like. Customer, Product etc as T and Tkey defines your Identification Key. It might be long, int or double as per the requirement.But if we declare it within one Interface then GetCustomersByDeptID() method is not useful for Product class. So here we rae violates the rules of Interface Segregation Principle.


		
			
			public interface IDbService<T, 
			TKey> where T 
			: IEntity
		
			
			{
		
			
			    IList<T> GetAll();
		
			
			    T GetById(TKey key);
		
			
			    bool Update(T 
			entity, TKey key);
		
			
			    int Add(T 
			entity);

			 IList<Customer> 
			GetCustomersByDeptID(int departmentId);

			

 
		
			
			}

We can segregate the Interface to make it useful for both the Modules.

Code


			
				
				public interface IDbService<T, 
				TKey> where T 
				: IEntity
			
				
				{
			
				
				    IList<T> 
				GetAll();
			
				
				    T GetById(TKey key);
			
				
				    bool Update(T 
				entity, TKey key);
			
				
				    int Add(T 
				entity); 
			
				
				}

				

 
					
					public interface ICustomerService : IDbService<Customer, int>
				
				
					{

				
					    IList<Customer> 
					GetCustomersByDeptID(int departmentId);
				
					}

Code

ICustomerService which implements IDbService having extend functionality GetCustomersByDeptID() Which is only for Customer not for Product.

Conclusion

If the design is already done fat interfaces can be segregated using the Adapter pattern.

Like every principle Interface Segregation Principle is one principle which require additional time and effort spent to apply it during the design time and increase the complexity of code.

But it produce a flexible design. If we are going to apply it more than is necessary it will result a code containing a lot of interfaces with single methods, so applying should be done based on experience and common sense in identifying the areas where extension of code are more likely to happens in the future.