Interface Segregation
It states that interfaces should be small and At their
simplest, interfaces contain single methods that serve a single purpose.
The reasons for
segregating (splitting ) large interface into smaller interfaces :
- Self-documentation for other developers to follow
- Decorating interfaces : we may have to decorate implementations using decorate pattern/adapter pattern in the cases where cross-cutting concerns such as logging transaction management ,caching are required
- Architectural Need :The interfaces are segregated based on the architectural need e.g. the Data access technology is different for the same data
- Client Need :When a set of certain set of operation is only available to a certain clients, the large interfaces are segregated into smaller interface
- Client A is having requirement to get read only a particular data from service and Client B is to get write only to the same data
- A set of certain set of operation is only available to a certain clients when the application is in specific state For example, the operations that a user can perform are typically different depending on whether that user is logged in or not.
Client construction :
Client can construct segregated interfaces in 2 ways as below.
- Single implementation, single instance : all of the segregated interfaces are implemented in a single class, a single instance is sufficient for all of the related dependencies on the client.
- Multiple implementations, multiple instances : If each segregated interface is given its own implementation, each of those implementations needs to be constructed and supplied to the client.
The Interface Soup
anti-pattern :
A common mistake is to take the segregated interfaces and
reunify them in an aggregate as below.
In the above fig, the segregated interfaces are reunified in
a single interface forming “interface soup”, resulting in providing implementations of all operations and so there is
no scope for targeted decoration
No comments:
Post a Comment