Introducción a la herencia

Transcripción

1 Departamento de Informática Universidad de Vallalid Programación III.I.T.I. de Sistemas Herencia 1 Contenis Programación III.I.T.I. de Sistemas Introducción a la herencia Contenis Definiciones Jerarquías de herencia Polimorfismo Tipo estático y dinámico Ligadura dinámica Clases y métos diferis Problemas asocias al polimorfismo Genericidad restringida Félix Prieto Curso 2008/09 Programación III.I.T.I. de Sistemas Herencia 2 Una clase ancestro Programación III.I.T.I. de Sistemas Herencia 3 Una clase desciente class POLIGONO create Acceso contar: INTEGER Número de vértices perimetro: DOUBLE is Suma de las longitudes de los las muestra is Representación en pantalla Modificación rota (c:punto;a: DOUBLE) is en torno a c con ángulo a traslada (a,b:double) is a en horizontal y b en vertical {NONE} Implementación vertices: LINKED_LIST[POINT] Puntos que lo definen Class POLIGONO class RECTANGULO POLIGONO redefine perimetro create Creación (c:punto;s1,s2,a:double) is Creación con centro c, las s1 y s2 y ángulo a con respecto a la horizontal Acceso la1, la2 : DOUBLE diagonal : DOUBLE Longitudes específicas perimetro: DOUBLE is Suma de las longitudes de los las Result:= la1 2 + la2 2 Class RECTANGULO Programación III.I.T.I. de Sistemas Herencia 4 Primeras definiciones Programación III.I.T.I. de Sistemas Herencia 5 Jerarquía de herencia de las figuras Llamaremos clase desciente de C a: la propia clase C cualquier clase con una clausula D nde D es desciente de C Diremos que B es desciente propio de C si es desciente suyo y ambas son distintas También utilizaremos expresiones como ancestro Los descientes disponen de todas las características de sus ancestros Los descientes pueden redefinir características de sus ancestros (redefine), aunque con ciertas restricciones (frozen, compatibilidad entre interfaces, programación bajo contrato) La condición de méto de creación en los ancestros no se mantiene en sus descientes Programación III.I.T.I. de Sistemas Herencia 6 Jerarquía de herencia de SmartEiffel Programación III.I.T.I. de Sistemas Herencia 7 Polimorfismo GENERAL PLATFORM ANY Polimorfismo es la habilidad de las referencias para estar conectadas a objetos de tipos distintos El número de tipos a que puede estar conectada una referencia está limita por las reglas que se deducen de la herencia Estas limitaciones pueden ser vistas desde distintos enfoques NONE

2 Programación III.I.T.I. de Sistemas Herencia 8 Límites al polimorfismo (mensajes) Programación III.I.T.I. de Sistemas Herencia 9 Límites al polimorfismo (conformidad) En una llamada x.f nde el tipo de x está basa en una clase C debe ocurrir que f sea característica de uno de los ancestros de C Las restricciones al polimorfismo deben garantizar que al ejecutar un código como x.f el objeto referencia por x sea capaz de responder al mensaje f Tampoco podemos mandar al objeto mensajes que no entería x, esto es, los declaras en sus descientes Al «disfrazar» un objeto mediante polimorfismo perdemos su tipo real. Podemos tratar de recuperarlo mediante un intento de asignación (?=) x:c sólo puede usarse para referenciar a objetos creas a partir de una clase desciente de C Programación III.I.T.I. de Sistemas Herencia 10 Límites al polimorfismo (instancias) En caso de tipos no genéricos un tipo T es conforme con un tipo U si y sólo si la clase base de T es desciente de la clase base de U En caso de tipos genéricos un tipo T es conforme con un tipo U si y sólo si la clase base de T es desciente de la clase base de U y cada parámetro actual utiliza para derivar T es conforme con el correspondiente parámetro utiliza para derivar U Una conexión de fuente x y objetivo y es válida si y sólo si el tipo de x es conforme con el tipo de y Programación III.I.T.I. de Sistemas Herencia 11 Tipo estático y dinámico Una instancia directa de una clase C es un objeto consegui en tiempo de ejecución mediante una clausula de creación create x, con x de tipo C Una instancia de C es un objeto instancia directa de algún desciente de C Una entidad de tipo basa en C sólo puede ser conectada en tiempo de ejecución a instancias de C Las entidades, identificares en el texto de una clase, tienen tipo estático y dinámico. El primero es fijo mientras el segun puede variar en tiempo de ejecución Las referencias, que sólo existen en tiempo de ejecución, tienen el tipo dinámico del objeto al que están conectadas (o NONE si la referencia apunta a Void ). El tipo de las referencias es variable Los objetos apuntas por las referencias tienen sólo tipo dinámico, pero es el tipo con el que fueron creas y no puede cambiar Programación III.I.T.I. de Sistemas Herencia 12 Formas de ligadura Programación III.I.T.I. de Sistemas Herencia 13 Ligadura dinámica En el código de un méto pueden aparecer llamadas como p.perimetro con p:poligono Disponemos de s definiciones del méto, una en POLIGONO y otra en RECTANGULO Gracias al polimorfismo el objeto que recibe el mensaje puede ser de cualquiera de los s tipos Cuál de las s versiones del méto se ejecutará? ligadura estática: La asociada al tipo estático de x ligadura dinámica: La asociada al tipo dinámico de x Cada lenguaje etermina el tipo de ligadura que será utilizada En Eiffel se utiliza por defecto la ligadura dinámica Forzamos la ligadura estática utilizan frozen En una llamada x.f la versión del méto realmente ejecutada se determina en tiempo de ejecución La versión del méto elegida es la definida en la clase base del objeto que recibe la llamada Podemos «imaginar» que el objeto responde ejecutan el único méto que conoce Pero es evidente que al compilar se almacenan en el ejecutable todas las versiones disponibles del méto, para su posterior selección en tiempo de ejecución Programación III.I.T.I. de Sistemas Herencia 14 Transformación sobre figuras Programación III.I.T.I. de Sistemas Herencia 15 Definiciones diferidas cambia is En el código de FIGURA rota(.) traslada() o alternativamente cambia is En el código de una clase con f:figura f.rota(.) f.traslada() El código se basa en la «promesa» de que todas las figuras trán una implementación de rota y traslada Necesitamos una garantía «sintáctica» de que estas definiciones siempre estarán presentes Podemos escribir definiciones «sin código» en FIGURA, pero eso no garantiza que tos los descientes redefinan los métos con alguna implementación efectiva En la clase figura rota (c:punto;a: DOUBLE) is en torno a c con ángulo a deferred traslada (a,b:double) is a en horizontal y b en vertical deferred Podemos añadir a FIGURA definiciones diferidas de rota y traslada Las definiciones diferidas determinan cómo será la interfaz de las características en los descientes La programación bajo contrato nos permitirá fijar desde el ancestro parte del comportamiento de las características en los descientes

3 Programación III.I.T.I. de Sistemas Herencia 16 Clases diferidas Programación III.I.T.I. de Sistemas Herencia 17 Sintáxis de la redeclaración Diremos que una clase es diferida cuan alguna de sus características lo es, en caso contrario es efectiva La definición de las clases diferidas comienza obligatoriamente por deferred Class (incluso cuan todas sus características diferidas provengan de sus ancestros) Un tipo es diferi si está basa en una clase diferida El tipo de una instrucción de creación no puede ser diferi Aunque las entidades pueden ser de un tipo diferi, los objetos siempre son de un tipo efectivo En los diagramas las clases y características diferidas se identifican con letra cursiva Tipos de redeclaración (declaración en ) a diferida a efectiva de diferida redefinición concreción (redefine) ninguna de efectiva indefinición redefinición (undefine) (redefine) export{<c>} para cambiar la exportación rename y select para herencia repetida Precursor para ejecutar el código del padre Programación III.I.T.I. de Sistemas Herencia 18 Eliminan alternativas múltiples Programación III.I.T.I. de Sistemas Herencia 19 Abreviaturas en la creación Deseamos escribir una fecha en determina idioma, variable en tiempo de ejecución Podemos encapsular el código de cada idioma en una alternativa múltiple Podemos utilizar polimorfismo, clases diferidas y ligadura dinámica para obtener el mismo efecto (ver TIME_IN_SOME_LANGUAGE y TIME_IN_SPANISH) Con esta solución minimizamos las operaciones de mantenimiento necesarias para introducir un nuevo idioma El responsable de la creación de cada objeto sabe con qué tipo lo hace, pero ni siquiera es seguro que un sólo objeto conozca tos los tipos posibles x,y:t a,b:u nueva sintáxis create a x:=a sintáxis tradicional!!b y:=b x,y:t nueva sintáxis create {U} x sintáxis tradicional!u!y En ambos casos U debe ser conforme con T Programación III.I.T.I. de Sistemas Herencia 20 Dificultades con el polimorfismo CHICO CLASIFICADO CHICA CLASIFICADA El polimorfismo relaja el de chequeo de tipos Existen situaciones en que eso provoca errores en tiempo de ejecución Gestionamos el alojamiento de esquiares en una competición Los esquiares comparten habitación con un del mismo sexo Los esquiares clasificas disponen de habitación individual Programación III.I.T.I. de Sistemas Herencia 21 Primer ejemplo problemático class compannero: Su de habitación. (otro:) is Fija el del esquiar class Programación III.I.T.I. de Sistemas Herencia 22 Primer ejemplo problemático(ii) Programación III.I.T.I. de Sistemas Herencia 23 Primer ejemplo problemático(iii) redefine compannero, compannero: CHICO (otro:chico) is Redefinimos la interfaz compannero:=otro Podemos usar Precursor(otro)? Para distinguirlo distinto: INTEGER class CHICA redefine compannero, compannero: CHICA (otro:chica) is Redefinimos la interfaz compannero:=otro Podemos usar Precursor(otro)? para distinguirla distinto:real class CHICA is Esquiva las limitaciones entre chicos y chicas s: ; b: CHICO ; g: CHICA create b ; create g s:= b Disfrazo al chico s.(g) no provoca error std_output.put_integer(b.compannero.distinto) error

4 Programación III.I.T.I. de Sistemas Herencia 24 Interludio Programación III.I.T.I. de Sistemas Herencia 25 Segun ejemplo problemático Al redefinir la interfaz de un méto podemos sustituir un tipo por uno conforme con él Como hemos visto en el ejemplo anterior, esta redefinición no necesariamente evita errores en tiempo de ejecución Alternativamente podemos anclar el tipo de una entidad al de otra mediante expresión like <tipo> (like Current incluso) Con anclas no evitaremos el problema del ejemplo anterior Los tipos anclas son sólo conformes con su correspondiente ancla class compannero: like Current Ahora anclamos el atributo (otro:like Current) is Ahora anclamos el argumento class Programación III.I.T.I. de Sistemas Herencia 26 Segun ejemplo problemático(ii) Programación III.I.T.I. de Sistemas Herencia 27 Segun ejemplo problemático(iii) distinto: INTEGER class CHICA distinto: REAL class CHICA is Esquiva las limitaciones entre chicos y chicas s: ; b: CHICO ; g: CHICA create b ; create g s:= b Disfrazo al chico s.(g) no provoca error std_output.put_integer(b.compannero.distinto) error Programación III.I.T.I. de Sistemas Herencia 28 Interludio (II) Programación III.I.T.I. de Sistemas Herencia 29 Tercer ejemplo problemático El polimorfismo también puede evitar la detección de problemas en tiempo de compilación El nivel de exportación de las características impide a ciertos clientes solicitar determinadas tareas. El error sería detecta en tiempo de compilación Pero si un cliente tiene acceso legítimo a una característica, tos sus descientes pueden «ser disfrazas» para conseguir el acceso, al menos en tiempo de compilación Algunos compilares avisan de esta situación mediante un Warning (SmartEiffel 2.3) class compannero: like Current Anclamos el atributo (otro:like Current) is Anclamos el argumento class Programación III.I.T.I. de Sistemas Herencia 30 Tercer ejemplo problemático(ii) Programación III.I.T.I. de Sistemas Herencia 31 Tercer ejemplo problemático(iii) class CLASIFICADO CHICO Pero nadie puede pedirle que comparta habitación export {NONE} class CLASIFICADO is Ejemplo del error s: CHICO; b1,b2: CLASIFICADO create b1 ; create b2 s:= b1 Disfrazo al chico s.(b2) no provoca error Pero ahora b1 comparte el cuarto

5 Programación III.I.T.I. de Sistemas Herencia 32 Genericidad restringida Programación III.I.T.I. de Sistemas Herencia 33 Un vector sumable En las clases genéricas las entidades cuyo tipo es el parámetro formal sólo pueden cualificar los mensajes compris por ANY En otras palabras: Los parámetros formales son conformes sólo con ANY No es esto una excepción? Al definir un parámetro formal podemos establecer el tipo con que será conforme (G > INTEGER por ejemplo) con ello: Aumentamos los mensajes que entien los parámetros formales Disminuimos los tipos utilizables como parámetros formales La genericidad definida como hasta ahora es una abreviatura de G > ANY class VECTOR[G > NUMERIC] ARRAY[G] create,with_capacity,from_collection {ANY} infix "+" (otro: like Current): like current is Suma con otro coherente con Current require lower = otro.lower upper = otro.upper i:integer create Result.(lower,upper) from i:=lower until i> upper loop Result.put(item(i)+otro.item(i),i);i:=i+1 class VECTOR[G]