Descargado 32 veces
Subido porLuis Alexander Aldazabal Gil
Principios de diseño de código orientado a objetos SOLID
El documento detalla principios de diseño de código en programación orientada a objetos, abarcando conceptos como encapsulación, herencia, polimorfismo y principios SOLID. Se discuten las 'design smells', que son indicios de violaciones a estos principios y afectan la calidad del código. Asimismo, se presentan principios de diseño orientados a objetos, enfatizando la importancia de mantener bajo acoplamiento y alta cohesión en el desarrollo de software.
En este documento
Desarrollado con IA
Presentación sobre los principios de diseño de código por Luis Alexander Aldazabal Gil.
Introducción a la presentación, definición de programación orientada a objetos y comparación con programación estructurada.
Medición de la calidad del código y reflexiones sobre la facilidad de respuesta a problemas de código.
Importancia de la calidad del código y reflexión sobre la refactorización y el diseño del código.
Definición de programación orientada a objetos, sus cuatro pilares: encapsulación, herencia, polimorfismo y abstracción.
Comparativa entre POO y programación estructurada, sus características, ventajas y desventajas.
Definición y tipos de Design Smells que indican problemas en el diseño orientado a objetos.
Introducción a los principios DRY, KISS y SOLID, y su objetivo de mejorar la calidad del código.Principio de responsabilidad única, aplica a clases y métodos para mejorar el mantenimiento del código.
Principio abierto/cerrado, permite extender clases sin modificar su contenido, y su aplicación en el diseño.
Principio de sustitución de Liskov que enfatiza el polimorfismo y su aplicación para clases.
Principio de segregación de interfaces que propone interfaces pequeñas para evitar dependencia innecesaria.
Principio de inversión de dependencias que sugiere que los módulos de alto nivel no deben depender de los de bajo nivel.
Listados de recursos disponibles para profundizar en los principios de diseño de objetos orientados a C#.
Sección final de preguntas para abordar dudas sobre el contenido presentado durante la sesión.
Más contenido relacionado
Similar a Principios de diseño de código orientado a objetos SOLID
Principios de diseño de código orientado a objetos SOLID
- 1. Principios de diseñode 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 lacalidad?
- 4. ¿Cuántos fideos hay enla imagen? Ahora, ¿ Cuántos tipos de fideos hay?
- 5. De esta forma¿Es más fácil saber la respuesta?
- 6. Entonces, ¿Vale lapena refactorizar código?
- 7. Si nunca tenemostiempo, ¿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 laprogramació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ónestructurada • 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ónestructurada
- 12. ¿Qué son losDesign 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 DesignSmells • Rigidez • Fragilidad • Inmovilidad • Viscosidad • Complejidad innecesaria • Repetición innecesaria • Opacidad
- 14. Tipos de DesignSmells • 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 DesignSmells • 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 DesignSmells • 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 DesignSmells • 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 DesignSmells • 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 DesignSmells • 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 DesignSmells • 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ñoorientados a objetos • DRY: • Dont repeat yourself • KISS: • Keep it simple stupid • Yagni: • You are going to need it
- 22. Principios de diseñoorientados 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ñoorientados a objetos • SOLID: • Single Responsability • Open Closed • Liskov Substitution • Interface segregation • Dependency inversion
- 24. Principios de diseñoorientados 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ñoorientados a objetos • SOLID - Single Responsability ¿Sobre qué artefactos aplica este principio? • Métodos • Clases • Paquetes • Módulos • Sistemas
- 26. Principios de diseñoorientados 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ñoorientados 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ñoorientados 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ñoorientados 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ñoorientados 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ñoorientados 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ñoorientados 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ñoorientados 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ñoorientados 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ñoorientados 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ñoorientados 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ñoorientados 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ñoorientados a objetos • SOLID – Interface Segregation
- 39. Principios de diseñoorientados a objetos • SOLID – Interface Segregation
- 40. Principios de diseñoorientados 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ñoorientados 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ñoorientados 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ñoorientados a objetos • SOLID – Dependency inversión • Los módulos de alto nivel no deben depender de los de bajo nivel.
- 44. Principios de diseñoorientados a objetos • SOLID – Dependency inversión • Abstracciones no deben depender de los detalles, los detalles deben depender de las abstracciones
- 45. Recursos • c# PrincipiosSOLID – 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.