Cita:
Empezado por mamcx
Asi como lo expresas, entonces me parece que es bueno seguir tal como es FileStream. Crear TArrayConverter si el archivo no se puede leer carece de sentido, mientras que operar sobre TArrayConverter puede no siempre tener problemas, asi que en cada metodo se evalua que hacer.
Mejor dicho:
Código Delphi [-] TArrayConverter = class private FFile: TFileStream; .. .. public //Aqui se hace lo de LoadFile. si esto falla, el objeto //no tiene razon de existir constructor Create(FileName: string); destructor Destroy; override; procedure LoadMatrix(AMatrix: TAMatrix); procedure LoadVector(AVector: TAVector); procedure SaveMatrix(AMatrix: TAMatrix; OnDir: TArrayOrientation); procedure SaveVector(AVector: TAVector); end;
Asi que quien llama a TArrayConverter con el archivo X solo tiene 2 opciones: Se puede o no operar sobre el archivo, si no se puede, ya haces como has dicho.
Si el objeto TArrayConverter existe, los errores son solo probables y el objeto reacciona de acuerdo.
Asi se captura de forma muy explicita lo que estas diciendo, sin complicar la logica interna del objeto. Ademas, mientras exista TArrayConverter se asume que el archivo esta en uso, lo que anula la variable de InUse que existe ahora porque TArrayConverter esta en un estado potencialmente dual: Tiene o no acceso?
Si entiendo bien lo de punto 1 & 3, entonces no veo porque pasas la matriz, en vez de retornarla tal como indique el archivo, o sea:
Código Delphi [-]function LoadMatrix():TAMatrix;
Ademas, si estas invocando de multiples sitios ese metodo, tendras problemas de concurrencia y tendrias que aplicar bloqueos u otra opcion para asegurar el acceso concurrente.
Es mas simple cuando los objetos son inmutables, y la informacion no se comparte (crea un cuello de botella). Mientras no se muchisimos datos, es muy rapido recrear una matriz y que cada parte del programa tenga su propia copia sabiendo con certeza que nadie la va a alterar. |
Muchas gracias mamx (no recuerdo bien si tu nombre era Mario, y a mi me gusta en lo posible dirigirme más en forma personal) por tu valioso aporte y ayudarme.
De lo que estoy entendiendo de tu propuesta, es hacer de TArrayConverter una especie de Adapter del TFileStream y que en caso de poder crear una instancia de TArrayConverter proceda a utilizarla. De ser así en realidad no soluciona el mayor problema: que no se pueda crear el TArrayConverter es lo mismo que no se pueda crear el TFileStream.
Tal diseño directamente pone en evidencia que no tiene sentido la clase y directamente se haga uso de TFileStream ¿no crees?
Entonces las clases que eran clientes de TArrayConverter, que directamente, hagan uso de TFileStream.
Si yo estoy entendiendo mal el concepto por favor hazmelo saber.
La intención de contar con TArrayConverter es que ésta pueda centrar el trabajo común de leer y guardar de archivos. Otros módulos/clases tienen ya sus propios juegos de matrices y vectores. Entre ellas se comparten algunas estructuras comunes, y otras son propias. Cada módulo/clase aplica sus instrucciones sobre estas estructuras y varias son de gran importancia e interés poder materializarlas en un archivo para usos posteriores.
Debido a ello es que vi natural el que exista una instancia de TArrayConverter a modo singleton que reciba las estructuras de cualquiera de estos módulos/clases y haga lo que mejor sabe hacer.
No consideré prudente que un LoadMatrix() regrese el tipo de dato TMatriz como sugieres debido a que esto condiciona a que el conflicto de intereses entre quien es el dueño de la matriz y no incluirle lógica que ya es más propia de otras clases.
Por cuestiones de operatoria y diseño es raro que se necesite un intento de leer y/o guardar archivos de forma concurrente o simultáneo. Generalmente se da cierto orden secuencial. Pero por seguridad, y para esos casos en que tales archivos sean grandes (según pruebas algunos archivos si que serán grandes... entre los 4MB a 10MB en promedio pero puede darse situaciones de mayor tamaño), es que vi sano el añadir la propiedad InUse o alguna tipo flag que indique que el objeto está ocupado trabajando en ese momento. De ese modo pretendía dos cosas:
1. Que TArrayConverter cree el TFileStream y lo libere cuando se necesite trabajar con algún archivo (recién me percato que posiblemente sea un error disponer de un atributo privado)
2. Que al disponer de esta propiedad InUse permita cierto "relajo" a la aplicación y permita darle respiros ante la cantidad de operaciones que se realizan entre cada lectura/guardado de archivos.
Cita:
Empezado por Al González
Hola Marcelo.
Cuatro cosas:
1. Gracias por regresar al foro. Da gusto ver cómo durante el último año han estado integrándose y reintegrándose muchos colegas en el Club. Muy de la mano, es evidente que el rescate de Delphi se va consolidando (y por añadidura el repunte de otros lenguajes Object Pascal). 
2. En México tienes abiertas la puertas de mi humilde hogar, si te agrada la idea y te es posible viajar, no tienes más que avisar. Y si es necesario buscamos la forma de facilitarte el traslado. Entre nosotros hay mucho código y conocimiento que podríamos compartir presencialmente. En fin, es una invitación a que te desconectes aunque sea unos meses de aquel ambiente.
3. Sostengo los comentarios técnicos que escribí hace varios años en el hilo que refieres, incluso ahora estoy más convencido de ellos.
4. Si este fin de semana no me distraen mucho acá, revisaré con detenimiento tu caso y responderé aquí con lo que pueda ayudar.
Saludos.
Al. |
Hola Al, gracias por venir en mi ayuda. Pido disculpas por haberte molestado en forma privada pero es que ya mi cabeza no trabaja tan bien después de haberme mandado cerca de 5000 líneas de código en otros módulos previos a éste. Y sumándose a que por cosas de la vida ya he perdido mucha práctica al estar bastante alejado de la programación.
Si bien tengo más presencia en los últimos tiempos en DA, no quiere decir que no estime a algunos compañeros. Como te dije: la comunidad Delphi es una.
Te agradezco la invitación, y admito que tengo ganas de buscar otros aires. Ganas no me faltan de ir a México y visitar a toda la pandilla, pero por ahora no podrá ser. Ya en los próximos días debo volver a casa, acá tengo a conocidos que me están dando apoyo pero también me ponen en ultimatum para que concrete para éste Lunes 1 (fecha en que posiblemente viaje).
Ni modo, no es fácil explicar a quien no está en el tema que un sistema no puede estar a medias. No es que se puede dejar como esté y que ande.
Deberé regresar y ver el modo de terminarlo allí.
No pensé que esto me tomara tanto tiempo. Necesito mínimo otra semana más si no hay más imprevisto y todo sale a la perfección.
Te agradezco cualquier recomendación.
Les comento a ambos que en lo que estoy pensando es aplicar una lógica que siga este diseño:
Código Delphi
[-]procedure TArrayConverter.LoadMatrix(...)
var File: TFileStream;
begin
try
File := TFileStream.Create(...);
try
finally
File.Free;
end;
except
end;
end;
Lo que estoy divagando es ver como adaptar el algoritmo que puse en mi primer post a este esquema lo más limpio posible. ¿Que piensan?
De este modo alguna clase que llame a ésta haga algo como:
Código Delphi
[-]procedure TOtraClase.HacerAlgo;
begin
HagoAlgoConEstaMatriz(LaMatrix);
try
Conversor.SaveMatrix(LaMatrix, NombreDelArchivo, Orientacion); except
E: EFileOperation do
....
end;
Y la versión análoga para una lectura.
¿Como lo ven?
Saludos,