Re: [Grulic-dev] Problema con factory

Página superior
Adjuntos:
+ (text/plain)
Eliminar este mensaje
Responder a este mensaje
Autor: Guillermo Marraco
Fecha:  
A: Lista de desarrollo de software libre
Asunto: Re: [Grulic-dev] Problema con factory
2009/2/13 Edgardo Hames <>:
> 2009/2/13 Guillermo Marraco <>:

...
> Buscando en Google .net get all objects given class, el primer hit
> devuelve esto:
>
> http://www.eggheadcafe.com/software/aspnet/33209268/get-all-objects-of-a-cert.aspx


Parece interesante. No lo he leído aún. Gracias por el link.

> No sé si aplica, pero de nuevo, me parece que no viene por el lado del
> factory la mano.

...
>> Claro, pero eso abre la puerta, a que cualquiera implemente esa
>> interface, en una clase que no tiene nada que ver. Digamos que vos
>> tenés un algoritmo que quiere desactivar todos los Button mientras se
>> ejecuta algún procedimiento. Entonces alguien crea un objeto
>> clickeable, y por conveniencia implementa Button. Entonces ese objecto
>> sigue siendo clickeable, y el usuario lo activa, arruinando el
>> procedimiento que se está ejecutando. (Es un ejemplo traído de los
>> pelos que acabo de inventar).
>
> Exacto. Y a eso cómo lo vas a resolver cuando las clases que hereden
> de tu clase base tampoco cumplan con los contratos? ;-) El compilador
> de .Net controla esas cosas?


Sí. Si escribís por ejemplo una función con parametro "mustoverride",
el compilador te insulta hasta que lo implementes. Si nó, no compila
ningún heredero.

>> O digamos que tengo 100000 objetos Button, y necesito buscar uno. Lo
>> busco en un array ordenado, pero resulta que ese button específico no
>> está en el array porque el que lo codificó no tenía idea de que tenía
>> que agregarlo al array.
>
> Podrías contar el problema específico que intentás solucionar buscando
> los objetos en ese array? .Net debe tener un Object Space donde buscar
> objetos y mucho más optimizado que la versión que hagas a mano.


Quiero crear una pattern genérica; hacer una clase virtual que pueda
agregar a cualquier programa, para heredar de ella y así crear una
factory que no se pueda "evadir".

me ha pasado con frecuencia que después de un año, necesito modificar
un código, y me largo directamente a implementar una clase. No anda, y
unas horas después "descubro" que tenía que crearla con una factory.

Quiero acabar con eso de una vez por todas.

Quisiera una solución que no dependiera de net (una pattern), para
poder usarla en cualquier lenguaje, pero parece que c# y VB te hacen
la vida bién difícil si querés hacer eso (y no querés usar
reflection).

Eso puede significar una de dos cosas:
1- Los lenguajes tienen una falla de diseño fundamental.
2- Hay algo profundamente errado en el concepto de lo que intento hacer.

Me inclino por lo primero (y me parece que c++ tiene el mismo defecto)

> Si lo que buscás es un invariante de clase, podrías definirlo con un
> método de la clase base y todas las instancias de las clases que
> heredan deberían cumplirlo. Así, en cualquier método dónde estés
> esperando una instancia de la clase base, simplemente llamás al método
> del invariante.
>
> Se entiende la idea?


Lo que creo que necesito es una factory, de una clase heredable, que
me ayude en el futuro a no tropezar con la misma piedra (de olvidarme
que esa clase tenía una factory agregada).

--
Saludos,

Guillermo Marraco
__________________
Si no eres parte de la solución, eres parte del precipitado.