FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Creo que alguien ha comentado el CreateOrNil. No suena muy bien, pero es descriptivo 100%. Recordemos que Delphi ya cuenta con un FreeAndNil.
Es por si ya te estabas decidiendo... Para que tengas un poco más de dudas...
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#2
|
||||
|
||||
Hola Al, creo que el concepto o palabrita que buscas es Materializar, o Materialize en inglés.
Este término se emplea en los frameworks de persistencia, y a mi ver Materializar no es propio de la persistencia en bases de datos, sino en su forma abstracta. Asi que no veo el porqué no aprovecharlo. Ahora, respecto a la utilidad del código, si me lo permites quisiera preguntar algo ¿Donde o que clase "cliente" lo utilizará o invocará al método en cuestión? ¿O es que no existe un lugar concreto donde usarlo? Como seguramente ya has visto un diseño de resultado booleano (objeto|nil) llevará a que al final se deba hacer una comprobación posterior, o bien hacer uso de try. Ahora bien, si en verdad nil es un resultado realmente válido (tiene un significado real y está aceptado en el contexto) y no deja al objeto que cumple el rol del creador en un estado inconsistente no hay problemas. Pero si este nil en realidad no responde a un resultado aceptable y tolerable lo correcto sería que no se devolviese nil sino que se eleve una excepción. Como nombre podría sugerir EUnmaterializedException o ETXFileUnmaterializedException. De este modo en donde se lo invoque simplemente se trabaja directamente con try y poder volver a un estado de calma sin estar alterando el flujo principal del código. Por otro lado, Al... me huele a que estás diseñando una Fábrica. Saludos, |
#3
|
||||
|
||||
Cita:
Tampoco ha puesto el nombre que sugerí de "Instanciar", no le habrá gustado, jeje. Por otra parte, con la forma en la que crea los objetos, este trozo de código que ha puesto Al, petaría (daría una excepción):
__________________
La Madurez se llama... ~~~Gaia~~~ |
#4
|
||||
|
||||
Cita:
Un objeto se crea totalmente o no se crea nada. No hay términos medios. Saludos, |
#5
|
||||
|
||||
Tienes, razón, cuando es nil no peta, sorry.
Entonces me he molestado en hacer una Liberar que no sirve pa na... Ahora, si se intenta liberar algo que nunca se creó pero que no está iniciado a nil, sí que peta. Lo siguiente peta.
__________________
La Madurez se llama... ~~~Gaia~~~ Última edición por ozsWizzard fecha: 07-03-2013 a las 15:23:40. |
#6
|
||||
|
||||
Hola,
Me surgen muchas dudas con este asunto. Dudas que no van a ningún sitio, avisados quedáis. Al cabo de darle algunas vueltas me pregunto, ¿puede un objeto ser "nil"? Y me respondo: tal vez sí, cuando busquemos un objeto que puede o no haber sido creado, pero, no, si de lo que se trata es de crear dicho objeto. Es decir, yo veo el siguiente código "válido" y de hecho he escrito mucho código de esta forma:
En el código de arriba, puesto que no estamos creando un objeto sino tratando de asignar uno (posiblemente) existente, creo que el "nil" tiene toda la lógica, puesto que el método "GetModule" retornará "nil" si no puede encontrar un objeto o el objeto mismo. Ahora bien, si de lo que se trata es de saber si un objeto se puede crear, correctamente, en base a ciertos argumentos, entonces yo escribiría un código similar a este:
¿Se entiende por dónde voy? Nosotros pasamos los parámetros conque contemos (tal vez sean válidos, tal vez no lo sean) al constructor de nuestro objeto, y, este, por ejemplo, proporciona un método "HasValidParams", que, podremos usar para comprobar si el objeto de hecho se ha creado en condiciones... con los parámetros correctos. De esta forma nos olvidamos del "nil", nos olvidamos con un método de clase que nos retorne una instancia del objeto mediante ciertos parámetros (¿podré usar el constructor sin parámetros o los necesitaré también?) y es el propio objeto, conocedor de los parámetros que necesita, quien nos dirá si está listo para usarse o no. ¿Cómo lo veis? |
#7
|
||||
|
||||
Muy bien dicho David, has ido a lo que yo quería hacer llamar la atención. Como tu has dicho:
Cita:
Cita:
Porque como lo ha dejado en claro en el ejemplo David, si la idea es garantizar o evaluar si hay cierta consistencia, quien tiene la información para hacerlo es el creador o el objeto en si mismo. Esto conduce a que para hacer algo entonces se puede disponer de un método que lo compruebe, y ahora si ya en base a estos resultados decidir que o no hacer. Y como dije antes, si nil no es una opción a considerar sino una situación fuera de lo esperado los lineamientos de la OO indican que lo sano es elevar excepción. Saludos, |
#8
|
||||
|
||||
Cita:
|
#9
|
||||
|
||||
Cita:
-------------- Volviendo al tema, es algo que implementaré en un par de clases de GH Freebrary. Cuando esté listo lo subiré y ya me dirán si estoy haciendo bien las cosas. Descarto los nombres que llevan la palabra Create o Instantiate porque son demasiado "fuertes" en el sentido de que parece que forzosamente se creará un objeto. Y lo del AndNil / OrNil los veo como recursos léxicos baratos; lo identificadores debieran llevar lo menos posible preposiciones, conjunciones y similares (hago uso de ellos en contadas ocasiones). Saludos. |
#10
|
||||
|
||||
Cita:
Respecto al código de ejemplo, me hago la misma pregunta que tu. ¿Que pasa allí abajo? Al, no es que esté mal o bien... sino que es diferente. Si no es mucha molestia, ¿Podrías concretar un poco más? Y como dije antes... me gustaría saber que significaría un resultado nil. Creo que ello ayudaría a entender mejor el panorama y ver alternativas. Aunque admito que mi ración de neuronas despiertas del día son escasas... tengo un diagrama de estados para una clase que acaparó demasiados recursos y mi cerebro no ha logrado restablecer la electricidad Saludos, |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Encontrar objeto por su nombre, encontrar metodo, ejecutar metodo | coso | Trucos | 7 | 02-09-2011 00:23:13 |
Cambiar el nombre de la clase. | rauros | Varios | 2 | 02-08-2008 20:56:44 |
Crear formularios a partir de su nombre de clase | kes | .NET | 6 | 21-02-2008 08:06:07 |
Crear Objeto por su nombre de clase | jlrbotella | OOP | 2 | 08-01-2008 23:44:37 |
nombre de variables de una clase | Mariana | OOP | 8 | 25-10-2005 17:48:34 |
|