¡Hola a todos!
¿Qué puedo decirte Marcelo? En los últimos años no he leído ningún libro de informática, pero trataré de ayudarte con algo que se parece a esto que mencionas:
Cita:
Empezado por Delphius
...Composite define a una clase que forma una lista de otra clase que la define a la primera...
|
Es curioso, pero precisamente en este momento tengo mi Delphi 7 abierto porque estoy trabajando en una serie de clases que se asemejan a ese concepto que jamás había escuchado.
Tal vez no se trate de lo mismo, pero te expongo de manera muy simplificada mi caso:
Tengo dos clases, TSavePoints y TSavePoint, las cuales me sirven para implementar puntos de restauración (
save points). Una instancia de la primera contiene una lista de instancias de la segunda clase. Es decir, TSavePoints es una lista de objetos TSavePoint. Los mecanismos esenciales del punto de restauración (una serie de métodos virtuales llamados InternalConfirm, InternalDestroy, InternalRestore e InternalSave) se definen en la clase TSavePoint, mientras que la clase TSavePoints sólo es quien crea, agrupa y coordina los puntos.
La clase TSavePoints carecería de sentido sin la clase TSavePoint, de alguna manera podría decirse que la segunda "define" a la primera. La clase TSavePoints existe porque los puntos de restauración no pueden ser autónomos, dependen unos de otros, por lo tanto algo debe agruparlos y coordinarlos. Si creo (
salvo) sucesivamente los puntos sp1, sp2 y sp3 y posteriormente restauro el punto sp2, sp3 debe desaparecer. Un ejemplo clásico de esto son los puntos de restauración que algunas bases de datos permiten dentro de transacciones, o los puntos de restauración que tiene Windows XP para cuando algo que instalaste quedó mal y quieres revertirlo.
Un ejemplo típico de Delphi podrían ser las clases TMenu y TMenuItem. Pero insisto en que tal vez esto no tiene nada que ver con lo que tú estás estudiando porque desconozco por completo el tema de los patrones.
Cita:
Empezado por Delphius
...Se que mi falta de comprensión se debe al hecho de que no manejo el concepto de interface, sobre todo lo que en Delphi significa...
|
En cuanto a las interfaces, es uno de esos temas que empiezan con cara de "
a ver si puedes conmigo" y terminan siendo una simplonada más de programación.
Una
interfaz es una especie de definición de clase, en la cual pueden aparecer declaraciones de métodos y propiedades (como en una declaración de clase normal). La diferencia es que no le pones código a esos métodos y no puedes crear un objeto (instancia) de dicha clase. "
¿Entonces pa' qué sirve? ¿dónde va el código de los métodos?", preguntarás. Simple: el código (implementación) lo pones como parte de una clase normal.
¡Ahchis! ¿Y esa clase normal también debe declarar los métodos?
Sí.
¿Entonces pa' qué declaro la interfaz?
Para darle un nombre o "identificador" a ese grupo de métodos y propiedades y poder trabajar con dicho grupo como si fuese un objeto aparte.
Pero has dicho que no pueden crearse instancias de una interfaz.
Así es, por eso es que una clase debe
implementar sus métodos.
¿Pero entonces por qué no declaro e implemento esos métodos y propiedades nada más en la clase normal y me olvido de usar una interfaz?
Si haces eso, ese grupo de elementos perderán su esencia de "tipo de objeto" y terminarán siendo métodos y propiedades comunes y corrientes de la clase. En cambio, una interfaz sirve para "etiquetar" a diversas clases de objetos no derivadas entre sí, dándole un comportamiento común a todas ellas, como si tuvieran un nuevo ancestro común paralelo, adicional a los ancestros que ya poseen. Un objeto de clase T1 que implemente la interfaz I1, podrá ser tratado como un objeto de tipo I1. Un objeto de clase T2 que implemente la misma interfaz, también podrá ser manejado como objeto de tipo I1. Entonces ya tienes dos objetos de clases diferentes (T1 y T2), pero que para ciertos propósitos pueden ser tratados como si fueran de la misma clase; y ya sabes que cuando puedes tratar a dos o más objetos de la misma manera, tu código se simplifica. Esto es una especie de polimorfismo forzado
¡Ah!, se parece mucho a la herencia múltiple de C++.
De hecho es la forma de emplear herencia múltiple en Delphi, pero de una manera más controlada.
¿Y sólo para eso sirven las interfaces?
No, también son muy importantes para permitir que los objetos de diferentes aplicaciones en ejecución se comuniquen entre sí, incluso si dichas aplicaciones corren en diferentes máquinas y fueron escritas en otros lenguajes. Las interfaces son una manera estandarizada de conectarse a los objetos de otro programa, sin importar cómo están implementados dichos objetos. Por eso se llaman interfaces (en singular
interfaz), porque son como una ventana o conexión hacia lo que está del otro lado, pero bajo una forma que es comprensible para quien, desde este lado, lo utiliza.
Gracias Al. ¿Estarás por aquí mañana?
¡Hasta crees! Mañana es quincena.
Un IAbrazo.
Al González.
P.D. Perdón si dije alguna tarugada, no domino el tema de las interfaces.
