Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

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


An introduction to the SOLID principles

This presentation is intended for developers who wants to improve their knowledge in object oriented design

Taras Zubyk

on 7 December 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of An introduction to the SOLID principles

An introduction to the S.O.L.I.D. principles (cc) image by nuonsolarteam on Flickr Agenda Symptoms of Rotting Design What does SOLID mean? Quick race on each of the principles Conclusion Symptoms of rotting design Rigidity/inflexibility Hard to change because every change affects too many other parts of the system. Fragility When you make a change, unexpected parts of the system break. Immobility The inability to reuse software from other projects or from parts of the same project Viscosity Software/Environment hacks SOLID Advantages :
Tight cohesion
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
Full transcript