Session 33 More on SOLID Steve Chenoweth Office:
Description: Session 33 More on SOLID Steve Chenoweth Office: Moench Room F220 Phone: (812) 877-8974 Email: chenowetrose-hulman.edu Chandan Rupakheti Office: Moench Room F203 Phone: (812) 877-8390 Email: rupakhetrose-hulman.edu Today The SOLID coding
Related Topics
Download Presentation
"Session 33 More on SOLID Steve Chenoweth Office:" is the property of its rightful owner. Permission is granted to download and print the materials on this website 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.
Presentation Transcript
slide1. Session 33 More on SOLID Steve Chenoweth
Office: Moench Room F220
Phone: (812) 877-8974 Email: chenowet@rose-hulman.edu Chandan Rupakheti
Office: Moench Room F203
Phone: (812) 877-8390 Email: rupakhet@rose-hulman.edu<br>
slide2. Today The SOLID coding exercises
See course website for zip file of all 5 of these
They go with the quiz to turn in before class (as usual)
Bring along your answers to discuss in class, too 2<br>
slide3. Recall what SOLID is: S - SRP: Single Responsibility Principle
We discussed this one in Session 13
O - OCP: Open Closed Principle
L - LSP: Liskov Substitution Principle
I - ISP: Interface Segregation Principle
D - DIP: Dependency Inversion Principle
Pioneered by Robert Martin (Uncle Bob) 3<br>
slide4. Recall SRP THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE.
(You looked at Pablo’s eBook on this – see especially pp. 15-25) 4<br>
slide5. OCP SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) SHOULD BE OPEN FOR EXTENSION BUT CLOSED FOR MODIFICATION. 5<br>
slide6. LSP FUNCTIONS THAT USE REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT. 6<br>
slide7. ISP CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DO NOT USE . 7<br>
slide8. DIP A. HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS.
B. ABSTRACTIONS SHOULD NOT DEPEND UPON DETAILS. DETAILS SHOULD DEPEND UPON ABSTRACTIONS 8<br>
slide9. More Info Look at the SOLID article we saw before. There’s more in there beyond SRP!
The SRP part you already studied is thru p 26.
Then there’s an article on each of the other SOLID principles, too. 9<br>
slide10. Let’s Learn By Doing! 10 Download SolidExamples
(a zip file of 5 Java examples)
from the course website.
The quiz asks describe where there are issues, with which of the SOLID principles.
And – How you would fix them!
Do the quiz before class, as usual, but also be ready to discuss your answers in class.<br>
slide11. A “Solid” Summary SRP: THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE.
OCP: SOFTWARE ENTITIES SHOULD BE OPEN FOR EXTENSION BUT CLOSED FOR MODIFICATION
LSP: FUNCTIONS THAT USE REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT.
ISP: CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DO NOT USE .
DIP:
HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS.
ABSTRACTIONS SHOULD NOT DEPEND UPON DETAILS. DETAILS SHOULD DEPEND UPON ABSTRACTIONS 11<br>
Office: Moench Room F220
Phone: (812) 877-8974 Email: chenowet@rose-hulman.edu Chandan Rupakheti
Office: Moench Room F203
Phone: (812) 877-8390 Email: rupakhet@rose-hulman.edu<br>
slide2. Today The SOLID coding exercises
See course website for zip file of all 5 of these
They go with the quiz to turn in before class (as usual)
Bring along your answers to discuss in class, too 2<br>
slide3. Recall what SOLID is: S - SRP: Single Responsibility Principle
We discussed this one in Session 13
O - OCP: Open Closed Principle
L - LSP: Liskov Substitution Principle
I - ISP: Interface Segregation Principle
D - DIP: Dependency Inversion Principle
Pioneered by Robert Martin (Uncle Bob) 3<br>
slide4. Recall SRP THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE.
(You looked at Pablo’s eBook on this – see especially pp. 15-25) 4<br>
slide5. OCP SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) SHOULD BE OPEN FOR EXTENSION BUT CLOSED FOR MODIFICATION. 5<br>
slide6. LSP FUNCTIONS THAT USE REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT. 6<br>
slide7. ISP CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DO NOT USE . 7<br>
slide8. DIP A. HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS.
B. ABSTRACTIONS SHOULD NOT DEPEND UPON DETAILS. DETAILS SHOULD DEPEND UPON ABSTRACTIONS 8<br>
slide9. More Info Look at the SOLID article we saw before. There’s more in there beyond SRP!
The SRP part you already studied is thru p 26.
Then there’s an article on each of the other SOLID principles, too. 9<br>
slide10. Let’s Learn By Doing! 10 Download SolidExamples
(a zip file of 5 Java examples)
from the course website.
The quiz asks describe where there are issues, with which of the SOLID principles.
And – How you would fix them!
Do the quiz before class, as usual, but also be ready to discuss your answers in class.<br>
slide11. A “Solid” Summary SRP: THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE.
OCP: SOFTWARE ENTITIES SHOULD BE OPEN FOR EXTENSION BUT CLOSED FOR MODIFICATION
LSP: FUNCTIONS THAT USE REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT.
ISP: CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DO NOT USE .
DIP:
HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS.
ABSTRACTIONS SHOULD NOT DEPEND UPON DETAILS. DETAILS SHOULD DEPEND UPON ABSTRACTIONS 11<br>