-
Notifications
You must be signed in to change notification settings - Fork 0
Interface Segregation Principle
Subrata Sahoo edited this page Jul 20, 2024
·
2 revisions
A client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use.
This principle aims to create more granular and specific interfaces so that classes implementing these interfaces only need to be concerned with the methods that are relevant to them.
- Reduce Complexity: Breaking down large interfaces into smaller, more specific ones, each implementing class only has to deal with the methods it actually needs. This reduces the complexity of the class and makes it easier to understand and implement.
- Increase Flexibility and Maintainability: Smaller interfaces are easier to manage and extend. A new method can be added to the relevant interface without affecting other interfaces and their implementations.
- Enhance Reusability: Classes that implement smaller interfaces are more likely to be reusable in different contexts because they aren't burdened with unnecessary methods.
- Simplify Testing: Each interface can be tested independently, ensuring that each piece of functionality works as expected.
- Promote Decoupling: Smaller interfaces help decouple the system's components, making it easier to replace or modify parts of the system without impacting other components.
| Problem | Description | Solution |
|---|---|---|
| Over-Segmentation | Excessive adherence to ISP can lead to an overly fragmented set of interfaces, where each interface has only one or a few methods. This can make the system harder to understand and manage due to the large number of interfaces. | Balance the granularity of interfaces. Ensure that they are not so fragmented that it becomes cumbersome to manage or understand their interactions. |
| Increased Complexity | With a large number of small interfaces, the complexity of managing dependencies and understanding how different components interact can increase. | Group related interfaces together and use well-defined naming conventions to keep the design manageable and comprehensible. |
| Duplication of Interfaces | Sometimes, smaller interfaces may lead to duplication of similar methods across different interfaces. This can create redundancy and increase maintenance efforts. | Refactor interfaces to avoid duplication. Look for common functionality that can be abstracted into shared interfaces or base interfaces where appropriate. |
| Increased Learning Curve | New developers or team members may face a steeper learning curve when dealing with many small interfaces, especially if the interfaces are not well-documented or intuitively designed. | Provide clear documentation and onboarding for new team members. Use descriptive names for interfaces and methods to make their purpose and usage clear. |
| Difficulty in Extending Interfaces | Adding new methods to an existing interface without violating ISP can be challenging. If the new methods do not align with the existing responsibilities, it may necessitate creating additional interfaces. | Carefully design interfaces with future extensions in mind. Consider the impact of adding new functionality and whether it requires creating new interfaces or can be integrated into existing ones. |
| Maintenance Overhead | Managing a large number of interfaces can introduce overhead in terms of maintaining and evolving the codebase. Changes to one interface might require updates to multiple implementations. | Implement changes incrementally and use automated tools to assist with managing and refactoring interfaces. Ensure that interface changes are well-communicated and tested. |
| Integration Challenges | Integrating components that depend on numerous small interfaces can be challenging, especially if those interfaces are used in various parts of the system. | Use dependency injection and well-defined service boundaries to manage integrations. Ensure that components are designed to work cohesively with the defined interfaces. |
| Potential Over-Design | Applying ISP can sometimes lead to over-design, where the effort to create and manage multiple interfaces outweighs the benefits. | Apply ISP pragmatically. Assess whether the benefits of interface segregation justify the effort and complexity involved. |
In this example, the Square class is forced to implement the GetVolume method, which it does not need. This violates the Interface Segregation Principle.
To adhere to the Interface Segregation Principle, we can create more specific interfaces. In the improved example:
- ITwoDimensionShape interface includes the GetArea method
- IThreeDimensionShape interface includes the GetVolume method.
- Cube class implements both ITwoDimensionShape and IThreeDimensionShape interfaces because it can have both area and volume.
- Square class implements only the ITwoDimensionShape interface because it can only have area and not volume.
This way, the Square class is not forced to implement the GetVolume method, adhering to the Interface Segregation Principle.