Conjunto de principios, no son reglas, aplicados al diseño orientado a objetos. SOLID no es un framework, ni una tecnología, tampoco una librería y mucho menos una metodología. Su propósito es generar código fácil de entender y mantener. Representa cinco principios básicos de la programación orientada a objetos y el diseño.

1. Principios de diseño de código
LUIS ALEXANDER ALDAZABAL GIL
HTTP://CODE2READ.COM
@BERCZECK

2. Contenido
• Introducción
• ¿Qué es la programación orientada a objetos?
• POO VS Programación estructurada
• ¿Qué son los Design Smells?
• Principios de diseño orientados a objetos

3. ¿Cómo medimos la calidad?

4. ¿Cuántos fideos hay
en la imagen?
Ahora, ¿ Cuántos
tipos de fideos hay?

5. De esta forma ¿Es más fácil saber la respuesta?

6. Entonces, ¿Vale la pena refactorizar código?

7. Si nunca tenemos tiempo,
¿Cuándo vamos a escribir
código con calidad?

8. Momento de reflexión
• Cuantas veces te has topado con clases o métodos que contiene
cientos o miles de líneas de código.
• Cuantas veces dentro de una clase o método encuentras todo tipo de
funcionalidad: Log, Manejo errores, Sesión, etc.
• Cuantas veces has encontrado muchas sentencias if o switch dentro de
un método.
• Cuanto código repetido y mal escrito hay en toda tu aplicación.
• Cuantas veces ni nosotros mismos entendemos el código que hemos
escrito.
• Cuantas veces hacer un cambio toma más de lo necesario por la forma
en como hemos diseñado el código.

9. ¿Qué es la programación orientada a objetos?
• Es un estilo de programación.
• Formada por 4 pilares:
• Encapsulación: Oculta detalles de la implementación
• Herencia: Crear nuevos objetos para compartir comportamientos.
• Polimorfismo: Tener métodos con el mismo nombre pero con comportamientos
diferentes.
• Abstracción: Aislar un elemento del mundo real.
• Se crean objetos con responsabilidades únicas que contienen campos,
atributos y métodos.
• Siempre considerando estas dos medidas al momento del diseño:
• Acoplamiento, se busca tener un bajo acoplamiento.
• Cohesión, se busca tener una alta cohesión.

10. POO VS Programación estructurada
• Colaboración entre objetos.
• La funcionalidad se agrupa
a nivel de objetos.
• Los objetos se pueden
reutilizar.
• Diseño complejo.
• Aumenta la cohesión y
disminuye el acoplamiento.
• Los objetos tiene
responsabilidades únicas.
• .Net, Java, Ruby, etc
• Una serie de funciones,
subrutinas y tareas.
• La funcionalidad se agrupa a
nivel de tarea.
• Las funciones, subrutinas y
tareas se pueden reutilizar.
• No necesita diseño.
• Disminuye la cohesión y
aumenta el acoplamiento.
• SQL, VB6

11. POO VS Programación estructurada

12. ¿Qué son los Design Smells?
• Síntomas que indican que estamos violando algún principio
de diseño orientado a objetos.
• Esto ocurre en el diseño de la aplicación.
• Degrada la calidad del código que escribimos.
• Por lo tanto se genera código difícil de entender, esto
impacta en el esfuerzo al momento de darle mantenimiento.

13. Tipos de Design Smells
• Rigidez
• Fragilidad
• Inmovilidad
• Viscosidad
• Complejidad innecesaria
• Repetición innecesaria
• Opacidad

14. Tipos de Design Smells
• Rigidez:
• Hacer un cambio es difícil, aunque sea un cambio simple.
• Un cambio causa una cascada de cambios en los módulos
dependientes.
• A más módulos se tengan que cambiar, más rígido es el sistema.
• Esto impacta en las estimaciones, ya que hay que hacer
cambios en módulos que no se tomaron en cuenta y toma más
tiempo que el estimado.

15. Tipos de Design Smells
• Fragilidad:
• Un cambio causa que el código no compile, ya que
aparecieron errores en muchos lugares.
• Ocurre cuando un cambio hecho en un modulo X afecta a un
modulo Y, aunque no tengan una relación directa.
• A medida que el diseño es frágil la probabilidad que un
cambio introduzca nuevos problemas también
aumenta.

16. Tipos de Design Smells
• Inmovilidad:
• Es difícil reutilizar partes del sistema.
• Ocurre cuando un diseño contiene partes que pueden ser
reutilizados por otros, pero el esfuerzo de separarlas es
muy grande.
• A medida que el diseño es inmóvil la probabilidad de
cometer los mismos errores también aumenta.

17. Tipos de Design Smells
• Viscosidad:
• Es difícil hacer lo correcto a nivel de software o
ambiente de desarrollo.
• Seguir la estrategia propuesta VS soluciones
alternas.
• Ocurre cuando es mas fácil hacer las cosas mal
(soluciones alternas) a hacer las cosas bien
(estrategia propuesta).

18. Tipos de Design Smells
• Complejidad Innecesaria:
• Son elementos que existen en el diseño que soportan
requerimientos que no se necesitar.
• Ocurre cuando se quiere desarrollar una librería de
propósito general y se agregan cosas que tal vez nunca se
van a necesitar.
• A medida que la complejidad aumenta el código se vuelve
más difícil de mantener.

19. Tipos de Design Smells
• Repetición Innecesaria:
• Hacer Ctrl+V y Ctrl+C a través de todo el sistema.
• Ocurre cuando se repite el mismo bug en todo el
sistema y para corregirlo hay que buscar en todos lados.
• A medida que se va repitiendo código un módulo se vuelve
más difícil de mantener.

20. Tipos de Design Smells
• Opacidad:
• La tendencia del código a que sea difícil de entender.
• Ocurre cuando el código aumenta con el tiempo y se
vuelve mas difícil de mantener.
• A medida que la opacidad aumenta se vuelve mas
complicado agregar nuevas funcionalidades.

21. Principios de diseño orientados a objetos
• DRY:
• Dont repeat yourself
• KISS:
• Keep it simple stupid
• Yagni:
• You are going to need it

22. Principios de diseño orientados a objetos
• SOLID:
• Conjunto de principios, no son reglas, aplicados al diseño orientado
a objetos.
• No es un framework, ni una tecnología, tampoco una librería y
mucho menos una metodología.
• Su propósito es generar código fácil de entender y mantener.
• Representa cinco principios básicos de la programación orientada a
objetos y el diseño.

23. Principios de diseño orientados a objetos
• SOLID:
• Single Responsability
• Open Closed
• Liskov Substitution
• Interface segregation
• Dependency inversion

24. Principios de diseño orientados a objetos
• SOLID - Single Responsability
• Cada clase debe tener una única
responsabilidad.
• Una clase debe tener una, y solo una,
razón de cambio, también aplica a nivel de
métodos de una clase.

25. Principios de diseño orientados a objetos
• SOLID - Single Responsability
¿Sobre qué artefactos aplica este
principio?
• Métodos
• Clases
• Paquetes
• Módulos
• Sistemas

26. Principios de diseño orientados a objetos
• SOLID - Single Responsability
¿Cuándo debemos aplicar este principio?
• Cuando una clase es muy larga (sugerencia si tiene más de 300 lineas de código).
• Cuando un método es muy largo (sugerencia si tiene más de 40 lineas de código).
• Cuando existen muchas dependencias a otros objetos (sugerencia si tiene más de
20 dependencias)
• Cuando hay baja cohesión.
• Cuando se usan nombres muy genéricos: Util, Manager, Process.
• Cuando se hace uso del anti patrón Spagethi Code.

27. Principios de diseño orientados a objetos
• SOLID - Single Responsability
Argumentos en contra de este principio
• Demasiadas clases
• Complicado entender el panorama general del diseño
• Nota: Tener más clases no significa necesariamente que el código sea más
complicado, hay casos y casos.
Nota: Tener más clases no significa necesariamente que el código sea más
complicado, hay casos y casos.

28. Principios de diseño orientados a objetos
• SOLID – Open Closed
• Una clase debe ser abierta para
extender, pero cerrada para
modificar.
• Uno debe ser capaz de extender el
comportamiento de una clase, sin
modificar su contenido.

29. Principios de diseño orientados a objetos
• SOLID – Open Closed
¿Sobre qué artefactos aplica este principio?
• Funciones
• Clases
• Módulos
¿Qué beneficios trae el trabajar con este principio?
• Reduce el riesgo de agregar nuevos bugs al código existente.
• Bajo acoplamiento.
• Flexibilidad.
• Mantenimiento, sistemas fáciles de cambiar y evolucionar.

30. Principios de diseño orientados a objetos
• SOLID – Open Closed
¿Cuándo debemos aplicar este principio?
• Cuando se detecta que una clase será sujeta a cambio
• Cuando no se puede cambiar una librería de terceros
¿Cuándo no debemos aplicar este principio?
• Cuando el número de sentencias if o switch en un método no va a
cambiar
• Cuando se sabe que una clase cuenta con un comportamiento fijo.

31. Principios de diseño orientados a objetos
• SOLID – Open Closed
¿Qué patrón puedo usar para aplicar este principio?
• Strategy
• Template Method
Argumentos en contra de este principio
• Requiere más esfuerzo el diseñar las clases
• Requiere mayor experiencia

32. Principios de diseño orientados a objetos
• SOLID – Liskov substitution
• Una clase derivada puede ser
reemplazada por cualquier otra que
use su clase base sin alterar
su correcto funcionamiento.
• Substituye una clase por otra.
• Polimorfismo.

33. Principios de diseño orientados a objetos
• SOLID – Liskov substitution
¿Sobre qué artefactos aplica este principio?
• Clases
¿Qué beneficios trae el trabajar con este principio?
• Flexibilidad.
• Mantenimiento, sistemas fáciles de cambiar.

34. Principios de diseño orientados a objetos
• SOLID – Liskov substitution
¿Cuándo debemos aplicar este principio?
• Cuando se quiere extender el funcionamiento usando clases
derivadas sin tocar el código base.
• Cuando existan clases que compartan el mismo
comportamiento.
• Cuando aplicamos el principio Open Closed.
¿Cuándo no debemos aplicar este principio?
• Cuando se sabe que una clase cuenta con un comportamiento
fijo.

35. Principios de diseño orientados a objetos
• SOLID – Interface Segregation
• Define interfaces pequeñas que
resuelvan un problema específico (Role
Interface) en lugar de tener interfaces
grandes que hagan muchas cosas (Head
Interface).
• Un cliente no debe ser forzado a
implementar interfaces que no necesite.

36. Principios de diseño orientados a objetos
• SOLID – Interface Segregation
¿Sobre qué artefactos aplica este principio?
• Clases
• Interfaces
¿Qué beneficios trae el trabajar con este principio?
• Bajo acoplamiento.
• Alta cohesión.
• Código fácil de cambiar.
• Código fácil de mantener.
• Código fácil de desplegar.

37. Principios de diseño orientados a objetos
• SOLID – Interface Segregation
¿Cuándo debemos aplicar este principio?
• Cuando existan clases con métodos vacíos o que devuelvan valores por defecto.
• Cuando existan clases con métodos que devuelvan excepciones del tipo
NotImplementedException.
• Cuando un cliente usa solo algunos métodos de una clase.
¿Cuándo no debemos aplicar este principio?
• Cuando una clase no va a ser rehusada (Una clase controladora o un servicio web)
• Cuando nadie depende de esta clase.

38. Principios de diseño orientados a objetos
• SOLID – Interface Segregation

39. Principios de diseño orientados a objetos
• SOLID – Interface Segregation

40. Principios de diseño orientados a objetos
• SOLID – Dependency inversión
• Los módulos de alto nivel no deben
depender de los módulos de bajo
nivel ambos deben depender de
abstracciones (Interfaces, Clases
abstractas), no de clases concretas.
• Las abstracciones no deben depender
de los detalles, los detalles deben
depender de las abstracciones.

41. Principios de diseño orientados a objetos
• SOLID – Dependency inversión
¿Sobre qué artefactos aplica este principio?
• Clases
• Paquetes
• Módulos
¿Qué beneficios trae el trabajar con este principio?
• Bajo acoplamiento.
• Testeabilidad.
• Flexibilidad.

42. Principios de diseño orientados a objetos
• SOLID – Dependency inversión
¿Cuándo se recomienda aplicar este principio?
• Cuando se necesitan desacoplar piezas de software que pueden cambiar en
el futuro.
• Cuando el nivel de acoplamiento en el código es alto.
¿Cuándo no debemos aplicar este principio?
• Cuando se desarrolla un módulo CRUD pequeño .
Argumentos en contra de este principio
• Requiere mayor experiencia
• Requiere más esfuerzo el diseñar los artefactos
• Demasiadas interfaces
• Complicado entender el panorama general del diseño

43. Principios de diseño orientados a objetos
• SOLID – Dependency inversión
• Los módulos de alto nivel no deben depender de los de
bajo nivel.

44. Principios de diseño orientados a objetos
• SOLID – Dependency inversión
• Abstracciones no deben depender de los detalles, los
detalles deben depender de las abstracciones

45. Recursos
• c# Principios SOLID – Caso práctico: Módulo de seguridad Parte 1
• c# Principios SOLID – Caso práctico: Módulo de seguridad Parte 2
• c# Object oriented design – ¿Qué significa SOLID?
• c# Object oriented design – ¿Cómo aplicas el principio Single Responsability?
• c# Object oriented design – ¿Cómo aplicas el principio Open Closed?
• c# Object oriented design – ¿Cómo aplicas el principio Liskov Substitution?
• c# Object oriented design – ¿Cómo aplicas el principio Interface Segregation?
• c# Object oriented design – Dependency Inversion ¿Cómo aplicas este principio?

46. Preguntas