La Cara Oculta de Delphi 6

36 La Cara Oculta de Delphi 6
type
// ¡¡¡Siguen faltando métodos importantes!!!
TTostadora = class(TObject, IAparatoElectrico, IProducto)
// …
protected // Métodos definidos por IProducto
function PrecioProducto: Currency;
function TiempoGarantia: Integer;
function IProducto.Precio = PrecioProducto;
function IProducto.Garantia = TiempoGarantia;
// … etcétera …
end;
La clase TTostadora ya no define los métodos Precio y Garantia que necesitaba IProducto,
pero sí define PrecioProducto y TiempoGarantia, con los prototipos adecuados.
Entonces le echamos una mano a la interfaz, para que sepa que PrecioProducto corresponde
a su método Precio, y TiempoGarantia a su Garantia.
Usted podría preguntarse para qué complicarnos, aparentemente, la vida de esta
forma: si sabíamos que TTostadora iba a implementar IProducto, deberíamos haber
dado nombres correctos a los métodos desde el primer momento. Pero es ahí donde
está el fallo de razonamiento. En la programación “real” es muy posible que un método
de implementación de interfaces haya sido definido tiempo atrás en una clase
ancestro. En aquel momento recibió un nombre diferente, pero ahora reconocemos
que es un buen candidato para asociarse a un método de cierta interfaz.
De todos modos, el motivo más importante para contar con una cláusula de resolución
de métodos es la posibilidad de que una clase implemente simultáneamente dos
interfaces, y que existan métodos comunes a ambas con el mismo nombre. Veamos
dos casos concretos, muy sencillos, pero que ilustran dos estrategias diferentes:
1 Alguien ha definido la interfaz IVela, no para las velas de los barcos, sino para las
fuentes de luz utilizadas en las cenas románticas. La interfaz IVela declara el
método SetEncendido. Más tarde, algún genio taiwanés concibe la idea kitsch de la
clase TVelaElectrica, que debe implementar las interfaces IAparatoElectrico e IVela.
Naturalmente, encender la vela corresponde al mismo acto físico que encender el
aparato. Podemos entonces crear un único método SetEncendido en TVelaElectrica;
no necesitaremos entonces cláusula de resolución alguna. La “esencia” de la vela
se ha fundido con la “esencia” del aparato eléctrico, y por ese motivo comparten
la implementación de varios de sus métodos.
2 En el segundo caso, las “esencias” no se mezclan. Tomemos las interfaces IConductor
e IPoliciaTrafico: ambas definen una propiedad Multas; en realidad, definen
los dos métodos de acceso correspondiente, pero me referiré a la propiedad para
simplificar. Paco es un objeto de la clase TPoliciaTrafico, que implementa las dos
interfaces mencionadas, porque un policía de carreteras debe también conducir.
Las multas de IConductor se refieren a las que sufre el propio policía cuando está
fuera de servicio, mientras que las de IPoliciaTrafico hacen referencia a las que él
inflige a los demás. Por lo tanto, los métodos de implementación deben ser
completamente independientes. La clase podría definir, por ejemplo, GetMultas-