Este capítulo trata sobre mantener la limpieza en niveles superiores de abstracción mediante la separación de aspectos como la construcción y el uso de objetos. Se recomienda separar la creación de objetos en el método main y su uso posterior, utilizar factorías para la creación de objetos cuando sea necesario, e inyectar dependencias en lugar de que las clases las creen directamente. Esto permite una arquitectura más evolutiva y con mejores pruebas unitarias.

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