Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Improve your software with SOLID code

Improve your software with SOLID code

You might have heard of the acronym SOLID and the five principles it consists of. Sadly the concepts are very abstract and can be difficult to really understand, while they are so important to writing good object oriented code.

This talk will not only deal with the theory behind SOLID and explain why SOLID is important. Better yet, we will be looking at code (lots of it!) and how it can be improved by applying one of the SOLID principles.

9ae62c9312a9b4f3058c08758c39b07f?s=128

flijten

May 02, 2012
Tweet

Transcript

  1. SOLID Design PHP Benelux may meeting

  2. None
  3. None
  4. Bikes

  5. SOLID

  6. OLDIS SOLID

  7. Open Closed Principle Software entities (classes, modules, functions, etc) should

    be open for extension, but closed for modification.
  8. None
  9. None
  10. A better solution

  11. None
  12. None
  13. None
  14. How to get the API?

  15. None
  16. There may be no more than one switch statement for

    a given type of selection. The cases in that switch statement must create polymorphic objects that take the place of such switch statements in the rest of the system
  17. None
  18. A small sidestep...

  19. None
  20. None
  21. Open Closed Principle 1. Since changing code introduces errors 2.

    Try to minimize change 3. And use polymorphism to solve our problems
  22. Liskov Substitution Principle Functions that use pointers or references to

    base classes must be able to use objects of derived classes without knowing it
  23. None
  24. None
  25. Design by contract Preconditions Postcondition Input and output variables And

    more...
  26. None
  27. None
  28. Liskov Substitution Principle 1. Indispensable when adhering to the OCP

    2. Only when a subclass can be used as its parent in every respect, functions using that parents can be reused without impunity.
  29. Dependency Inversion Principle A. High-level modules should not depend on

    low level modules. Both should depend on abstractions. B. Abstractions should not depend upon details. Details should depend upon abstractions.
  30. None
  31. None
  32. None
  33. None
  34. None
  35. Dependency Inversion Principle 1. Implementation details hide behind abstractions 2.

    Other code depends upon these abstractions
  36. Interface Segregation Principle Clients should not be forced to depend

    upon interfaces that they do not use.
  37. None
  38. None
  39. None
  40. None
  41. Interface Segregation Principle 1. Design interfaces based on use-cases 2.

    Stop pollution from seeping in
  42. Single Responsibility Principle There should never be more than one

    reason for a class to change.
  43. None
  44. Single Responsibility Principle The most simple principle to understand, the

    hardest to get right
  45. SOLID

  46. http://joind.in/talk/view/6465 Freek Lijten: @flijten www.freeklijten.nl