FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
||||
|
||||
Sugerencias para nombre de método de clase, ¿tú qué nombre le darías?
Ejemplo algo "abstracto":
En ocasiones la verificación de "Param" es tan intrínseca de la clase (en este caso "TObj"), que pareciera más adecuado (y orientado a objetos) definir en ella un método de clase que haga todo el trabajo: verificar el parámetro y crear el objeto o devolver Nil. ¿Creen que "Make" puede ser un buen nombre estandarizado para ese tipo de métodos? ¿Se les ocurre algún otro que suene más a la tarea realizada? ¿Cuál? ¿Estoy borracho de sueño y debí dormir algunas horas antes de publicar disparates? Bueno, saludos y gracias de antemano. Esta mañana, será otro día... |
#2
|
||||
|
||||
Hola,
¿MakeOrDie? En todo caso trataría (creo) de dejar claro que trata de crear un objeto, pero, que, es posible que no se termine creando. Así que "MakeOrDie", "MakeIfPossible", "MakeFromParams",... "CreateFromParams"... ¡Lo siento! ¡no soy muy bueno poniendo nombre a nada! Última edición por dec fecha: 06-03-2013 a las 09:52:22. |
#3
|
||||
|
||||
Yo voto por la tercera opción...
No, no la de "MakeFromParams", sino la de que "te vayas a dirmir un rato...." Si aun sigues con eso cuando te levantes, tal vez un "TryCreate",...
__________________
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. |
#4
|
||||
|
||||
Hola,
+1 al "TryCreate", aunque, todo esto me deja una rara sensación, como que no entiendo muy bien que uno espere "nil" de esta forma... entonces habría de comprobarse después si el objeto ha sido o no creado. Ahora bien, ¿qué tal el uso de excepciones? Se le pasan los parámetros a cierto método, y, este levanta determinada excepción si los parámetros no son válidos y el objeto no puede ser creado. ¿Qué os parece? |
#5
|
||||
|
||||
Yo tiro por la tangente.
Yo, a veces, tengo dos métodos de clase, dos procedimiento llamados "Instanciar" y "Liberar", en ellos hago lo siguiente: A esta forma de trabajar, para que se parezca a la tuya bastaría con cambiar el "Instanciar" y realizar lo siguiente
Se me olvidaba la llamada:
La opción "TryCreate" no me parece mal tampoco.
__________________
La Madurez se llama... ~~~Gaia~~~ Última edición por ozsWizzard fecha: 06-03-2013 a las 15:55:47. |
#6
|
||||
|
||||
No quería entrar en el comportamiento, pero a mi también me parece algo extraño el que al llamar a un Create, el constructor no cree nada y devuelva un nil. Además sin dar ningún otro "síntoma".
Es decir, si igualmente después del Create se tiene que preguntar si se ha creado algo, veo más natural lo que comenta David. Si hay algún problema levanto excepción y listo. Si hay que acabar preguntando (o haciendo algo), me "suena" más natural el tema de la excepción. Si al crear hay algún problema, parece lógico avisare de ello.
__________________
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. |
#7
|
||||
|
||||
Bueno, yo no he querido entrar tampoco en ese tema y mucho menos en si es necesario o no avisar de que ha habido un problema, se me ocurren ejemplo prácticos del porqué.
Vamos a verlo de la siguiente forma:
En definitiva, si te pones a buscar caso prácticos, seguro que alguno se encuentra.
__________________
La Madurez se llama... ~~~Gaia~~~ |
#9
|
||||
|
||||
En todo caso "CreateOrNil"... aunque me sigue gustando más "TryCreate". A menos que yo traduzca mal el "try"
__________________
La Madurez se llama... ~~~Gaia~~~ |
#10
|
||||
|
||||
El nombre mas comun que he visto en varios lenguajes es
Código:
getOrNone(param) Código:
ifcreate('param','defaultValue)(param)
__________________
El malabarista. |
#11
|
||||
|
||||
Realmente la forma de crear el objeto no es consistente con la práctica en Delphi. No es que sea malo romper con la práctica, más si ésta no es tan buena. Sino que puedes crear incosistencias en tu código. Pero la forma que propones es la utilizada por Python más o menos. Pero en Python, si un parámetro no valida se genera una excepción.
Con respecto al nombre de "Make", el verbo es muy general y ambiguo. En lo personal me quedaría con el Create. Saludos! |
#12
|
||||
|
||||
Muchas gracias por sus valiosas respuestas.
He tenido la sensación de estar enfocando mal el problema, pero algo me dice quizá no voy tan mal. Elevar excepciones desde el interior de un constructor es algo normal cuando no están dadas las condiciones estrictamente necesarias para que la instancia exista. Pero a veces la instancia puede o no puede existir, sin que lo último amerite generar un error o aviso. Hice un ejemplo un poquitín menos "abstracto":
Lo de Make fue por buscar un sinónimo de Create, algo que, quizá (y ahí tengo mi mayor duda) pudiera llegar a ser acuñado y con el tiempo dejar de sonar confuso o ambiguo. Una palabra que "insinúe" una acción semejante a la del constructor, pero que al mismo tiempo se diferencie de éste, entendiéndose que podemos obtener un Nil si cierta condición (que podría estar documentada) no se cumple en la llamada a ese método especial. «Oh, mire compañero, la clase tiene método Make, hay que usarlo en esta parte del programa. Según dice aquí, devuelve Nil cuando...» Me empieza a gustar el nombre TryCreate que propusieron en mensajes anteriores. TryOrNil se entiende también, pero se pierde un poco el sentido de "crear". Otro camino es que este tipo de métodos se definan con nombres más explícitos y acomodados a cada clase y situación en particular, con lo cual ya no tendríamos una candidatura a estándar. Y bueno, también está la opción de crear una función normal o de otra clase, que haga la tarea, pero creo que es más correcto que la propia clase se encargue de validar o verificar lo que a la clase concierne. ¿No creen? Bueno, a alguna conclusión habremos de llegar entre todos. ¡Saludos! |
#13
|
||||
|
||||
¿Build?
// Saludos |
#14
|
||||
|
||||
Cita:
// Saludos |
#15
|
||||
|
||||
Gracias Román.
Una hora más temprano que ayer, pongo una breve lista de posibles nombres:
|
#16
|
||||
|
||||
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. |
#17
|
||||
|
||||
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, |
#18
|
||||
|
||||
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~~~ |
#19
|
||||
|
||||
Cita:
Un objeto se crea totalmente o no se crea nada. No hay términos medios. Saludos, |
#20
|
||||
|
||||
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. |
Herramientas | Buscar en Tema |
Desplegado | |
|
|
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 |
|