Sixto, una duda concreta, cuando dices: "... luego cuando quisieras aplicarlo a un clip, solo se trataba de regístralo a la biblioteca con registerClass." ¿Esto hace referencia a lo habla Peter Hall aquí: http://www.peterjoel.com/blog/index.php?archive=2004_01_01_archive.xml#10755 0841406346131 que me recomendastéis el otro día, o hay otra manera? ¿Se pude asignar una clase a un elemento de la librería en ejecución? o sea, ¿puedo tener un clip vacio en mi librería y cambiarle o asignarle distintas clases y attacharlo según me convenga, o esto es ciencia ficción (además de una chapuza)? Es que según el comentario de Moock, parece que no es muy seguro usar el indocumentado "__Packages..." .
Pregunto también lo mismo que Pedro: ¿Las conferencias no se ivan a colgar en algun sitio? Javier, jajaja, sí, los Marxs controlaban de OOP más que yo, y la frasecita tiene tela, pero es que estamos entrando en el terreno de la metafísica y me dejo llevar. 8P Gracias por el código, Cesar, que qué menos que ser agradecido. Estoy aprendiendo más esta semana que en los úlitmos seis meses (por lo menos vocabulario 8-) Y sigan, sigan ustedes discutiendo, que esto está cada vez más interesante. Vaya pupurrí, no se que poner en el asunto... Bah, lo dejo como está. Paulo. ----- Original Message ----- From: "Sixto Cantolla - AzulMedia" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, May 28, 2004 12:43 AM Subject: RE: [ASNativos] Re: Clase carga, LoadVars > <-Esto cada vez se pone más dificil. ;)-> > Pues si, jejejejeje. > > <- > Tal y como yo veo las cosas, el código tiene que estar determinado por la > arquitectura, no por las funcionalidades concretas.-> > > Bueno, realmente las funcionalidades concretas son lo que hacen útil a la > aplicación. Los requisitos que ha de cumplir una aplicación son los que > condicionan el desarrollo de la misma, ya que hay que cumplirlos, y > precisamente estas funcionalidades son las que mandan. Aún así, insisto en > que la OOP se definió como paradigma, por que podemos modelar mediante el > lenguaje cualquier equivalente del mundo real, de manera que no es cuestión > tanto de definir la arquitectura según las funcionalidades, sino mas bien > definir mediante el lenguaje una solución a un problema complejo. Como en la > vida real hay objetos que son similares y los cuales solo se diferencian en > unas pocas propiedades. Esto quiere decir que pueden tener una clase base, y > luego especializarlos mediante la herencia. De todas formas esta frase te ha > quedado algo confusa. > > <-Y nadie me va a convencer ( al menos por ahora ) de que es mejor extender > clases como String, y hacer que toda la arquitectura de tu aplicación > actual > ( y de las siguientes que desarrolles ) esté mediatizada por que ya no > puedas utilizar "String" sino "miString" porque en determinado momento > necesitaste implementar un método para eliminar las comillas de una cadena > de texto. Y otra vez más, probablemente el de String sea el peor ejemplo > para esto, pero piénsalo con MovieClip .-> > > Esto desde luego que no es muy correcto, el que yo decida extender la clase > string con unas funcionalidades concretas no quería decir que yo me ate a mi > nueva clase, por que cuando hablo de extender, me refiero a herencia, y no a > modificación de los prototype, como creo que ya había quedado claro, de > manera que una vez que extienda la clase string, tengo dos clases, la String > original que usare cuando no necesite las funcionalidades extra que le he > añadido, y la clase myString, que hereda de string y que me da una serie de > ventajas cuando necesito realizar ciertas operaciones con la cadena que > contiene. > En el caso del Movieclip es exactamente igual, y esta igual de claro, cuando > yo tengo que especializar la clase base de movieclip, no estoy modificando > la clase original, ya que exclusivamente heredo de ella, y de esa manera, > consigo que las funcionalidades estándar me las gestione la clase superior, > y el efecto draggable me lo provee mi clase recién escrita. Sin embargo, si > hablamos de modificar el prototype, seguiría diciendo lo mismo, ya que aún > en AS1 podías heredar de MovieClip y extenderla, sin necesidad de modificar > el objeto nativo de Flash, luego cuando quisieras aplicarlo a un clip, solo > se trataba de regístralo a la biblioteca con registerClass. Ya dije que es > perjudicial modificar el prototypado de una clase ya desarrollada, pero si > recomendable extenderla mediante herencia. > > <-Eso probablemente facilite la encapsulación, pero no facilita el > mantenimiento, al menos desde mi punto de vista. ¿ Qué pasa si ahora tienes > que volver a extender "miString" ? ¿ O todas las cadenas de la aplicación > tienen que ser instancias de la misma clase ? ¿ No es mejor hacer que > determinadas funcionalidades sean externas a las clases nativas ?. Es > exactamente el mismo caso que con la física de un movieclip.-> > > Pues exactamente lo contrario, el mantenimiento se facilita, por que cuando > vas a modificar o mejorar algo, no tienes que hacer el seguimiento de las > funcionalidades extras que tiene un objeto, ya que las contiene el mismo, de > hecho, tu modelo de desarrollo a mi me daría muchos quebraderos de cabeza, > ya que mi primera intención al coger un código, es buscar las > funcionalidades dentro de la clase, no en una clase externa, que puede que > tenga muchas funcionalidades que a mi no me interesan en el nuevo > desarrollo. Desde luego si quiero especializar aún mas miString, no hay > ningún problema, al final tendré tres clases con una finalidad distinta, que > es para la que han sido diseñadas, en ningún momento veo el problema de > volver a extender una clase ya extendida (refiriéndome a herencia de clases, > no a modificación del prototipado), realmente es para lo que apareció OOP, > para la reutilización de las clases mediante la herencia, no tiene otra > razón de ser. > > <-En cuanto a la comparación con Java, que es algo que parece que > últimamente > hemos tomado todos con muchas ganas, no es válida. Esto no es Java, y no lo > será, espero que nunca. Creo que alguna que otra vez hemos discutido > también > sobre eso por aquí. Y recordemos también que en flash el compilador te > puede > decir lo que quiera, y que tú puedes hacer en tiempo de ejecución lo que te > dé la gana. Y eso no es ni mejor ni peor. Es así, simplemente.-> > > La comparación con Java, sencillamente venia a colación respecto a OOP, como > lenguaje completamente OOP y que sigue unas especificaciones rígidas al > respecto, podía decirte lo mismo de c#, c++, etc.. no es que para mi sea una > moda. Y evidentemente no es Java, por que sino no se llamaría Flash, pero si > sigue las bases de la OOP, y si tu quieres realizar un buen diseño de > software, habrás de acotarte a las normas de la OOP, que no están así por > capricho, sino por que facilitan el desarrollo de las aplicaciones. > En cualquier lenguaje es el compilador el que emite los avisos, y > posteriormente en ejecución no se realizan casi ninguna comprobación(excepto > en lenguajes interpretados), la única diferencia es que el compilador de > otro lenguaje no te pasa ningún código que no cumpla las normas, mientras > que flash si esta escrito en sintaxis de AS1 te lo pasa y puedes trampear. > El que sea así, no quiere decir que no sea peor. Yo siempre me quejé de > flash por que no controlaba si el tipo de una variable coincidía con lo que > le asignabas, no por que me guste que lo haga, sino por que al final tenia > problemas de asignación que hasta que lograba depurar me volvía loco. La > implementación en flash del tipado fuerte, es un paso adelante en el > lenguaje, ya que lo hace mas robusto y mas accesible a la gente (evita > errores de bulto, que de otra forma serian difíciles de localizar). > > <-Sobre mi ejemplo del clip draggble. Yo no he hablado de métodos > estáticos. > Simplemente, la funcionalidad de hacer el clip draggable y de interactuar > con el resto de objetos del escenario no puede estar implementada en el > propio clip. El hecho de no estarlo, no sólo no rompe la encapsulación, > sino > que la aumenta, ya que el mundo del juego no sabe ( porque no tiene porqué > saberlo ) ni qué se está moviendo, ni porqué, ni sobre todo, de qué manera. > Precisamente, este caso está determinado por la arquitectura global del > proyecto. Más aún, está motivado porque ese elemento draggable ha de ser > común al menos a cinco juegos distintos ( pero totalmente distintos ).-> > > Vuelvo a discrepar al respecto, no aumenta la encapsulación de ninguna de > las maneras el hecho de que se implementen funcionalidades que son > responsabilidad de un objeto fuera de él, ya que estas cargando a otro > objeto con responsabilidades que no son suyas. > El encapsulamiento de una clase consiste en que esta expone una serie de > métodos para acceder a los datos, ocultando a cualquiera el como se tratan > los datos internamente, quiere decir que se ha de comportar como una caja > negra, sabemos como hacerla funcionar, pero no sabemos como funciona, esto > favorece la reusabilidad de una clase por motivos evidentes. > En el caso de un coche y de un conductor, la responsabilidad del movimiento > es del coche, aunque el conductor sea el que active ese movimiento, de una > forma gráfica, seria absurdo que el conductor tuviera que empujar el coche > para que se moviera, es el coche que tiene motor el que se encarga de > moverse, siendo responsabilidad del conductor accionar el movimiento y > llevar la dirección. En el caso de tu objeto que es dragable, es exactamente > igual. El mundo del juego no tiene ni que saber que ese objeto es dragable, > eso lo sabe solo el mismo, ya que es su responsabilidad. > Acerca de la comunicación con el juego de ese objeto usaré otro ejemplo, > también de conductores. Si alguien que conduce quiere avisar a otro > conductor de que está ahí, para no sufrir un accidente, de manera que > utilizara el pito (método interno de la clase), que emite un sonido que se > propaga por el aire (clase externa de comunicación), y los que estén cerca > les llegará el sonido llamando su atención (conductores suscritos al aire > cercano al conductor). al que le corresponda, le prestará atención y > realizara una acción, y al que no dejará pasar el mensaje. Evidentemente en > este caso la comunicación es responsabilidad del aire, aunque el acto de > comunicar algo le corresponde al conductor. Espero que quede claro lo que > quiero decir. > > <-Sobre el XMl, no veo porqué el parseo tiene que ser responsabilidad de > dicho > objeto. ¿ Y si se carga un XML de disco para luego enviarlo a otro servidor > ? ¿ Y si lo que quiero es cargar cinco árboles XML con estructura > totalmente > distinta ? ¿ Tengo que extender 5 veces la clase XML ?. Precisamente, en > este caso, una vez más, es la arquitectura la que marca el camino a seguir. > ¿ Porqués está mal planteada la aplicación por el hecho de que una clase > cargue un XML, y devuelva su contenido, en forma de XMLNode a otra clase > distinta ?-> > > No tiene que estar necesariamente mal el que una clase cargue el contenido y > lo devuelva a otra clase, lo que no es recomendable es que uses LoadVars sin > haberlo extendido cuanto menos, para que tenga una propiedad que apunte a la > clase que lo agrega, de esta manera no violas ningún principio de OOP, > aunque puedas hacerlo, al fin y al cabo hablamos de como se realiza un buen > diseño de software y no como se pueden hacer las cosas. > De todas formas, en el caso de que se cargue un XML de disco y se envie a un > servidor, extendería XML de la misma manera, ya que sería la clase de > comunicaciones y seria su responsabilidad recuperar el XML, comprobar que > esta bien formado y enviarlo al servidor. Al respecto del segundo ejemplo, > pues si es una posibilidad extender 5 veces la clase XML modificando el > método onload, para parsear el contenido, al fin y al cabo, donde mejor > tratar un XML que dentro del objeto que lo contiene, para después exponerlo > a la clase que va a contener el modelo de datos, a no ser que vayas a usar > directamente el XML, caso de algunos componentes, en el que el modelo espera > esa estructura, y la usa sin transformarlo a otro modelo de datos. Aunque > eso si, hay que tener claro que todo depende de como asignes las > responsabilidades. > > <-En cuanto a la pregunta y la respuesta, no SON un movieclip. Se presentan > utilizando un MovieClip, que es algo totalmente distinto. Me sorprende que > tú, que hablas de acoplamiento, me propongas hacer que un movieclip, como > elemento de presentación, contenga en sí mismo también datos que no son > propios de la presentación. Aunque se pueda hacer, el MovieClip no está > para > eso. > > mcTextClip agrega MC. > > Implementa un interfaz de comunicación con el resto del juego, por lo que > para el juego todo es transparente y está perfectamente encapsulado.-> > > Bueno, la separación de vista, modelo y controlador o vista, modelo y > presentador es un patrón, de manera que no necesariamente en tu ejemplo se > tiene que adscribir MovieClip a la vista ya que no dijiste que se tuviera > que implementar bajo un patrón MVC, de todas formas por la formulación que > tenias en tu ejemplo, asignabas al mismo objeto la responsabilidad de dar > funcionalidad extra al movieclip, contener los datos y reaccionar a los > eventos del MovieClip, por ello te hice el planteamiento. > Aún utilizando en tu aplicación de forma general el patrón, no estaría mal, > ya que realmente estamos hablando de una presentación casi puramente, y los > datos aunque los contenga es para su uso propio en la representación, el > encargado de desplegar las preguntas y respuestas seria el que se comunicara > con el modelo de datos y pasara los datos necesarios a cada pregunta y > respuesta. > Aún así, y si quisiéramos implementar dentro del mini control el patrón MVC, > casi seria mas sencillo, y el MovieClip seguiría heredando la funcionalidad > extra. Mi planteamiento entonces seria: > > QuestionViewer extends MovieClip =Responsabilidades: > fade > la modificación del color del texto > habilitación/deshabilitación del click de ratón). > Propiedades: > Añade una propiedad que lo comunica con el controlador > > QuestionController = Responsabilidades: > Instanciar el Viewer > Instanciar el model (dependiendo de que tipo sea pregunta o respuesta) > Traslada una referencia del modelo a la vista, para que esta pueda > consultarlo directamente. > > AskModel = Responsabilidades: > Contener la información específica a esta pregunta y servirlas cuando > es pedida. > Almacenar el color del texto. > > AnswerModel extends AskModel = Responsabilidades: > Añade la información que no es compartida con AskModel. > > Aún usando la primera solución, no existiría alto acoplamiento, ya que el > alto acoplamiento se da normalmente cuando un objeto ha de saber demasiados > detalles internos de otro para su funcionamiento, es decir, rompe el > encapsulamiento de otro objeto. Como es una sola clase, es difícil que no > haya alto acoplamiento, ya se sabe, conócete a ti mismo, jejejejejee. > > <-¿ Ves cómo sí podemos discutir sobre esto durante días ?-> > > Claro que si, y eso redundara en que ambos mejoremos en nuestro trabajo > diario, lo preocupante es que no discutiéramos sobre el tema, así que espero > tu respuesta, jejejeje. > > Un saludo, > > Sixto > > > ---------------------------------- > Lista ASNativos:[EMAIL PROTECTED] > http://www.5dms.com/listas > ---------------------------------- > > ---------------------------------- Lista ASNativos:[EMAIL PROTECTED] http://www.5dms.com/listas ----------------------------------
