Interface Segregation Principle Definition Clients should not be forced to depend on methods they do not use Prefer small cohesive interfaces to fat interfaces ISP helps you resolve the problem with LSP violations ID: 774232
Download Presentation The PPT/PDF document "Interface Segregation" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Interface Segregation Principle
Definition Clients should not be forced to depend on methods they do not use . Prefer small, cohesive interfaces to “fat” interfaces. ISP helps you resolve the problem with LSP violations. www.seavus.com
Motivational poster
Motivational poster
Interfaces Why interfaces exist? Who owns the interfaces? Who defines the interfaces? Should we think about interfaces in terms of the concrete classes that implement those interfaces? www.seavus.com
Interfaces The purpose of the interfaces in the first place is to introduce loose coupling. It’s not really the concrete class that needs the interface – it’s the client that needs the interface. The client owns the interface! The client defines what it needs! www.seavus.com
Example 1
Problems www.seavus.com ReadOnlyStream needs to provide implementation of the write() method, even though it does not require them. This is a violation of the Interface Segregation Principle. Violation of the Interface Segregation Principle also leads to violation of the complementary Open Closed Principle . For example, consider that the Stream interface is modified to include a new method. As a result, you now need to modify all existing Stream implementation classes to include the new method even if they do not need it.
Following the Interface Segregation Principle
Example 2 www.seavus.com Both clients HAVE A CustomerTransaction object Both clients don’t required all of the methods from CustomerTransaction
Example 2 www.seavus.com
So, what’s the problem? www.seavus.com
Problems www.seavus.com Changes in the CustomerTransaction class could result in recompilation and redeployment of both of this dependent client modules. For example, if we update method: chargeCustomer ( String arg ) , TransactionReportGenerator will be forced to recompile and redeploy although it doesn’t use this method.
Solution www.seavus.com
Demo www.seavus.com
When to fix ISP www.seavus.com Once there is pain If there is no pain, there’s no problem to address If you find yourself depending on a “fat” interface you own Create a smaller interfaces with just what you need Have the fat interface implement your new interface Reference the new interface with your code If you find “fat” interfaces are problematic but you do not own them Create a smaller interface with just what you need Implement this interface using an Adapter that implements the full interface (adapter would be between you and the third party interface that you don’t have control over)
ISP tips www.seavus.com Keep interfaces small, cohesive and focused (refactor large interfaces so they inherit smaller interfaces) Whenever possible, let the client define the interface (don’t force client code to depend on things it doesn’t need)
Thank you for your attention Copyright: © 2019 Seavus . All rights reserved. | www.seavus.com | info@seavus.com | sales@seavus.com