FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
#1
|
|||
|
|||
Cita:
Ya lo había pensado, pero (siempre hay un pero), cuando accedes al campo (FDomain) desde fuera de la clase, solo tendrás acceso a los integrantes de la clase base (TDomain) en forma directa. Si quieres tener acceso a los integrantes de la clase descendiente tendrás que especificarlo en forma explicita, por ejemplo: Suponiendo que TDomainString es descendiente de TDomain. La idea es que dicho acceso sea transparente: Saludos... |
#2
|
||||
|
||||
Accediendo una propiedad privada como si fuera una publica? Uno de los conceptos fundamentales de la OO es el *encapsulamiento*. Estas yendo contra el viento y por eso sufres.
Y la forma que pones de ver domain es absurda. Casi siempre un programador se pone a dar vueltas a una aparente restriccion tecnica es porque su diseño esta deficiente. Osea: Hacks son un code-smell (una indicacion poderosa, 90% de los casos, que estas contra el viento, en vez de solucionando un genuino problema)
__________________
El malabarista. |
#3
|
|||
|
|||
Cita:
Cita:
|
#4
|
||||
|
||||
Ok, podrias explicar que es lo que estas tratando de hacer? Cual es el objetivo de este codigo?
__________________
El malabarista. |
#5
|
|||
|
|||
Podrías explicar que quieres haer con el código que pones?
Saludos
__________________
Si tienes una función o procedimiento con diez parámetros, probablemente hayas olvidado uno |
#6
|
|||
|
|||
Las clases que expongo son parte de la capa de datos de una aplicación, mas específicamente TField almacena la definición de un campo de la base de datos, junto con TDomain que almacena las características del dominio al que pertenece dicho campo, ya explicado lo anterior, lo que quería lograr era asignar a Tfield que representa al campo, el tipo de dominio que este posee, el cual puede ser de distinto tipo (string, integer, etc), debido a esto pensé que usar tipos genéricos era buena idea para almacenar el tipo de dominio especifico de cada campo. Se que se puede usar herencia de la clase base TDomian para conseguir el mismo efecto, pero haciendo esto necesariamente hay que hacer cast para acceder a la clase descendiente, cuestión que quería evitar para hacer transparente el acceso a los datos a los clientes de dichas clases. La aplicación cliente no tiene porque saber que tipo de Dominio tiene un campo, si las restricciones de ingreso de dicho campo, las cuales son accesibles desde las clases descendientes...
Espero haberme hecho entender.. Saludos. |
#7
|
||||
|
||||
La clase TField ya existe en Delphi. De todos modos, segundo a mamcx y creo que no esta bien diseñado
|
#8
|
||||
|
||||
Hola doctorhd.
Opino igual que AgustinOrtu. De la clase TField podes obtener los datos de las columnas relativas a la tabla asociada a un TDataSet. (O he perdido el rumbo y no estoy entendiendo lo que intentas hacer...) Saludos
__________________
Daniel Didriksen Guía de estilo - Uso de las etiquetas - La otra guía de estilo .... |
#9
|
||||
|
||||
Ok, estas haciendo un ORM . Hacer un ORM es de lo primero que hago cuando aprendo un nuevo lenguaje (y he hecho, con re-escrituras, un monton!) y justo ahora estoy diseñando un lenguaje relacional... y si vieras lo particularmente complejo que puede volverse el asunto.
El punto es que las BD y la OO no se llevan bien (tienen un "impedance mismatch"): http://clubdelphi.com/foros/showpost...76&postcount=2 ---- La parte mas importante del modelo relacional, es entender que una tabla es un valor, no un objeto!. Un valor como "1", "true", "hello world", Array(1, 2, 3), o sea como si en cada "momento" es un pantallazo estatico de la informacion, como una constante. Por lo tanto, una tabla es como un array, solo con multiples columnas. ---- Te voy a ahorrar un monton de tiempo y muchas vueltas de cabeza y te digo que: 1- Usa un ORM que ya este hecho. No creo que ninguno realmente sea bueno, pero sera mucho mejor que hacerlo. Te lo digo despues de intentar varios ORM en Delphi 2- El modelo que tiene sentido y exito en la OO es hacer como este proyecto: https://github.com/StackExchange/dapper-dot-net Código PHP:
Nota como la interface de Dapper no le huye al SQL. Ademas, es mas rapido que los ORM tradicionales de .NET (obvio: No esta re-implementando gran cosa). La unica cosa sofisticada es que puede usarse el LINQ, que es algo facil en .NET. No se que tanto se pueda con Delphi hacer eso, pero creo que una version moderna de Delphi es muy viable. Estudia dapper y lee sobre los micro-ORM que te abriran la mente y simplificaran mucho la vida. P.D: Delphi basicamente permite hacer algo muy simple: Usa TClientDataset para obtener resultados, y una clase plana para ejecutar SQL. Un micro-ORM asi se puede resolver con unos, digamos, 7-8 funciones y eso es todo. Lo que hace un micro-ORM es solo mapear una tabla a una clase, y ojala una clase "plana": Osea= Sin metodos, funciones ni propiedades complejas. Quizas de extra, hacer un ayudador para hacer query o para generar SQL. Ya que como te explique, una tabla es un valor, esto es lo que realmente tiene sentido: Código PHP:
Esto significa que si tienes una vista o un SQL que retorna campos que no son identicos a las clases que ya tienes... no haces herencia (bueno digamos que no herencias profundas, y a lo sumo, solo heredas propiedades y YA), no haces arboles complejos de objetos, nada. Crea una clase tipo "record" adicional y ya. Maso asi:
Nota que (aparte de usar un TClientDataset, que sigue siendo demasiado pero ya esta inventado) este es la UNICA forma que *realmente* tiene sentido y *verdaderamente* refleja lo que es la BD. Una tabla no tiene herencia, no hay funciones, etc. Campo1:Tipo es Campo1:Tipo eso es todo. Esto te ahorra mucho tiempo, hace el codigo mas simple, claro y veloz. Igual, si quieres hacer clases que encapsulen estas otras ya es otro tema.
__________________
El malabarista. Última edición por mamcx fecha: 07-10-2015 a las 01:42:17. |
#10
|
||||
|
||||
Lo que explico Mario (si se me permite llamarte por tu nombre ) es basicamente lo que hago (intento) desde casi que inicio en el mundo del OO + Relacional
En las versiones mas modernas de Delphi es mas sencillo todavia, ya que podes crearte la clase que el te dijo, un TObjectList<TTuClase> y enlazarla por LiveBindings. En un plumazo tenes separada la logica de tu aplicacion, del acceso a los datos, de la presentacion visual Yo creo lo mejor es dar un pequeño paso mas, y pedirle a una clase que te retorne la instancia en cuestion de la forma que el lo propone. Es decir, tus clases de negocio en un principio no tienen porque saber que van a ser guardadas en una BD Si sigo con el ejemplo del Dog
Esa clase no sabe nada de que se la va a guadar en una BD para que sea persistente. Eso quiere decir que tu clase es testeable sin depender de ninguna BD. Podes probar que tanto las propiedades Name, como Age, como el metodo Run funcionan bien usando Unit Testing. Luego, para levantarlo de una BD, harias algo como esto
Tambien es posible que crees otra clase, como comenta Mario, que no tenga ningun metodo, simplemente los campos que mapea de la BD. Entonces, para crear un Dog, podrias tener un constructor que recibe como parametro una instancia del TDatabaseDog de donde tomar el Name y el Age El tema es bastante complejo pero siempre me gusta este tipo de debates |
Herramientas | Buscar en Tema |
Desplegado | |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Class Helpers sobre Genericos.. | yapt | OOP | 1 | 24-04-2011 16:06:17 |
Procedures Genericos con Parametros de Controles.... | Kenobi | Varios | 23 | 21-11-2007 00:42:41 |
Listbox con items genericos | ANG4L | Varios | 2 | 11-05-2006 03:54:37 |
Parametros sql genericos | AbcXxx | Conexión con bases de datos | 2 | 10-11-2005 00:31:59 |
... 100 tipos... | Jure | Humor | 0 | 18-03-2004 14:24:30 |
|