Inyección de funcionalidad... ¿existe?
Hola, estoy haciendo un package de managers para realizar varias funciones. Acomodar elementos, redimensionar, atrapar eventos de mouse, extraer propiedades, etc.
La cuestión es que se me ocurrió la idea de inyectar esos sprites-managers en un sprite vacío a forma de "inyectar funcionalidad".
Ejemplo: Si agregamos a un sprite vacío, 10 movieclips, podemos posteriormente agregarle un sprite-manager del tipo "Presentacion" que se encargue de acomodar todos los elementos de ese sprite.
Por ejemplo, para crear un componente scrollbar solo necesitaríamos crear un sprite vació e inyectarle dos o tres símbolos gráficos para luego inyectarle un sprite con la funcionalidad del scroll.
La ventaja que le encuentro a esto, es que a un elemento X se le puede "inyectar" cualquier tipo de funcionalidad en tiempo real sin necesidad de compilar.
¿Existe algún paradigma así en programación o me hizo daño esto que me fume? :P
elSuricatoRojo
Hola, lo que planteas huele a framework lo cual implica una segunda cuestion ¿es rentable crear tu framework o es mejor utilizar uno existente?
Mi opinión coincide bastante con esta: http://www.dandolachapa.com/2008/05/06/%C2%BFahora-picar-frameworks-propios-es-malo/ y básicamente se resume en que hacer un framework no se debe contabilizar a nivel rentabilidad puramente económica sino tambien a nivel del know-how que adquieres... aunque yo añadiría que si te haces tu propio framework te sientes mucho mas seguro, agil y rápido si tienes que añadir o modificar funcionalidades.
En cuanto a modo en el que inyectas esas funcionalidades o si esas funcionalidades están ya compiladas o no ta aconsejo que antes de empezar hagas muuucha labor de análisis, para ver si lo que puede parecer una ventaja a primera vista (ej: tener las funcionalidades/clases precompiladas) al final te lastra (te obliga a recompilar todo o casi todo en cada cambio de la clase/funcionalidad, no solo ella misma sino todas aquellas que la incorporen).
Una forma, la que utilizo yo, es tener un classpath con una rama com todas las clases del framework, trabajar por compisición y tratando de no extender MovieClip ni siquiera, y luego hacer esas inyecciones con imports + contructora y todo basado en eventos de tal forma que la implementación de la capa de representación tenga "cintura"... me explico:
Si basa tu framework de tal forma que para un scroll "inyectas" 1 botón de subir + 1 botón de bajar + 1 slider + la lógica de scroll (que tiene los datos de alto de contenidos, inercias del scroll, alto de la mascara o zona del visor, etc)... ten cuidado para que si en un proyecto resulta que no hay boton de subir y bajar y solo slider o haya 2 botones de subir y 3 sliders, tu planteamiento lo encaje bien.
Tambien ten cuaidado por que si te pasas de "abstracto" la clase se hace poco intuitiva y en vez de tener 1 clase lo mismo acabas con 5 previendo situaciones que al final no se producen y que tan solo hacen que cada vez que quieres utilizar esa funcionalidad requiera que te la estudies de nuevo porque no es intuitiva y ya se ha olvidado porque creastes esa capa de abstacción adicional.
En fin... suerte valor y al toro, y yo particularment te animo a hacerlo porque pase lo que pase vas a aprender un huevo.
PD-Offtopic: Otra cosa muy importante... hagas lo que hagas ni te ocurra volar con Vueling (no tiene nada que ver lo se, pero es un consejo tan valido y util como los de arriba, creeme :-) )
dagi3d
échale un vistazo a los patrones Decorator y Command que igual es a lo que te refieres:
http://en.wikipedia.org/wiki/Decorator_pattern
http://en.wikipedia.org/wiki/Command_pattern