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.

Transcript

1. SOLID Design PHP Benelux may meeting
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.
10. A better solution
14. How to get the API?
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
18. A small sidestep...
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
25. Design by contract Preconditions Postcondition Input and output variables And more...
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.
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.
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.
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