Siempre que programo aplico los principios SOLID. Pero me estoy dando cuenta de que hay algo que no funciona bien...

1. Deconstrucción de
SOLID

3. AUDIENCIA
• Ya conozco SOLID y lo tengo en cuenta cada vez que escribo una línea
de código – Esta charla es para ti
• Sé qué es SOLID y lo voy aplicando cuando puedo – Aplica SOLID
• No tengo ni idea de qué es SOLID – Quizá esta charla no sea para ti

4. Al principio fue la programación

5. PROGRAMACIÓN ORIENTADA A OBJETOS
 Abstracción
 Encapsulamiento
 Herencia
 Cohesión
 Polimorfismo

6. S.O.L.I.D.

8. Los 5 principios
 Single responsibility
 Open-closed
 Liskov substitution
 Interface segregation
 Dependency inversion

10. Single Responsibility Principle
Una clase debe tener una, y solo una, razón para cambiar

11. Single Responsibility Principle

12. Single Responsibility Principle

13. PERO…
• ¿Qué es una responsabilidad única exactamente?
• ¿Como puedo predecir qué código puede cambiar?
• ¿Tener muchas clases muy pequeñas es siempre mejor que una sola
más grande?

15. Open-Close Principle
Debes ser capaz de extender el comportamiento
de una clase sin necesidad de modificarla
(abierto a extensión, cerrado a modificación)

16. Strategy Pattern

17. Open-Close Principle

18. PERO…
• Cuando un requisito del sistema cambia, significa que tu código no es
válido y tienes que reemplazarlo

20. Liskov Substitution Principle
Las clases derivadas, deben poder ser sustituidas por
su clases base

21. Liskov Substitution Principle

22. Liskov Substitution Principle

23. PERO…
• La composición es más fácil que la herencia
• No hay una forma mejor de gastar el tiempo que escribir un gran
código que nunca va a ser usado

25. Interface Segregation Principle
Desgranar las interfaces lo más fino posible,
para que sean lo más específicas posible

26. Interface Segregation Principle

27. Interface Segregation Principle

28. Interface Segregation Principle

29. PERO…
• No dice nada, prácticamente cualquier cosa es mejor que un objeto
mega grande
• Muchas interfaces con solo un método: ¿esto es bueno?
• Quizá haya que basarse en “roles” más que en interfaces…

31. Dependency Inversion Principle
Depender de las abstracciones no de las concreciones

32. Dependency Injection Pattern

33. Dependency Inversion Principle

34. PERO…
• Generamos una dependencia: los framworks de DI
• No diseñemos para reusar componentes: diseñemos para usarlos

35. ¡¡¡Muchas Gracias!!!

37. Mejor usa estos 3 principios

39. Don’t Repeat Yourself
for(int i = 0; i< 100; i++)
Console.WriteLine(“I’ll not repeat myself”);

41. You Ain’t Gonna Need It
Tenemos que ser capaces de adaptarnos
rápidamente al cambio, no preverlo

43. Don’t Reinvent The Wheel
Si ya existe, se adapta a nuestras necesidades,
esta probado y funciona… ¿por qué no utilizarlo?

44. EN RESUMEN…

46. Keep It Simple, Stupid
Simple no es lo mismo que programar poco
Es muy difícil hacer cosas simples
Sé pragmático

47. DEBATE

48. TOKIOTA,
the Microsoft leading partner for innovative technology solutions,
empowering our customers while taking care of our people.