Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.
An introduction to the SOLID principles
Transcript of An introduction to the SOLID principles
Loose coupling SOLID An object should have only a single responsibility A responsibility as a reason to change DEMO Robert C. Martin
(uncle Bob) Taras Zubyk
Software developer S : Single Responsibility Principle O : Open/Closed Principle L : Liskov Substitution Principle I : Interface Segregation Principle D : Dependency Inversion Principle Suggestions Find one reason to change and take everything else out of the class Document your code Be sure that you can associate all method names with the class/interface name. Don't create a GOD objects SOLID Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification Suggestions Change a classes behavior by using inheritance and/or composition SOLID If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T Liskov Substitution Principle SOLID Liskov Substitution Principle SOLID Interface segregation principle Interfaces that have become “fat” (like god classes) should be split into several interfaces SOLID Dependency Inversion Principle Depend upon Abstractions. Do not depend upon concretions. Conclusion Don't do things like ... Following SRP usually makes it easier to follow DRY Design your class/methods before coding Derived types must be completely substitutable for their base types Example A square is a rectangle Inheritance Implementation Expected: 30
Actual : 9 Choose the best approach for the problem solution Easy maintain Easy extend Understandable Code Easy to test Loose coupling & tight cohesion True encapsulation