solid

Recursos de programación de solid
Hoy sentaremos los principios sobre la Arquitectura de Software y, más en concerto, sobre qué es la Arquitectura Hexagonal. Tras una primera temporada donde hemos hablado al respecto de los principios SOLID, y hemos visto los problemas del código acoplado en términos de testabilidad, vamos a pasar a dar un salto en términos de diseño de Software y nos centraremos en la Arquitectura de Software, o como lo denominaba Sandro Mancuso: "Macro-design". Más info: http://codely.tv/screencasts/arquitectura-hexagonal-ddd/
SOLID, YAGNI, KISS, DRY... Los programadores somos vagos hasta para poner nombres. Pero... ¿es fácil ser vago? Al contrario de lo que mucha gente piensa, ser "vago" es un arte, y como tal se debe cultivar. En esta charla veremos qué ideas se esconden detrás de estos acrónimos, veremos Clean Architecture, refactorización de código, patrones, y buenas prácticas en general que nos garantizaran trabajar eficientemente y dormir bien por las noches sabiendo que hemos hecho bien nuestro trabajo. Los ejemplos de la charla estarán en C#, pero cualquier programador con conocimientos de C++/Java debería poder entender los ejemplos sin dificultad. Bibliografia recomendada: Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin) The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin) The Pragmatic Programmer (Andrew Hunt, David Thomas)
¿Cometes alguno de estos errores comunes al interpretar el Principio de Segregación de Interfaces? En este vídeo veremos principalmente en qué se basa el concepto "las interfaces pertenecen a los clientes que las usan y no a las clases que las implementan". También hablaremos del "acoplamiento estructural" de nuestras interfaces. Recomiendo darle un voto de confianza a la explicación. Al principio del vídeo creo que me lío un poco y a medida que avanza el vídeo considero que se puede entender mejor lo que quiero transmitir.
Aprende a través de un ejemplo qué es el Interface Segregation Principle (o Principio de Segregación de Interfaces). Este principio que forma parte de los 5 principios de desarrollo SOLID promueve la limitación de responsabilidades a nivel de interfaces para acabar permitiendo que se respete el Single Responsibility Principle. Más info: http://codely.tv/screencasts/principio-segregacion-interfaces-solid
Material del vídeo: http://codely.tv/screencasts/solid-principio-inversion-dependencias Qué es y qué beneficios aporta el Principio de Inversión de Dependencias. Índice: 1:03 - Explicación código base (contexto) 2:50 - Escenario 1: Código altamente acoplado y creando las instancias de los colaboradores en el punto en el que se necesitan 3:55 - ¿Por qué es malo el acoplamiento de código? 6:10 - Diagrama de clases del escenario 1 7:10 - Escenario 2: Refactoring para introducir el concepto de inyección de dependencias. Código altamente acoplado pero creando las instancias de los colaboradores fuera de la clase cliente 9:00 - ¿Qué beneficios tiene la inyección de dependencias? 10:39 - Escenario 3: Refactoring para aplicar el Principio de Inversión de Dependencias (Dependency Inversion Principle, DIP). Código desacoplado y cambiable. 11:38 - Explicación de la interface introducida. Diseño por contratos 13:35 - ¿Qué beneficios tiene la inversión de dependencias? 15:30 - Diagrama de clases aplicando el principio de inversión de dependencias 16:05 - Inversión de dependencias como nunca te lo han explicado :D
Material del vídeo: http://codely.tv/screencasts/solid-responsabilidad-unica-segregacion-interfaces Proceso de refactoring de un código que viola el primero de los principios SOLID: Principio de Responsabilidad Única. Índice: 0:29 - Qué son los principios SOLID 1:28 - Contexto: Qué hace el código a refactorizar 5:12 - Violación del Principio de Responsabilidad Única - SRP 7:07 - Problemática al violar SRP 9:57 - Refactoring del método registerNewUser 17:41 - Violación del Principio de Segregación de Interfaces - ISP
8. Achieving Dependency Inversion by extracting an interface.Even though we are already injecting into Alarm the dependency on Sensor, we haven't inverted the dependency yet. Alarm still depends on a concrete implementation. Now we'll show how to invert the dependency by extracting an interface. Normally, it's better to defer this refactoring until you have more information, i.e., until the need for another sensor types arises, to avoid falling in the Speculative Generality code smell. However,...
1. Introduction.Last week I facilitated a guided kata for a Gran Canaria Ágil event in Aplicaciones Informáticas Domingo Alonso (thanks to both for inviting me) in which I explained a possible way to solve Luca Minudel's Tire Pressure Monitoring System exercise. This exercise is part of his TDD with Mock Objects: Design Principles and Emergent Properties exercises. I like these exercises very much because they contain clear violations of the SOLID principles but they are sill small enough to be...
¿Cuándo lo hacemos? Hablamos sobre esto, sobre la utilidad que le encontramos y damos alguna bibliografía que a nosotros nos sirvió para asimilar conceptos. Bibliografía [LIBRO] Refactoring, by Martin Fowler [LIBRO] Refactoring to Patterns, by Joshua Kerievsky [LIBRO] Pro PHP Refactoring [VIDEO] Curso de Refactoring, by Xavi Gost [WIKI] Principios SOLID [VIDEO] Debate de “gurús” sobre cohesión y acoplamiento … Sigue leyendo 01×08 Refactoring →
Web
31-12-2014
I've just watched this great talk by Colin Jones: SOLID Clojure - por Garajeando