Herencia en Eiffel Gerardo Rossel -

Transcripción

1 Herencia en Eiffel Gerardo Rossel - grossel@bigfoot.com La intención del presente trabajo es discutir algunos aspectos de la herencia en el Lenguaje Eiffel. Los aspectos a discutir trataran temas de redefinición, junta, múltiple herencia y soporte de correctitud sobre la herencia. La herencia introduce las relaciones Padre e Hijo y su clausura transitiva ntecesor y Desciente. La inclusión del nombre de una clase en la cláusula de herencia de otra determina que aquella es padre de esta última: Class C inherit... es padre de C. La noción de herencia no admite ciclos, así si es antecesor de entonces no puede ser antecesor de. Esto es así en cualquier lenguaje basado en clases. daptación de Features La adaptación de Features se realiza mediante la redeclaración lo cual incluye dos importantes conceptos: refefinición y efectivización. La redefinición implica un cambio en la implementación, signatura o especificación de la original; mientras que efectivización es proveer la implementación de un deferred (abstracta) en el padre. Estos conceptos se suman al de junta de s y la indefinición de s (undefining). Veremos después como se trata el caso de la herencia repetida utilizando los conceptos mencionados y otros que surjan según se necesiten. Renombre El renombre de s heredadas es una de las facilidades del sistema de herencia provisto por el Lenguaje Eiffel. Como veremos más adelante esto se relaciona con la múltiple herencia pero además permite adaptar los nombres al contexto de la nueva clase. La sintaxis es: as C as D Se puede insertar una parte para cada padre. No se permite dos renombres de una misma para la misma clase padre. Redefinición La redefinición es un mecanismo que nos permite generar una nueva implementación de una heredada. Se puede combinar renombre y redefinición: class inherit f as newf redefine newf newf...is class

2 El renombre no cambia la sino su nombre final mientras que la redefinición no cambia el nombre sino su implementación, signature o especificación. El mecanismo de anchored (anclaje) permite la redefinición de s en forma implícita. Efectivización Efectivización es la redeclaración como efectiva de una declarada en un antecesor como deferred. Es decir transformar en concreta una abstracta. En la efectivización no es necesario incluir esta en la cláusula de redefinición. Lo cual es lógico ya que la en cuestión nunca fue "definida". Se debe hacer la salvedad del caso en el cual la nueva aún permanezca deferred o sea que solamente se cambia su signatura. Las clases deferred pueden eventualmente implementar algunas s y otras no, la condición necesaria y suficiente para que una clase sea considerada deferred es que posea al menos una deferred. Las clases deferred no pueden ser instanciadas. Un tipo de clase deferred que cumple un rol de suma importancia en la construcción de abstracciones útiles a la modelización e implementación de software son las clases de comportamiento(behavior class). Un ejemplo de ellas sería la clase ITERTOR la cual implementa y especifica mecanismos de iteración. Undefining La abstractización de s efectivas se conoce como undefining. Esta característica es útil en contextos de múltiple herencia donde exista un conflicto de nombres y no se redefinan ni renombren las s implicadas. Una declarada como deferred en el padre o abstractizada mediante el mecanismo de undefining se dice que es heredada como deferred en otro caso se dice que es heredada como efectiva class inherit _efectiva as _abstracta undefine _abstracta redefine _anstracta _abstracta(x:i, y: H) is deferred -- class Mecanismo de Junta Este mecanismo soporta un concepto muy importante en el modelo orientado a objetos de Eiffel: la fusión de abstracciones. La fusión de abstracciones se utiliza cuando diversas abstracciones provenientes de varias clases necesitan ser combinadas. Supongamos que tenemos dos s heredadas de distintas clases pero que nos interesa que se comporten como una nueva, en este caso el mecanismo de junta se implementaría mediante dos renombres

3 class C inherit f as nuevaf g as nuevaf Otro caso se presenta cuando heredamos varias s con y nos interesa una sola versión: class D inherit g as f undefine f h as f C undefine f -- class D En este caso estamos utilizando la implementación de la h en como junta de g, h y f provenientes de,,c y con el nombre f. Herencia repetida La múltiple herencia presenta la propiedad de que en determinado momento se puede heredar de una misma clase varias veces por distintos caminos. Los gráficos nos muestran dos ejemplos comunes: C D

4 Los gráficos nos muestran casos clásicos de herencia repetida. En el primer gráfico la clase D hereda de dos veces una por medio de C y otra por medio de. En el otro ejemplo la clase hereda dos veces de. La regla de nombres de s nos dice que: una clase que hereda diferentes s del mismo nombre desde diferentes padres es invalida. Eiffel nos da una forma de resolver conflictos mediante la siguiente regla de la herencia repetida: una heredada repetidamente bajo el mismo nombre representa una simple; versiones heredadas bajo distintos nombres representan s separadas replicadas desde el antecesor común. La herencia repetida presenta problemas potenciales: redeclaración sobre caminos separados, duplicación de atributos, conflicto con derivaciones genéricas. El caso de la redeclaración puede ser resuelto mediante el renombre (el compilador Eiffel no permite que se violen las reglas) tenio en ese caso todas las versiones redeclaradas con un nuevo nombre. Si por ejemplo la clase de la figura tiene una f que es redeclarada en y en C entonces en D se presenta el problema de heredar dos s con el mismo nombre lo cual es invalido, en este caso se necesita renombrar alguna o ambas s. Debemos aclarar que esta solución se considera buena por ahora, pero que no alcanza debido a las asignaciones polimórficas que trataremos después. El caso de los atributos es similar, supongamos siguio la segunda figura que la clase tiene un atributo at en ese caso solo trá un atributo at ya que según la regla de herencia repetida se representaría como un solo atributo. Pero sí en se renombra at como at1 y at2 (en cada cláusula de padre ) entonces en se trán dos atributos. class inherit at as at1 ; at as at2 ; Nuevamente se plantea el problema de las asignaciones polimórficas. Para enterlo pongamos un ejemplo: supongamos en el caso planteado en la primera figura con una f en la clase a redeclarada en y en C y renombrada en D como fb y fc respectivamente. Si tenemos el siguiente código: d:d!!dl; d.bf; d.cf no habría problema ya que se ejecutaría en el primer caso la versión heredada de y en el segundo la versión heredada de C. Pero si se plantea el siguiente código:

5 a:, d:d;!!d; a:= d; a.f En este caso la asignación polimórfica es permitida ya que D conforma con según las reglas de tipos, pero surge el problema de determinar que versión de f se ejecutará. Esta ambigüedad se resuelve en Eiffel mediante la incorporación de la sentencia select. En el renombre se debe especificar cual se selecciona como la a aplicar en asignaciones polimórficas: class D inherit f as bf select bf C f as cf La utilización de la sentencia select no es optativa, cada vez que se presenten conflictos de binding dinámico debido a la herencia de dos o más declaraciones de s es obligatorio seleccionar una. El conflicto sobre derivaciones genéricas se presenta cuando una clase hereda de dos o más clases que a su ves heredan de un clase genérica pero instanciando el parámetro genérico en diferentes tipos. Para que la repetida herencia sea valida es posible utilizar las soluciones presentadas anteriormente: sobreescribir a través de la abstractización, (undefining), utilizar el select para permitir replicación, el sharing es imposible ya que la elección de una puede causar incompatibilidad de tipos. En el caso de la abstractización hay que tener una precaución adicional ya que al sobreescribir se necesita que las signaturas conformen, pero en el caso de derivaciones genéricas puede haber conflicto. Si las clases intermedias instancian el tipo genérico en tipos que no conforman entonces se debe abstractizar todas las s heredadas en conflicto y proveer una redeclaración nueva, tenio en cuenta que la nueva versión debe proveer tipos que conformen con los originales, en el peor caso NONE. Herencia y serciones Para que una clase sea correcta debe respetar las invariantes de sus padres. Esto se puede expresar por la regla: Las invariantes de todos los padres se aplican a la clase en si. Si la clase no tiene invariante se considera la invariante true lo que implica que se aplican las invariantes de sus padres. El caso de la redeclaración de s presenta un tratamiento especial, se debe tener cuidad debido al polimorfismo y al binding dinámico. En la redeclaración si se necesita incorporar aserciones se incorporan con la siguiente sintaxis: require else alternativa_precondicion ensure then extra_poscondicion Para la precondición se toma la misma o más débil, es decir si las precondiciones anteriores fueran: pre 1,...,pre n y la nueva alternativa_precondicion la semántica sería: alternativa_precondicion or else pre 1 or else...or else pre n Para la postcondición se toma las misma o una postcondición mas fuerte, es decir si las postcondición anteriores fueran: pos 1,...,pos n y la nueva extra_precondicion la semántica sería: extra_precondicion and then pos 1 and then... and then pos n

6 Tener una precondición más débil no impone ningún nuevo requerimiento a los clientes originales, mientras que una postcondición más fuerte garantiza un resultado que satisface las originales, tal cual lo espera el cliente (el término cliente se refiere a una entidad que toma servicios de la clase). Eiffel no soporta métodos de clase ya que toma una distinción conceptual entre clases y objetos, pero permite definir rutinas once, las cuales se ejecutan solo una vez, y utiliza la herencia múltiple para acceder a propiedades de otras clases. Para poder mostrar algo por pantalla en JV se utiliza la clase System que cuenta con atributos declarados como static, en Eiffel bastaría con heredar de ella. Smalltalk soporta métodos y variables de clase pero además variables globales. Lo visto en este apunto no cubre completamente el tema de herencia en Eiffel, pero sirve como una introducción general a la problemática y nos muestra como la múltiple herencia puede tratarse con elegancia dando un lenguaje de programación altamente flexible sin perder cualidades que facilitan la construcción de software correcto y robusto. uenos ires, Mayo de 1998