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