Principios de diseño de código
LUIS ALEXANDER ALDAZABAL GILHT TP://CODE2READ.COM@BERCZECK
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
¿Cómo medimos la calidad?
¿Cuántos fideos hay en la imagen?
Ahora, ¿ Cuántos tipos de fideos hay?
De esta forma ¿Es más fácil saber la respuesta?
Entonces, ¿Vale la pena refactorizar código?
Si nunca tenemos tiempo, ¿Cuándo vamos a escribir código con calidad?
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.
¿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.
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
POO VS Programación estructurada
¿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.
Tipos de Design Smells• Rigidez
• Fragilidad
• Inmovilidad
• Viscosidad
• Complejidad innecesaria
• Repetición innecesaria
• Opacidad
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.
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.
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.
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).
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.
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.
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.
Principios de diseño orientados a objetos
• DRY: • Dont repeat yourself
• KISS: • Keep it simple stupid
• Yagni: • You are going to need it
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.
Principios de diseño orientados a objetos
• SOLID: • Single Responsability
• Open Closed
• Liskov Substitution
• Interface segregation
• Dependency inversion
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.
Principios de diseño orientados a objetos
• SOLID - Single Responsability
¿Sobre qué artefactos aplica este principio?• Métodos
• Clases
• Paquetes
• Módulos
• Sistemas
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
Principios de diseño orientados a objetos• SOLID – Interface Segregation
Principios de diseño orientados a objetos• SOLID – Interface Segregation
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.
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.
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
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.
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
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?
Preguntas