SOLID Principles Part 2
•Als PPTX, PDF herunterladen•
1 gefällt mir•485 views
This document discusses the SOLID principles of Liskov Substitution Principle (LSP) and Interface Segregation Principle (ISP). LSP requires that subtypes be substitutable for their base types without altering behavior. ISP states that client classes should not be forced to depend on interfaces they do not use. The document provides examples of how to identify violations of these principles and offers resolutions such as splitting interfaces into smaller cohesive groups.
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie SOLID Principles Part 2
Ähnlich wie SOLID Principles Part 2 (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
SOLID Principles Part 2
- 1. SOLID Principles - II LSP – Liskov Substitution Principle ISP – Interface Segregation Principle Maulik Soni
- 2. Liskov Substitution Principle Subtypes must be substitutable for their base types. Maulik Soni
- 3. Is LSP Violated Here ? Maulik Soni
- 4. How To Spot LSP Violation ? Derivative that tries to do less than base class Instance of checks Hiding or stubbing parent methods Void SomeMethod(){} Void SomeMethod(){ Throw new ShouldNotBecalledException(“…”);} Polymorphic if Statements Maulik Soni
- 6. Interface Segregation Principle Client should not be forced to depend on methods they do not use Maulik Soni
- 7. Why ISP Important ? Each member of an interface needs to be implemented in its entirety Properties Events Methods Unless every client of an interface requires every member It does not make sense to force client to implement such a large contract Maulik Soni
- 9. Is ISP Violated Here? Maulik Soni
- 11. Re-Visit the solution Maulik Soni Software IPrint IScan IFax IPrint IScan IFax IPrint IScan IStaple
- 12. Summary Design cohesive interfaces and avoid “fat” interfaces The dependency of one class to another should depend on the smallest possible interface The interface of the class can be broken up into groups of methods Each group serves a different set of clients Check Classes with a high number of Public methods Group clients according to their calls to the public methods Check for methods that frequently change together Maulik Soni
- 13. End of Presentation Maulik Soni
Hinweis der Redaktion
- Barbara Liskov wrote this principle in 1988.
- Task : Base class Research Task - you can close the task even if it’s started Project : Task Derived class
- The Interface is a key tool in the modern object-oriented programmers’ toolkit. Interface represent the boundaries between what client code requires and how that requirement is implemented. The ISP states that interfaces should be small.
- The design problem was that a single Job class was used by almost all of the tasks. Whenever a print job or a stapling job needed to be performed, a call was made to the Job class. This resulted in a 'fat' class with multitudes of methods specific to a variety of different clients. Because of this design, a staple job would know about all the methods of the print job, even though there was no use for them.
- The solution suggested by Martin utilized what is called the Interface Segregation Principle today. Applied to the Xerox software, an interface layer between the Job class and its clients was added using the Dependency Inversion Principle. Instead of having one large Job class, a Staple Job interface or a Print Job interface was created that would be used by the Staple or Print classes, respectively, calling methods of the Job class. Therefore, one interface was created for each job type, which were all implemented by the Job class.