Recomendados
Más contenido relacionado
Similar a Cap11 clean code - alexandergiraldo
Similar a Cap11 clean code - alexandergiraldo (20)
Último
Último (20)
Cap11 clean code - alexandergiraldo
- 1. SISTEMAS PRESENTADA POR: FRANCISCO ALEXANDER GIRALDO CLEAN CODE- CAP 11
- 2. • EN ESTE CAPÍTULO SE VERÁ COMO MANTENER LA LIMPIEZA EN NIVELES SUPERIORES DE ABSTRACCIÓN.
- 3. SEPARACIÓN DE ASPECTOS • PARADIGMA DE PROGRAMACIÓN, DONDE SE BUSCA UNA ADECUADA MODULARIZACIÓN DE LAS APLICACIONES Y UNA MEJOR SEPARACIÓN DE RESPONSABILIDADES.(ELIMINAR DEPENDENCIAS ENTRE CADA UNO DE LOS MÓDULOS). • “LOS SISTEMAS DE SOFTWARE DEBEN SEPARAR EL PROCESO DE INICIO, EN EL QUE SE CREAN LOS OBJETOS DE LA APLICACIÓN Y SE CONECTAN LAS DEPENDENCIAS, DE LA LÓGICA DE EJECUCIÓN QUE TOMA EL TESTIGO TRAS EL INICIO”
- 4. SEPARAR EL MAIN • SEPARAR LA CONSTRUCCIÓN DEL USO, CONSISTE EN TRASLADAR TODOS LOS ASPECTOS DE LA CONSTRUCCIÓN A MAIN Y DISEÑAR EL RESTO DEL SISTEMA SUPONIENDO QUE TODOS LOS OBJETOS SE HAN CREADO Y CONECTADO CORRECTAMENTE.” • EL FLUJO DE CONTROL ES FÁCIL DE SEGUIR, LA FUNCIÓN MAIN CREA LOS OBJETOS NECESARIOS, LOS PASA A LA APLICACIÓN Y ESTE LOS UTILIZA.
- 5. FACTORÍAS • UNA FACTORÍA ES UN OBJETO QUE MANEJA LA CREACIÓN DE OTROS OBJETOS. LAS FACTORÍAS SE UTILIZAN CUANDO LA CREACIÓN DE UN OBJETO IMPLICA ALGO MÁS QUE UNA SIMPLE INSTANCIACIÓN. • CUANDO LA APLICACIÓN TENGA QUE SER RESPONSABLE DE LA CREACIÓN DE UN OBJETO
- 6. INYECTAR DEPENDENCIAS • UN OBJETO NO DEBE SER RESPONSABLE DE INSTALAR DEPENDENCIAS, SINO QUE DEBE DELEGAR ESTA RESPONSABILIDAD EN OTRO MECANISMO AUTORIZADO, DE MODO QUE SE INVIERTE EL CONTROL.(RUTINA MAIN O UN CONTENEDOR DE PROPÓSITO ESPECIAL)
- 7. INYECCIÓN DE DEPENDENCIAS • ES UN PATRÓN DE DISEÑO ORIENTADO A OBJETOS, EN EL QUE SE SUMINISTRAN OBJETOS A UNA CLASE EN LUGAR DE SER LA PROPIA CLASE QUIEN CREE EL OBJETO. • LA FORMA HABITUAL DE IMPLEMENTAR ESTE PATRÓN ES MEDIANTE UN "CONTENEDOR DI" Y OBJETOS PLANOS O SIMPLES POR EJEMPLO LOS LLAMADOS POJO EN JAVA. EL CONTENEDOR INYECTA A CADA OBJETO LOS OBJETOS NECESARIOS SEGÚN LAS RELACIONES PLASMADAS EN UN FICHERO DE CONFIGURACIÓN.
- 8. INYECCIÓN DE DEPENDENCIAS • EJEMPLO SIN INYECCIÓN DE DEPENDENCIAS
- 9. INYECCIÓN DE DEPENDENCIAS • EJEMPLO CON INYECCIÓN DE DEPENDENCIAS
- 10. EVOLUCIONAR
- 11. EVOLUCIONAR • ARQUITECTURA QUE NO SEPARA CORRECTAMENTE LOS ASPECTOS
- 12. EVOLUCIONAR
- 13. PRUEBAS DE UNIDAD DE LA ARQUITECTURA DEL SISTEMA • ES ECONÓMICAMENTE FACTIBLE REALIZAR CAMBIOS RADICALES SI LA ESTRUCTURA DEL SOFTWARE SEPARA SUS ASPECTOS DE FORMA EFICAZ. • ES POSIBLE INICIAR UN PROYECTO DE SOFTWARE CON UNA ARQUITECTURA SIMPLE PERO BIEN DESCONECTADA, Y OFRECER HISTORIAS FUNCIONALES DE FORMA RÁPIDA, PARA DESPUÉS AUMENTAR LA INFRAESTRUCTURA.
- 14. USAR ESTÁNDARES CUANDO AÑADAN UN VALOR DEMOSTRABLE
- 15. BIBLIOGRAFÍA
Notas del editor
- Se realiza la comprobación del null y asisgnar el correspondiente test doublé por lo el método hace más de una solo cosa por lo cúal incumple el principio de responsabilidad única
- Las flechas de dependencia van en la misma dirección por lo que la aplicación no tiene conocimiento del main ni del proceso de construcción.
- La app debe crear instancias de lineItem, para q la app controle cuando crear lineItem, pero mantener los detalles de dicha construcción separados del código de la aplicación La aplicación orderProcessing se desconenta de los detalles de creación de lineItem En diseño de software, el patrón de diseño Factory Method consiste en utilizar una clase constructora (al estilo del Abstract Factory) abstracta con unos cuantos métodos definidos y otro(s) abstracto(s): el dedicado a la construcción de objetos de un subtipo de un tipo determinado. Es una simplificación del Abstract Factory, en la que la clase abstracta tiene métodos concretos que usan algunos de los abstractos; según usemos una u otra hija de esta clase abstracta, tendremos uno u otro comportamiento.
- Pojo en java es para enfatizar el uso de clases simples y que no dependen de frameworks