> http://www.object-arts.com/ > > El sitio quedo muy bueno !
Sipo! Alexandre > > > > De: [email protected] [mailto:[email protected]] En > nombre de GallegO > Enviado el: Thursday, September 30, 2010 9:33 AM > Para: [email protected] > Asunto: Re: [clubSmalltalk] Consulta sobre modelo > > Hola: > > Sin hacer mucho laburo yo sacaria de los accessors a i.v. la llamada al > componente. Tambien removeria todas las sucesivas llamadas a las globales por > un metodo implementado en la superclase que devuelva la interfaz. Incluso eso > puede hacer un lookup dinamico de la interfaz mas apropiada partiendo del > nombre de la clase donde es solicitada. > > El initialize lo dejaria que setee las propiedades basicas sin hacer el > render o creacion efectiva en la interfaz hasta que yo se lo diga. Imaginate > que esto es util al momento de recrear todo el modelo, por ejemplo podrias > grabar el image con el modelo instanciado, salir volver a entrar y que todo > se encuentre como antes sin mucho esfuerzo. > > Todos los defaultXxxx, si te gusta dejalos. Yo prefiero no poner tanta cosa > si no hace falta, es decir, cuando la probabilidad de redefinir esos metodos > en subclases es infima, entonces tener un #defaultXxx para cada default me > parece que no es necesario. Fijate. Hay otra opcion que es tener una > coleccion de decorators, fijate el pattern Decorator. > > Los metodos que hacen contacto con la interfaz los pondria en otra familia, > por ejemplo #setAttenuation: o como mas te guste. > A estos QUIZAS los llamaria desde un metodo #create o #render o algo asi. > > Tambien podria usarse un pattern visitor. Para mi el visitor es más elegante > y la verdad en distintos usos siempre nos dio buenos resultados, pero, a > veces siento que me aleja un poco de lo que quiero hacer realmente en ese > momento.Quizas es la opcion a implementar para refinar la cosa una vez que > tenes claro como debería andar. > De todas formas no estoy seguro si para tu problema aplica ese pattern o > conviene otra cosa. > > Espero que alguien ayude si sabe más. > > Saludos > GAllegO > > El 29 de septiembre de 2010 15:51, Jose Gregoris <[email protected]> > escribió: > Hola Gallego > > Gracias, si, así lo tengo implementado y anda ok. > Otra cosa relacionada a esto. > Cuando creo un objeto Light este debe tener algunos valores por default. Lo > que hago es implementar un #default que retorne una instancia con dichos > valores. > Algo como: > > Light(class)>> default > ^self new initialize > > Y tengo mensajes que retornan valores por default, algo como: > > Light>>defaultColor > > ^Color red > > > Ahora el #initialize es así: > > Light>>initialize > "Initialize the receiver" > > super initialize. > index := TV3DEnvironment current lightManager > createDirectionalLightOfColor: self defaultColor > direction: self defaultDirection. > self > attenuation: self defaultAttenuation; > specularLevel: self defaultSpecularLevel; > ambient: self defaultAmbient; > diffuse: self defaultDiffuse; > name: self defaultName; > position: self defaultPosition; > range: self defaultRange; > enable: true; > isCastShadows: true; > isManagedLight: true; > isForLightmapping: false > > > Donde por ejemplo #attenuation: hace esto: > > Light>>attenuation: aPoint3D > "Private - Set the receiver attenuation color." > > attenuation := aPoint3D. > TV3DEnvironment current lightManager setLight: self index attenuation: > aPoint3D > > Me queda la sensación de que el #initialize es medio raro. > El sobre todo como seteo las propiedades, es decir llamando a cada mesaje > como #attenuation. > Por lo regular uno setea los colaboradores sin hacer uso de los accessors > dentro del #initialize. Pero en este caso, sino lo hago así me quedaría un > #initialize más grande y más feo. > Algo como: > > Light>>initialize > "Initialize the receiver" > > super initialize. > index := TV3DEnvironment current lightManager > createDirectionalLightOfColor: self defaultColor > direction: self defaultDirection. > attenuation:= self defaultAttenuation. > TV3DEnvironment current lightManager setLight: self index attenuation: > attenuation > ................ > > Que opinas ? > > > saludos > > > > --- El mié 29-sep-10, GallegO <[email protected]> escribió: > > De: GallegO <[email protected]> > Asunto: Re: [clubSmalltalk] Consulta sobre modelo > Para: [email protected] > Fecha: miércoles, 29 de septiembre de 2010, 14:49 > > > Hola: > > Podrias usar algun objeto tipo TVEngineManager con una coleccion o variables > o dict con cada uno de los engines instanciados. Incluslo a mismo implementas > la finalizacion para que finalice los demas engines. > De esa forma, si implementas un registro podes tener mas control sobre las > interfaces instanciadas y de que manera vas haciendo los "release" ya que a > veces no da buenos resultados (o no es posible) dejarlo librado a la logica > de la finalizacion transparente por GC que proponen los frameworks COM. > > Saludos > > El 28 de septiembre de 2010 22:41, Jose Gregoris <[email protected]> > escribió: > Hola > > Tengo una duda sobre como modelar lo siguente. > Tengo un COM llamado ITVLightEngine , que se encarga de crear luces y > modificar todas las propiedades de las mismas. > La interfase solo retorna un index a una luz y sobre eso quiero modelar un > objeto Light. > El tema es que ITVLightEngine es un singleton y todo lo que modifique sobre > mi objeto Light debo hacerlo por medio de la interface. > Si fuera una DLL no tendría dudas, ya que podría hacer algo así: > > Light>>color: aColor > "Set the receiver color" > color:= aColor. > XXXDLL default setColor: aColor > > Aquí tengo un COM y hay que tenerlo instanciado. Podría tener una global y > usarlo de la misma forma que una DLL. > El tema es que esto se repite con unas cuantas interfases COM y no me gusta > como queda con globales. > > > Hay alguna forma estandar de modelar esto ? Tipo pattern > Sugerencia ? > > saludos kiko > > > > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > > http://www.clubSmalltalk.org > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > > http://www.clubSmalltalk.org > > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > > http://www.clubSmalltalk.org > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > > http://www.clubSmalltalk.org > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > > http://www.clubSmalltalk.org -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
