Sugerencias para nombre de método de clase, ¿tú qué nombre le darías?

[[Al González]]

Ejemplo algo "abstracto":

Código Delphi [-]
  // Esquema normal, usar If:

  If { Cierta verificación de Param } Then
    // Param superó la verificación, creamos la instancia de objeto.
    Obj := TObj.Create (Param)
  Else
    Obj := Nil;  // Param no superó la verificación, asignamos Nil.


  // Esquema alternativo, usar un método de clase:

  { El método de clase "Make" hace la verificación de Param, llamando al
    constructor Create si la supera, o devolviendo Nil si no la supera. }
  Obj := TObj.Make (Param);

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...

[dec]

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!

[Neftali [Germán.Estévez]]

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",...

Código Delphi [-]
  Obj := TObj.TryCreate(Param);

[dec]

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?

[ozsWizzard]

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:

Código Delphi [-]
class procedure TObj.Instanciar(var Param: TParam; var pObj; TObj);
begin
    Liberar(pObj);

    pObj := TObj.Create(Param);
end;

class function TObj.Liberar(var pObj: TObj);
begin
   if Assigned(pObj) then
      FreeAndNil(pObj);
end;

A esta forma de trabajar, para que se parezca a la tuya bastaría con cambiar el "Instanciar" y realizar lo siguiente

Código Delphi [-]
class procedure TObj.Instanciarr(var Param: TParam; var pObj; TObj);
begin
    Liberar(pObj);

    if TObj.ValidarParam(Param) then //Siendo ValidarParam una función de clase de tipo booleana
          pObj := TObj.Create(Param);
end;

Se me olvidaba la llamada:

Código Delphi [-]
begin
   TObj.Instanciar(Param, Obj);
end;

La opción "TryCreate" no me parece mal tampoco.

[Neftali [Germán.Estévez]]

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.

[ozsWizzard]

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:

1. Tengo un objeto con varios objetos dependientes
2. En el Destroy de ese objeto contenedor tengo el siguiente código
   

   Código Delphi [-]
    
   destructor TContenedor.Destroy;
   begin
      for i := 0 to ListaObjetos.Count - 1 do
      begin
         if Assigned(ListaObjetos[i]) then ListaObjetos[i].Free;
      end;
   end;

3. cada objeto contenido tiene una misión en base a si se crea o no; ejemplo: muestra un edit si se crea o no lo muestra en caso contrario

En definitiva, si te pones a buscar caso prácticos, seguro que alguno se encuentra.

[[egostar]]

Hola

Según la lógica yo lo nombraría

Código Delphi [-]
Obj := TObj.TryOrNil (Param);

Saludos