Destruir objetos

[[Crandel]]

che locos, dejen de hablar todos al mismo tiempo que no se entiende nada. A ver si sacan turno para escribir

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

Empezado por jhonny

Se que como parámetro hay que pasarle un Objeto y al de el TStringList un string pero lo que trato de preguntar es ¿Que tan rápido(Eficiente) es buscar la posición de un objeto con este método? ¿Es igual de rápido que buscar el nombre de un objeto en un TStringList?

La diferencias es el método de Acceso.
NOTA: Habñlamos siempre de TStringList que podamos Ordenar y sin duplicados (opara poder usar el método Find con búsqueda binaria).

En el TObjectList cuando buscas con (IndexOf), se hace un recorrido desde el primer objeto mirando si es el que buscas. Si no ese ese, incrementa el índice y vuelve a comparar; Así hasta encontrarlo o llegar al final de la lista.

En TStringList (ordenado y sin duplicados) al hacer un Find se coge el elemento central de la lista y se compara. Si es igual, se compara si es mayor o menor y se busca en la mitad de la lista correspondiente empezando por el elemento central y así sucesivamente.

En media en un TObjectList harás un número de comparaciones para buscar un elemento igual a la mitad de los elementos;
En una lista de 10 harás 5 comparacoiones, en una de 100 harás 50...
10 -> 5
100 -> 50
1000 ->500
10000 - 5000
...

En media en una búsqueda binaria (la que hace TStringList) debes aplicar logaritmo.
10 -> 4
100 -> 7
1000 -> 10
10000 -> 13
....

Si te fijas la proporción se aleja cuantos más elementos hay.

[jhonny]

Empezado por seoane

Pongamos un ejemplo jhonny. Si yo tengo una lista de objetos, y quiero acceder a un objeto sabiendo solo su nombre, no podría usando el método que tu indicas.

mmm, si tienes razón en fin todo depende de para que se necesite, quizá mi cerebro se niega a creer que no venga de fabrica un método en esta clase para buscar el objeto por su nombre.

[jhonny]

Muchas gracias por la extensa explicación Neftali, todo esta mas claro que el agua.

[roman]

En mi experiencia, a pesar del entusiasmo inicial que alguna vez tuve por el ObjectList, en general es una clase con muy pocas ventajas sobre el StringList, ya que la más de las veces requerimos referenciar a los objetos que contiene por algún identificador. La ventaja de un ObjectList, que sería la de su manejo automático de la destrucción de los ojetos, es realmente muy nimia. Una simple rutinita:

Código Delphi [-]
procedure FreeList(var List: TStringList);
var
  I: Integer;

begin
  for I := 0 to List.Count -1 do
    List[i].Free;

  FreeAndNil(List);
end;

Vamos, qué es más cómodo con ObjectList, lo es. Pero muy poco más cómodo, y la enrome ventaja de acceder a los elementos por medio de un identificador sobrepasa con creces lo otro.

// Saludos

[[Lepe]]

Quizás estemos usando el TObjectList cuando no deberíamos usarlo.

Me explico: TObjectList está pensado para guardar una lista de objetos, su principal cualidad (por decirlo así) es encontrar los objetos por su posición (índice) o bien por su dirección (puntero de TObjects), si no necesitamos estas características, quizás no deberíamos usar esta clase.

Tenemos una lista de Edits creados en tiempo de ejecución y cuando el usuario teclea debemos localizarlo, ¿para qué complicarnos la vida añadiendo un nombre único a cada TEdit y después usar ese nombre para encontrarlo? Si tenemos el objeto Sender ya podemos encontrar por ese puntero (haciendo uso de TObjectList.IndexOf) el Tedit en cuestión dentro de nuestra lista (no creo que vayamos a tener 10.000 TEdits creados en un Form ). Usar FindComponent será más costoso que el TobjectList.IndexOf, precisamente porque habrá más controles creados en el form, y su búsqueda tardará más.

Otra pega que le veo al StringList, es precisamente tener un único identificador para localizar el objeto, ¿qué ocurre si quiero localizar un Objeto por alguna propiedad que lleva dentro dicho objeto?, pues tenemos la misma desventaja que al usar TObjectList, tenemos que hacer un bucle, recorriendo todos los objetos que tiene el StringList y buscando la dichosa propiedad.

Yo al menos, jamás he derivado de TStrings o TStringList para obtener funcionalidades extras, sin embargo, si lo he hecho de TObjectList para tratar mis propios objetos sin tener que aplicar moldeo de tipos en mi programa principal. Para mí, ya es muy clarificador el código resultante y si le veo utilidad hacerlo.

El método Sort de un TObjectList es también muy útil, ya que creando varias funciones de ordenamiento permite realizar auténticas virguerías con los objetos creados.

Aquí un ejemplo práctico:
TFolders es un TObjectList, cada elemento vuelve a ser un TObjectList (TFolder) , por último, cada elemento de este último TObjectList es un TObject a secas (TPathElement), que tendrá una serie de propiedades inherentes a cada archivo, como:
- ruta relativa de una dada
- ruta absoluta
- tamaño del archivo
- etc.

Código Delphi [-]
{------------------------------------------------------------------------------
  TFolders son las carpetas  que se van a crear

  Es una lista que contiene una lista dual

  TFolders
     |--------- TFolder
     |             |------- Archivos encontrados (TPathElement)
     |             |------- Archivos encontrados (TPathElement)
     |             |------- Archivos encontrados (TPathElement)
     |
     |--------- TFolder
                   |------- Archivos encontrados (TPathElement)
                   |------- Archivos encontrados (TPathElement)

-------------------------------------------------------------------------------}

// posibilidades de ordenación:
{ Por el nombre de archivo (scaption)
   por el tamaño de carpeta (sValue)
   sin ordenación (sNone)
}
  TSort = (sCaption, sValue,sNone);
   
  TFolder = class(TDualList)
    public
     function Size :Int64; // suma el tamaño de todos los archivos que contiene
  end;

  TFolders = class(TObjectList)
    private
      function GetItem(Index: Integer): TFolder;
      procedure SetItem(Index: Integer; const Value: TFolder);
    public
      function Add(AObject: TFolder): Integer;
      procedure Sort(const SortBy:TSort;const Order:TSortOrder);overload;
      procedure Sort(funcion:TListSortCompare);overload;

      property Items[Index: Integer]: TFolder read GetItem write SetItem; default;
  end;

Saludos

[roman]

Empezado por Lepe

Quizás estemos usando el TObjectList cuando no deberíamos usarlo.

Llevas razón y son interesantes los ejemplos. No obstante, me gustaría apuntar algunas cosas:

1. TStringList tiene el método IndexOfObject que funciona igual que el de TObjectList (TList). Hace un ciclo en busca del apuntador, y con ello encuentras fácilmente un objeto.

2. TStringList tiene el método CustomSort, que funciona igual que el Sort de TList: se le pasa como parámetro una función de comparación. En el caso de TObjectList, la función recibe dos apuntadores (básicamente los objetos) y en el caso de TStringList recibe dos índices con los cuales es inmediato obtener los objetos.

3. En la búsqueda, estamos igual, como ya observaste.

El ejemplo que pones, es muy interesante, pero hay que notar que ahí ya estamos hablando, no de un lista realmente, sino de una estructura ramificada. Pero aún así, usando TStringList también podríamos hacerlo, con la ventaja extra, por ejemplo, de poder colocar el nombre del archivo y así agilizar las búsquedas por nombre.

// Saludos

[mamcx]

Creo que en tal caso una lista hash seria un mejor candidato. Aunque de forma lastimosa Delphi no viene de fabrica con una bien pensada y la que ahi esta "escondidad" y como que no es muy eficiente...

[[Lepe]]

No voy a hacer contrarreplica de todo, las ideas están mostradas y en definitiva eso es lo que importa.

Empezado por roman

Pero aún así, usando TStringList también podríamos hacerlo, con la ventaja extra, por ejemplo, de poder colocar el nombre del archivo y así agilizar las búsquedas por nombre.

Si te fijas el objeto final se llama TPathElement, no se llama TFoundFile, TFile o similar, esto es porque realmente lo que importaba en este caso son las distintas rutas de cada archivo:
- ruta original
- ruta relativa a partir de una profundidad específica
- ruta de destino inicial
- Nombre del archivo a secas para mostrar al usuario.
- ruta final donde se copiará el archivo (devolverá la concatenación de: ruta de destino inicial + ruta relativa+ Nombre de archivo)

El tener alguna de esas propiedades fuera del objeto me hace trabajar más para mantener sincronizada la informacion, sobre todo dando la posibilidad al usuario de cambiar un archivo de carpeta mediante drag&drop que implicaría actualizar ese String fuera del objeto.

Saludos