1 / 11

Session 33 More on SOLID

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. Today. The SOLID coding exercises

lynde
Download Presentation

Session 33 More on SOLID

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Session 33 More on SOLID Steve Chenoweth Office: Moench Room F220 Phone: (812) 877-8974Email: chenowet@rose-hulman.edu ChandanRupakheti Office: Moench Room F203 Phone: (812) 877-8390Email: rupakhet@rose-hulman.edu

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

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

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

  5. OCP SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) SHOULD BE OPEN FOR EXTENSION BUT CLOSED FOR MODIFICATION.

  6. LSP FUNCTIONS THAT USE REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT.

  7. ISP CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DO NOT USE .

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

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

  10. Let’s Learn By Doing! 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.

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

More Related