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

[ozsWizzard]

Empezado por Neftali

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

He sido yo

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):

Código Delphi [-]
procedure TForm1.FormDestroy(Sender: TObject);
begin
  XFile1.Free;
  XFile2.Free;
  XFile3.Free;
end;

[[Delphius]]

Empezado por ozsWizzard

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):

Código Delphi [-]
procedure TForm1.FormDestroy(Sender: TObject);
begin
  XFile1.Free;
  XFile2.Free;
  XFile3.Free;
end;

¿Donde está el problema? Free es un método seguro. Si las instancias XFile1, XFile2 y XFile3 no fueran válidas (nil) Free lo detectará y no intentará liberar algo que ya fue liberado o bien nunca fue creado.

Un objeto se crea totalmente o no se crea nada. No hay términos medios.

Saludos,

[ozsWizzard]

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.

Código Delphi [-]
procedure TFrmPruebas.Button1Click(Sender: TObject);
var
   q: TSqlQuery;
begin
   q.Free;
end;

[dec]

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:

Código Delphi [-]
var
  module : TMyModule;
begin
  module := MyModules.GetModule( 123 );  

  if module <> nil then
  begin
    // Module is a valid object for us
  end
  else
  begin
    // We can't found a module with ID 123
  end;
end;

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:

Código Delphi [-]
var
  params : string;
  module : TMyModule;
begin
  params := 'My params';

  module := TModule.Create( params );

  if module.HasValidParams() then
  begin
    // We have a valid object here, with the right params
  end
  else
  begin
    // We have a valid object here, but with wrong params
  end;
end;

¿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?

[[Delphius]]

Muy bien dicho David, has ido a lo que yo quería hacer llamar la atención. Como tu has dicho:

creo que el "nil" tiene toda la lógica,

Y yo por algo había comentado antes:

Ahora bien, si en verdad nil es un resultado realmente válido (tiene un significado real y está aceptado en el contexto)

Al, es primordial entender ¿que significa para ti que el objeto sea nil? ¿Tiene algún propósito?

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,

[dec]

Empezado por Delphius

Muy bien dicho David, has ido a lo que yo quería hacer llamar la atención. Como tu has dicho:



Y yo por algo había comentado antes:



Al, es primordial entender ¿que significa para ti que el objeto sea nil? ¿Tiene algún propósito?

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,

Yo apunté también lo propio (lo siento Delphius, no leí tus anteriores mensaje), pero, ¿serviría de algo lanzar la excepción en el constructor del objeto? Me refiero a si tiene sentido en el contexto en que nuestro amigo Al trabaja. Además no me queda muy claro el uso de excepciones tal que así:

Código Delphi [-]
try
  obj := TMyObject.Create();
except
  on E : Exception do
  begin
    // Manejamos la excepción, pero,...
  end;

  // ¿qué pasa con el código situado aquí debajo?

end;