Saludo
24
dic
| Twittear |
| Twittear |
Son metodologías en las que solemos caer muy fácilmente y para colmo de males, con bastante frecuencia.
Estas son: DRY (Don't Repeat Yourself) y YAGNI (You Ain't Gonna Need It).
Intentar llevar a cabo todas y cada una de las metodologías y principios vistos hasta aquí, nos permitirá tener un código limpio; mucho más fácil de leer, comprender y expandir.
| Twittear |
Echemos una mirada al siguiente código:
| Twittear |
Esto básicamente significa que en ningún lugar de nuestro código deberíamos depender de una implementación actual, sino que en su lugar debemos depender de interfaces o clases abstractas. ¿Y por qué deberíamos hacer esto? Porque esto nos habilita a cambiar cualquier implementación por otra y ninguna otra clase que hayamos codificado debe saberlo o importarle. Si, es así, a ninguna otra clase debe importarle que el cambiemos un colaborador por otro.
| Twittear |
Esto se torna repetitivo, pero esto es para minimizar el impacto de los cambios que puedan haber sobre nuestro código.
En otras palabras: si tenemos una clase abstracta o una interfaz, entonces, quienes la implementen, no deben ser forzados a implementar partes (métodos o propiedades) que no les importen.
| Twittear |
Esto, nuevamente, es para minimizar el impacto de los cambios que puedan haber sobre nuestro código.
Los problemas que resuelve LSP casi siempre son fácilmente evitables. Hay algunos habituales signos reveladores de que una violación a LSP aparece en el código. He aquí un escenario que muestra cómo puede ocurrir una violación a LSP.
| Twittear |
Este patrón de diseño, establece que los comportamientos no deben heredarse. En su lugar, se deben encapsular usando interfaces.
Para dar un ejemplo, me remitiré a uno ya existente en el libro Head first design patterns.
| Twittear |
Suena fácil, pero muchos desarrolladores podemos perder el norte durante la implementación de este enfoque de extensibilidad. No se trata necesariamente por una cuestión de habilidades, sino más bien, que no se nos ha enseñado a abordar este principio en el diseño de clases.
| Twittear |
Algo con un propósito, una responsabilidad, siempre va a resultar mucho más fácil de cambiar. Esto es simplemente porque se puede ver mucho más claramente lo que hace y lo que no. Además, como tiene una única responsabilidad, no hay chance de que el cambio en el código pueda afectar a otro código, comportamiento quizás, pero código, no. Y mejora en gran medida la reutilización de código.
Finalmente, el código se hace mucho más fácil de probar ya que se puede realizar el test de una responsabilidad en forma aislada de las demás.
| Twittear |
Lamentablemente, esto es sólo una utopía para los programadores y con el correr del tiempo hemos tratado de no caer en las trampas que nosotros mismos nos creamos cuando programamos sin pensar en los cambios que los requerimientos pueden sufrir a lo largo del tiempo.
Entra tantas mejoras que se han ido agregando al desarrollo de software, la programación orientada a objetos (P.O.O.) se ha convertido en un conocimiento que hoy se considera muy importante para esta tarea.
Implementar los principios S.O.L.I.D., nos redundará en una mejora sustancial del diseño y arquitectura de nuestras aplicaciones, haciendo que las mismas sean mucho más flexibles y extensibles.
Este acrónimo mnemotécnico surge de la unión de varios principios básicos de la programación orientada a objetos, explicados en el libro "Agile software development: Principles, Patterns and Practices" por uno de los grandes exponentes de la Artesanía del software: el famoso Uncle Bob (Robert Cecil Martin).
| Twittear |
Cómo aplicarlo al trabajo diario
Son muchos pasos los que se deben llevar a cabo, muy simples, pero pueden resultar un reto para algunos.
Tan fácil como suena, mantenerlo simple, es sólo cuestión de paciencia. Sobretodo, con uno mismo.
A continuación, veremos los puntos a tener en cuenta para llevarlo a cabo:
- Ser humilde. No pensar en uno mismo como un super genio. Este es el primer error. Siendo humilde, es muy posible alcanzar el estatus de super genio. Pero, aunque así no se lograse, a quién le importa?! El código es simple y estúpido, por lo que no hay que ser un genio para trabajar con él.
- Dividir las tareas en subtareas que, en principio, no deben llevar más de 4-12 horas de codificación.
- Dividir los problemas en pequeños problemas. Cada problema se debe poder resolver dentro de una o muy pocas clases.
- Mantener los métodos pequeños. Cada método no debe tener nunca más de 10-20 líneas y sólo debe resolver un (y sólo un) problema. Si contiene muchas condiciones, hay que dividirlo en métodos más pequeños. (Esto no sólo los hace más legibles y mantenibles, sino que además, encontrar errores es mucho más rápido.
- Mantener las clases pequeñas. Aplicar la misma metodología que con los métodos.
Copyright 2009 Programación SOLIDa
BloggerTheme by BloggerThemes |
Design by 9thsphere