El tema que nos convoca ahora es algo conocido hace ya bastante tiempo pero que muchas veces pasa desapercibido. Como algunas veces se dice, sería ideal estar aplicándolo y no saber ni siquiera su nombre (esto significa que uno ya está en un muy buen nivel de diseño y no necesita "nombrar" a su estilo).
Para el resto de los mortales, acá viene una breve explicación de AOM (Adaptive Object Model).Básicamente el objetivo de esta técnica es lograr, adivinen...., sí!!! flexibilidad.
Para los ejemplos voy a usar los mismos ejemplos que se encuentran en un paper muy reconocido al respecto (más abajo voy a poner las referencias así lo pueden buscar Uds).
Cuando uno aprende las primeras nociones de la teoría de orientación a objetos, uno se encuentra con el tema de la herencia y la posibilidad de definir comportamiento arriba y que maravillosamente las subclases hereden el comportamiento y que sea todo más fácil. Como venía diciendo, uno queda maravillado por lo "poco" que se tiene que escribir, basta con escribirlo una vez en la superclase y todas las subclases ya lo tienen. Bien, si bien esto es cierto y hasta cierto punto beneficioso, la idea no es escribir menos, sino reusar el diseño de lo ya escrito (el reuso de código ya existía desde las tarjetas perforadas, así que no es nada nuevo).
El problema es que uno se empieza a acostumbrar a pensar en término de jerarquías y todo empieza a verse como jerarquías (eso de cuando uno tiene solamente un martillo todo se parece a un clavo se mantiene aquí). Cuál es entonces el problema? siguiendo con el ejemplo del paper, si nos dicen que tenemos vehículos de diferentes tipos (digamos camiones, autos y motos) lo que uno arranca pensando es en una jerarquía de Vehículos con la clase Vehículo como superclase y cada uno de los tipos concretos como subclase (Clase Auto, Clase Camión, Clase Moto). Si bien como arranque no está mal, la siguiente pregunta es que diferencia a cada subclase para ameritar una clase en particular para cada una??
Si no se puede responder "de una" esta pregunta, entonces probablemente no sea un buen diseño o al menos no se tengan justificativos tan válidos.
Hay un pattern de diseño que se llama TypeObject que justamente presenta una solución: si todo lo que diferencia a un auto de un camión es su tipo, entonces modelemos este tipo, por lo que pasaríamos al siguiente diseño : Clase Vehículo que tiene un colaborador de la clase TipoVehículo.
Siguiendo con los ejemplos de modo de dejar más claro el concepto, imaginemos ahora que nos piden diseñar un workflow que permite tener diferentes estados por los que pasan los elementos (digamos Iniciado, Asignado, En progeso, Finalizado). Para muchos rápidamente surge la idea de tener una clase EstadoDeWorkflow de la cual "colgarán" los estados concretos Iniciado, Asignado, En progreso, etc.
Ven lo que les digo respecto de como uno rápidamente piensa en jerarquías?? En este caso nuevamente aparece la pregunta de si tiene sentido tener clases "separadas" para cada estado. Además, que pasa si aparece un nuevo estado? Este diseño me impone la escritura de una nueva clase para cada nuevo estado posible del workflow, haciendo entre otras cosas que un usuario no puede definir desde la interfaz gráfica del sistema nuevos estados.
Después de todo lo escrito, fijense nuevamente en que estamos aplicando un principio del diseño bastante viejo: favorecer la colaboración frente a la herencia.
el paper que les comenté más arriba es uno que se llama "The Adaptive Object-Model Architectural Style", y fue escrito por dos que algo de objetos parece que saben: Joseph W. Yoder & Ralph Johnson.
Bueno, después seguimos.
Rescate este post de un blog cacheado en google de un tal Javier
Adaptive Object-Model Architecture by Federico Balaguer and Joseph W. Yoder
No hay comentarios:
Publicar un comentario