Existen numerosos términos relacionados con lo que podríamos denominar conocimiento en el diseño de micro-arquitecturas software: Principios, Heurísticas, Patrones, Malos Olores (Bad smell), Lecciones Aprendidas, Mejores Prácticas, Buenos Hábitos, Refactorizaciones y similares (aquí tienes algún recopilatorio más, en libros y artículos en la tabla de abajo tienes más referencias).
|
PRINCIPIOS |
| The Dependency Inversion Principle (DIP) “Depend upon Abstractions. Do not depend upon concretions” (R.C. Martin, 1996) |
|
HEURÍSTICAS |
| “If two or more classes only share common interface (i.e. messages, not methods), then they should inherit from a common base class only if they will be used polymorphically.” (Riel, 1996) |
|
MEJORES PRÁCTICAS |
| “See objects as bundles of behavior, not bundles of data.” (Venners, 2004) |
|
MALOS OLORES |
| Refused bequest Subclasses that do not use what they inherit (Beck y Fowler, 2000) |
Ejemplos de reglas de diseño OO
Sin tomar en cuenta a los patrones, quedándonos sólo con Principios, Heurísticas, Bad Smells, etc., en esencia estos siempre tienen la misma estructura, común, y aunque diferentes autores los han denominado de distinta forma y existe una amplia heterogeneidad entre las formas de describir estos componentes del conocimiento, no existe diferencia sustancial entre los mismos: todos atienden a la estructura y forma de una Regla, en la que exponen una condición para la que de cumplirse se ofrece una recomendación, destacar la “recomendación” de la Regla, que no es una solución como la del Patrón.
Supongamos la regla de “no dependencia de clases concretas” (de R. C. Martin, 1996, al que pudimos entrevistar para el blog), también conocida por «inversion of control».
Para cumplir la regla, esta nos dice que hay que depender de abstracciones (interfaces o clases abstractas) en vez de concreciones (clases concretas), solución que lleva implícita un problema: ¿cómo mantener el uso que anteriormente hacía la clase (los objetos) cliente A de la clase (objetos) servidora B si ahora no están directamente conectadas?.
Una vez detectado el problema originado de resolver la violación de la regla encontramos que una solución pasa por aplicar un patrón Creacional (Gamma et al., 1995), y es este patrón Creacional (para crear instancias y asociar objetos en la nueva situación) el que nos va ha permitir que el diseño no viole la regla.
En resumen, en muchas ocasiones, tras introducir una regla obtenemos un nuevo diseño el cual necesita un patrón. Con todo podemos sacar la siguiente conclusión: “Aplicar una Regla Implica Utilizar un Patrón”.
Hay que observar cómo esto no siempre sucede, no todas las reglas implican introducir un patrón, un claro ejemplo de esto es cuando aplicamos reglas que trabajan sólo dentro de un módulo (sólo afectan a una clase), como las que descomponen servicios largos, por ejemplo la «Regla de SI un Servicio Tiene Muchos Parámetros» (también conocida como el bad smell “Long Parameter List”, Beck y Fowler (2000)).
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024