Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

SOLID principles

369 visualizaciones

Publicado el

SOLID design principles and some examples

Publicado en: Tecnología
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

SOLID principles

  1. 1. SOLID Principles Principles for good design
  2. 2. Three Presentations 1. SOLID Principles Overview 2. Test Driven Development Overview 3. Refactoring Patterns
  3. 3. SOLID - describes five design principles Michael Feathers and Bob Martin were heavily involved in formulating these principles They help us to write testable code by using good design principles I'll present these as SDOLI though...
  4. 4. Most importantly Read up on the principles afterwards and investigate for yourselves. Try some of them out
  5. 5. Consider the following...
  6. 6. Evaluating the design Pros ●Easy to write (very imperative, like a recipe) Cons ●Hard to test ●Hard to read ●Not reusable Let's separate the responsibilities using: Extract Method
  7. 7. Evaluating the design We have methods with one responsibility now. But the class still does several things Makes it harder to test Separate the responsibilities using Extract Class
  8. 8. This wraps up our database interaction This wraps up our email server interaction
  9. 9. Evaluating the design We have separate classes with responsibilities Much simpler It does require us to navigate in our IDE to see what MailSenderImpl and OrderDAOImpl do though Is it easier to test?
  10. 10. We've just demonstrated the...
  11. 11. Evaluation of our class Our class is bound to specific implementations: MailSenderImpl - what if I want to send via SMS instead of mail? Generalise the class by refactoring with Extract Interface
  12. 12. Can inject implementations of these interfaces Programmatically as well as with Spring! Evaluation of our class
  13. 13. We've just demonstrated...
  14. 14. ● Should be able to change the external dependencies of the class ● Without change the class internals ● Well we can do this already! ● We used an Interface and injected our dependencies into the class Evaluation of our class
  15. 15. There are other ways to make the class extensible: ● Dependency Injection - Inject when container starts ● Decorator and composition - Bound at compile time. Wrap a class providing before method & after method. ● Dynamic language extensibility - Bound at runtime. One way is to use a dynamic language or bean to provide functionality. Other extensibility mechanisms
  16. 16. This one is short because we've already done the refactoring previously... In conclusion
  17. 17. Open Closed We previously demonstrated...
  18. 18. We write a Duck interface which defines a method called swim: public interface Duck { void swim(); } We're envisioning all kinds of different implementations of this. Consider the following...
  19. 19. StandardDuck We create a class that implements this: public class StandardDuck implements Duck { public void swim() { System.out.println("Off we go..."); } }
  20. 20. ElectricDuck Soon we need to provide a new type of duck. public class ElectricDuck implements Duck { public void swim() { if ( isTurnedOn() ) { System.out.println("Off we go..."); } } } This breaks our principle because of the state.
  21. 21. ExceptoDuck This is also bad... public class ExceptoDuck implements Duck { public void swim() { throw new IllegalStateException("No way"); } } This also breaks our principle.
  22. 22. From the pond... Think of this from a client perspective. If you have a getDuck() method and you call swim() on that then you should expect it to just work This goes in hand with the: Principle of Least Astonishment
  23. 23. ● An object should be substitutable by it's: oInterface oBase Class ● This means that if you create a new class and implement an interface it shouldn't do anything surprising ● No side effects - throwing exceptions or doing things contrary to the interface Liskov Substitution Principle
  24. 24. Liskov Substitution We've just demonstrated...
  25. 25. ●Let's add another method to our Duck interface because we want our duck to swim and speak: public interface Duck { void swim(); void speak(); } Interfaces...
  26. 26. Enter RoboDuck public class RoboDuck implements Duck { public void swim() { System.out.println("Let's move creep"); } public void speak() { // I really really don't want to be forced // to speak... } }
  27. 27. ●We shouldn't force people to implement things they don't want to ●We should create a separate interface called Speakable or something... ●In short Interfaces should also have single responsibilities as well as classes and methods Bringing Back SRP
  28. 28. Interface Segregation We've just demonstrated...
  29. 29. ●YAGNI - You Ain't Gonna Need It. Don't build what you don't need today ! ●Don't over-engineer abstractions, hierarchies or genericise where you don't need to ●It's called Speculative Generality ●And it's way worse than any of the above because it makes work harder for us One other principle - YAGNI
  30. 30. ●If you have abstract classes that don't do anything - Collapse Hierarchy ●Don't delegate when you don't need to - fold the class back in - Inline the Class ●Above all... If someone proposes a complex design to a problem then question it until you understand Some refactoring advice
  31. 31. ●Further reading on this... ●One of the single best articles out there on bad code or code smells http://www.codinghorror.com/blog/2006/05/code-smells.html Coding Horror - Code Smells
  32. 32. ●Found out about this last night... http://sourcemaking.com/ SourceMaking.com
  33. 33. ●Refactoring oHow many do you know? oHow many people use Eclipse for this? ●Test Driven Development oDoes it help us here with the principles? oDo people write their tests first? oDo people use it when fixing bugs? Discussion

×