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