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.
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
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
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
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.