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.
¿Cómo aplicar los principios SOLID a mi código?
Definición de los principios y ejemplos clásicos de buenas prácticas de Diseño Orientado a Objetos
Audio de la presentación:
http://archive.org/details/10.S.o.l.i.d.ComoLoAplicoEnMiCdigo-JuanJosFuchs
¿Cómo aplicar los principios SOLID a mi código?
Definición de los principios y ejemplos clásicos de buenas prácticas de Diseño Orientado a Objetos
Audio de la presentación:
http://archive.org/details/10.S.o.l.i.d.ComoLoAplicoEnMiCdigo-JuanJosFuchs
Aquí podrás encontrar varia información sobre el pseudocodigo, definición de algoritmo, diagramas de flujo, problema informático y mas...
Entra ya!! Así encontraras la información que tu necesitas!!
2012 the clean architecture by Uncle bob GEORGE LEON
Very interesting 2012 the clean architecture by Uncle Bob
Also go buy the book Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series)
Enfoque estrategico para la prueba de softwareJorge Bustillos
Pruebas de software.
Características de estrategias de prueba.
Verificación y Validación.
Organización para la prueba de software.
Estrategias de prueba de software
Estrategias.
Criterios para completar la prueba.
Prueba de Unidad.
Prueba de Integración.
Prueba de Validación.
Pensado para enfrentar ambientes muy cambiantes. Es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los Desarrolladores, y propiciando un buen clima de trabajo.
Es una completa guía de preguntas y respuestas diseñada para brindar una comprensión exhaustiva y práctica del lenguaje de programación Java. Este documento ha sido creado con el objetivo de ser una valiosa herramienta tanto para principiantes que desean adentrarse en el mundo de la programación como para desarrolladores experimentados que buscan afianzar y ampliar sus conocimientos en Java. La guía abarca una amplia gama de temas relacionados con Java, desde conceptos básicos hasta temas más avanzados. Cada pregunta ha sido seleccionada cuidadosamente para abarcar los aspectos fundamentales del lenguaje. Cada pregunta se presenta con una explicación detallada y una respuesta clara y concisa, respaldada por ejemplos prácticos siempre que sea relevante. Además, los ejemplos de código se proporcionan para que los lectores puedan comprender y aplicar los conceptos de manera efectiva. No importa si eres un estudiante, un profesional o un entusiasta de la programación, esta guía te ayudará a fortalecer tus conocimientos en Java y te proporcionará una sólida base para convertirte en un desarrollador más competente y confiado en este emocionante mundo de la tecnología. ¡Sumérgete en el mundo de Java y amplía tus horizontes de desarrollo con "Java Preguntas"!
Aquí podrás encontrar varia información sobre el pseudocodigo, definición de algoritmo, diagramas de flujo, problema informático y mas...
Entra ya!! Así encontraras la información que tu necesitas!!
2012 the clean architecture by Uncle bob GEORGE LEON
Very interesting 2012 the clean architecture by Uncle Bob
Also go buy the book Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series)
Enfoque estrategico para la prueba de softwareJorge Bustillos
Pruebas de software.
Características de estrategias de prueba.
Verificación y Validación.
Organización para la prueba de software.
Estrategias de prueba de software
Estrategias.
Criterios para completar la prueba.
Prueba de Unidad.
Prueba de Integración.
Prueba de Validación.
Pensado para enfrentar ambientes muy cambiantes. Es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los Desarrolladores, y propiciando un buen clima de trabajo.
Es una completa guía de preguntas y respuestas diseñada para brindar una comprensión exhaustiva y práctica del lenguaje de programación Java. Este documento ha sido creado con el objetivo de ser una valiosa herramienta tanto para principiantes que desean adentrarse en el mundo de la programación como para desarrolladores experimentados que buscan afianzar y ampliar sus conocimientos en Java. La guía abarca una amplia gama de temas relacionados con Java, desde conceptos básicos hasta temas más avanzados. Cada pregunta ha sido seleccionada cuidadosamente para abarcar los aspectos fundamentales del lenguaje. Cada pregunta se presenta con una explicación detallada y una respuesta clara y concisa, respaldada por ejemplos prácticos siempre que sea relevante. Además, los ejemplos de código se proporcionan para que los lectores puedan comprender y aplicar los conceptos de manera efectiva. No importa si eres un estudiante, un profesional o un entusiasta de la programación, esta guía te ayudará a fortalecer tus conocimientos en Java y te proporcionará una sólida base para convertirte en un desarrollador más competente y confiado en este emocionante mundo de la tecnología. ¡Sumérgete en el mundo de Java y amplía tus horizontes de desarrollo con "Java Preguntas"!
Slides de la drupaleada de febrero en Origami, sobre responsive web design en Drupal.
Por Alberto Rojas de Manatí
Twitter:
@estudiomanati
@betovarg
www.estudiomanati.com
San José, Costa Rica.
Similar a Principios de diseño de código orientado a objetos SOLID (20)
Escaneo y eliminación de malware en el equiponicromante2000
El malware tiene muchas caras, y es que los programas maliciosos se reproducen en los ordenadores de diferentes formas. Ya se trate de virus, de programas espía o de troyanos, la presencia de software malicioso en los sistemas informáticos siempre debería evitarse. Aquí te muestro como trabaja un anti malware a la hora de analizar tu equipo
Si bien los hospitales conjuntan a profesionales de salud que atienden a la población, existe un equipo de organización, coordinación y administración que permite que los cuidados clínicos se otorguen de manera constante y sin obstáculos.
Mario García Baltazar, director del área de Tecnología (TI) del Hospital Victoria La Salle, relató la manera en la que el departamento que él lidera, apoyado en Cirrus y Estela, brinda servicio a los clientes internos de la institución e impulsa una experiencia positiva en el paciente.
Conoce el Hospital Victoria La Salle
Ubicado en Ciudad Victoria, Tamaulipas, México
Inició operaciones en el 2016
Forma parte del Consorcio Mexicanos de Hospitales
Hospital de segundo nivel
21 habitaciones para estancia
31 camas censables
13 camillas
2 quirófanos
+174 integrantes en su plantilla
+120 equipos médicos de alta tecnología
+900 pacientes atendidos
Servicios de +20 especialidades
Módulos utilizados de Cirrus
HIS
EHR
ERP
Estela - Business Intelligence
Principios de diseño de código orientado a objetos SOLID
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
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
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.
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.
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?