Efectivamente, tienes razón en que lo importante es el concepto de programación orientada a objetos, y que siempre es mejor el evitar el acceso directo a propiedades de objetos.
La discusión, al menos por mi parte, no era sobre cómo deben comunicarse las clases, o cómo asignar en una clase referencias a otra, sino sobre la mentalidad con la de debemos atacar determinados problemas que se nos presentan. En lo que no estoy de acuerdo es en utilizar todos los lenguajes igual ( aunque tampoco creo que sea lo que tú dices ). Si bien una cierta "base" conceptual de POO es, evidentemente, buena para poder cambiar de un lenguaje a otro, cada lenguaje y cada entorno tiene sus ventajas e inconvenientes sobre otros. Saber utilizar esas ventajas también es importante. Actionscript es un lenguaje mucho más relajado en muchos aspectos que Java o C#, y la orientación a objetos no es tan fuerte. Eso siempre ha sido una ventaja para nosotros, no la dejemos de lado. César Tardáguila [EMAIL PROTECTED] -----Mensaje original----- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de David Serrano Enviado el: sábado, 29 de mayo de 2004 13:00 Para: [EMAIL PROTECTED] Asunto: RE: [ASNativos] [AS2] Clase carga, LoadVars Bueno, después de leer durante 1 hora todos los posts de este hilo, creo que es conveniente que intentemos aclarar o posicionarse respecto a algunos conceptos. He leído que no es ilegal acceder a los miembros de una clase de forma dinámica en Flash. Bueno, creo que esto, aun no siendo ilegal no es bueno ni sigue el paradigma de la OOP. Creo que es mejor dejar claro este concepto a la gente de la lista porque puede llegar a producir confusiones. Es verdad que cada uno tiene una forma de programar y una forma de analizar, pero lo que uno haga no significa que sea bueno o no. Hay que tener en cuenta uno de los principios relativos a la OOP: 1) Un objeto debe ser responsable de sí mismo. 2) La encapsulación, entiende al objeto como "Black Box" o caja negra, donde sus propiedades y métodos no son accesibles directamente desde otro ámbito o clase. Bien, siguiendo el segundo principio de la OOP, flash como lenguaje orientado a objetos sigue o debe seguir este paradigma. No es que sea obligatorio, pero si recomendable y aceptado por la mayoría. Si como se dice, Flash permite acceder y crear directamente atributos y métodos de clase, no es recomendable hacerlo, y voy a explicar el porqué: Supongamos, que accedemos directamente a las propiedades (no a través de los accesors o setter/setter). Si la próxima versión de Flash no lo permitiera (como es muy posible que sea el caso), este código quedaría obsoleto y debería refactorizarse, perdiendo una de las ventajas de la OOP, que es la reutilización. Además, hay que tener en cuenta, que si bien, flash admite variables privadas y publicas, no se comportan como tal (como cualquier lenguaje OOP), ya que si fuera así, no te permitiría acceder y modificar las propiedades tan fácilmente, y el compilador daría error. Para finalizar me gustaría comentar que lo importante no es saber programar flash, sino saber programar en programación orientada a objetos, ya que esto permite poder programar en cualquier lenguaje que siga el paradigma sin importar su sintaxis, y permitiendo aprovechar su potencia en un 100%. También iba a comentar el tema de asociación-composición, pero Xavi lo ha comentado muy bien y tampoco es cuestión de rizar el rizo. Un saludo. David Serrano. -----Mensaje original----- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de Cesar Tardaguila Enviado el: viernes, 28 de mayo de 2004 10:11 Para: [EMAIL PROTECTED] Asunto: RE: [ASNativos] [AS2] Clase carga, LoadVars Oiga, Sr., su nombre me suena! ( levantando las cejas mientras masco un puro ) Es que es viernes.... Cesar Tardaguila [EMAIL PROTECTED] -----Mensaje original----- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de Javier Tardáguila Enviado el: viernes, 28 de mayo de 2004 9:48 Para: [EMAIL PROTECTED] Asunto: Re: [ASNativos] [AS2] Clase carga, LoadVars Cierto, yo estoy leyendo esto por encima porque ando de curro que no tengo tiempo ni para ir a mear, pero en cuanto pueda me voy a los archivos y me saco toda la hilera de mensajes. Por cierto, ya se que esta es una lista seria, pero respondiendo a esta parte de tu mensaje: "De todo esto deduzco que: Si La Clase tiene un miembro que apunta a otra clase, pero esta segunda clase no apunta a La Clase, la agregación es unidireccional. (La Clase usa o puede usar otra clase para lo que le interese) Si La Clase tiene un miembro que apunta a otra clase, y esta segunda clase tiene un miembro que apunta a La Clase, la agregación es bidireccional." lo siento, pero si no lo digo reviento. Si la parte contratante de la primera parte de la clase, contrata a la parte contratante de la segunda parte de la clase.......( si es que los hermanos Marx eran unos visionarios ) Bueno un poquito de humor. Que me perdonen los administradores. Un saludo. > Cesar, Sixto, Xavi, me alegra haber provocado esta discusión tan > fructífera para los que nos enteramos poco o nada de OOP (en AS2 o en > lo que sea, que algo tengo claro ya, el lenguaje es lo de menos, el > análisis es lo importante). > > Resumo unos cuantos conceptos para aclarar mis ideas y para que me > corrijáis si me equivoco y tenéis tiempo y humor: > > - Relación HAS-A de composición: > Un miembro de La Clase instancia otra clase (el dichoso owner, que > contendría la instancia de la otra clase). Creo que a esto os referís > como encapsular una clase en otra, pero no lo tengo claro: Yo por > encapsular entendía hacer que un objeto sea funcional en sí mismo, sin dependencias. > Sixto habla de "agregación", y dice que puede ser uni o bidireccional, > y que esta última forma implica que un miembro de la clase agregada > apunte a la clase que la agrega, lo cual, creo, rompería la > encapsulación tal y como yo la entendía (o sea, seguramente mal). > > De todo esto deduzco que: > Si La Clase tiene un miembro que apunta a otra clase, pero esta > segunda clase no apunta a La Clase, la agregación es unidireccional. > (La Clase usa o puede usar otra clase para lo que le interese) Si La > Clase tiene un miembro que apunta a otra clase, y esta segunda clase > tiene un miembro que apunta a La Clase, la agregación es bidireccional. > (Ambas clases están vinculadas la una a la otra, esto no lo entiendo, > o no le veo la utilidad, bueno, la utilidad sí, pero creo que rompe el > paradigma OOP). > > Por aquí entremedio salen los Listeners, que se supone son el > mecanismo de intercambio de información entre objetos (Cuando yo > cambio, te aviso si te has registrado a mis cambios). Y ya me pierdo > totalmente. Si se supone que son el mecanismo de interrelación ¿qué > sentido tiene la agragación bidireccional (otra vez), si sin > referenciarse pueden comunicarse? > > - Relación IS-A de herencia > La Clase extiende otra clase para añadirle funcionalidad. Que > sencillito suena esto ahora 8-). > > Otra cosa que me ha quedado clara es que cada proyecto requerirá de > una, otra o ambas metodologías (porque esto son metodologías, ¿no?: > modos de actuación frente a un problema concreto). Así que no os > peguéis 8-) > > Cada día más confuso, espero que santo Moock me ilumine pronto. > > Paulo. > > > > > ---------------------------------- > Lista ASNativos:[EMAIL PROTECTED] > http://www.5dms.com/listas > ---------------------------------- > -- Javier Tardáguila www.design-nation.net www.design-nation.net/es ( blog en castellano ) www.design-nation.net/en ( english blog ) [EMAIL PROTECTED] [EMAIL PROTECTED] ---------------------------------- Lista ASNativos:[EMAIL PROTECTED] http://www.5dms.com/listas ---------------------------------- ---------------------------------- Lista ASNativos:[EMAIL PROTECTED] http://www.5dms.com/listas ---------------------------------- ---------------------------------- Lista ASNativos:[EMAIL PROTECTED] http://www.5dms.com/listas ---------------------------------- ---------------------------------- Lista ASNativos:[EMAIL PROTECTED] http://www.5dms.com/listas ----------------------------------
