Pensar en C++ (Volumen 1) - Grupo ARCO

Pensar en C++ (Volumen 1) - Grupo ARCO Pensar en C++ (Volumen 1) - Grupo ARCO

arco.esi.uclm.es
from arco.esi.uclm.es More from this publisher
13.01.2015 Views

✐ ✐ ✐ “Volumen1” — 2012/1/12 — 13:52 — page 10 — #48 ✐ Capítulo 1. Introducción a los Objetos dibujar( ) borrar( ) mover( ) pedirColor( ) fijarColor( ) dibujar( ) borrar( ) dibujar( ) borrar( ) dibujar( ) borrar( ) Figura 1.6: Reescritura de métodos Para reescribir una función, simplemente hay que crear una nueva definición para esa función en la clase derivada. Está diciendo, «Estoy usando la misma función de interfaz aquí, pero quiero hacer algo diferente para mi nuevo tipo». 1.5.1. Relaciones es-un vs. es-como-un Hay cierta controversia que puede ocurrir con la herencia: ¿la herencia debería limitarse a anular sólo funciones de la clase base (y no añadir nuevos métodos que no estén en la clase base) Esto puede significar que el tipo derivado es exactamente el mismo tipo que la clase base dado que tiene exactamente la misma interfaz. Como resultado, se puede sustituir un objeto de una clase derivada por un objeto de la clase base. Se puede pensar como una sustitución pura, y se suele llamar principio de sustitución. En cierto modo, esta es la forma ideal de tratar la herencia. A menudo nos referimos a las relaciones entre la clase base y clases derivadas en este caso como una relación es-un, porque se dice «un círculo es una figura». Un modo de probar la herencia es determinar si se puede considerar la relación es-un sobre las clases y si tiene sentido. Hay ocasiones en las que se deben añadir nuevos elementos a la interfaz de un tipo derivado, de esta manera se amplía la interfaz y se crea un tipo nuevo. El nuevo tipo todavía puede ser sustituido por el tipo base, pero la sustitución no es perfecta porque sus nuevas funciones no son accesibles desde el tipo base. Esta relación se conoce como es-como-un; el nuevo tipo tiene la interfaz del viejo tipo, pero también contiene otras funciones, por lo que se puede decir que es exactamente el mismo. Por ejemplo, considere un aire acondicionado. Suponga que su casa está conectada con todos los controles para refrigerar; es decir, tiene una interfaz que le permite controlar la temperatura. Imagine que el aire acondicionado se avería y lo reemplaza por una bomba de calor, la cual puede dar calor y frío. La bomba de calor es-como-un aire acondicionado, pero puede hacer más cosas. Como el sistema de control de su casa está diseñado sólo para controlar el frío, está rentringida a comunicarse sólo con 10 ✐ ✐ ✐ ✐

✐ ✐ ✐ “Volumen1” — 2012/1/12 — 13:52 — page 11 — #49 ✐ 1.6. Objetos intercambiables gracias al polimorfismo la parte de frío del nuevo objeto. La interfaz del nuevo objeto se ha extendido, y el sistema existente no conoce nada excepto la interfaz original. Tesmostato controla Sistema de frío temperaturaMínima( ) frío( ) Aire Acondicionado frío( ) Bomba de calor frío( ) calor( ) Figura 1.7: Relaciones Por supuesto, una vez que vea este diseño queda claro que la clase base «sistema de frío» no es bastante general, y se debería renombrar a «sistema de control de temperatura», además también puede incluir calor, en este punto se aplica el principio de sustitución. Sin embargo, el diagrama de arriba es un ejemplo de lo que puede ocurrir en el diseño y en el mundo real. Cuando se ve el principio de sustitución es fácil entender cómo este enfoque (sustitución pura) es la única forma de hacer las cosas, y de hecho es bueno para que sus diseños funcionen de esta forma. Pero verá que hay ocasiones en que está igualmente claro que se deben añadir nuevas funciones a la interfaz de la clase derivada. Con experiencia, ambos casos puede ser razonablemente obvios. 1.6. Objetos intercambiables gracias al polimorfismo Cuando se manejan jerarquías de tipos, se suele tratar un objeto no como el tipo específico si no como su tipo base. Esto le permite escribir código que no depende de los tipos específicos. En el ejemplo de la figura, las funciones manipulan figuras genéricas sin preocuparse de si son círculos, cuadrados, triángulos, etc. Todas las figuras se pueden dibujar, borrar y mover, pero estas funciones simplemente envían un mensaje a un objeto figura, sin preocuparse de cómo se las arregla el objeto con cada mensaje. Semejante código no está afectado por la adición de nuevos tipos, y añadir nuevos tipos es la forma más común de extender un programa orientado a objetos para tratar nuevas situaciones. Por ejemplo, puede derivar un nuevo subtipo de figura llamado pentágono sin modificar las funciones que tratan sólo con figuras genéricas. Esta habilidad para extender un programa fácilmente derivando nuevos subtipos es importante porque mejora enormemente los diseños al mismo tiempo que reduce el coste del mantenimiento del software. 11 ✐ ✐ ✐ ✐

✐<br />

✐<br />

✐<br />

“Volum<strong>en</strong>1” — 2012/1/12 — 13:52 — page 11 — #49<br />

✐<br />

1.6. Objetos intercambiables gracias al polimorfismo<br />

la parte de frío del nuevo objeto. La interfaz del nuevo objeto se ha ext<strong>en</strong>dido, y el<br />

sistema exist<strong>en</strong>te no conoce nada excepto la interfaz original.<br />

Tesmostato controla Sistema de frío<br />

temperaturaMínima( ) frío( )<br />

Aire Acondicionado<br />

frío( )<br />

Bomba de calor<br />

frío( )<br />

calor( )<br />

Figura 1.7: Relaciones<br />

Por supuesto, una vez que vea este diseño queda claro que la clase base «sistema<br />

de frío» no es bastante g<strong>en</strong>eral, y se debería r<strong>en</strong>ombrar a «sistema de control de temperatura»,<br />

además también puede incluir calor, <strong>en</strong> este punto se aplica el principio<br />

de sustitución. Sin embargo, el diagrama de arriba es un ejemplo de lo que puede<br />

ocurrir <strong>en</strong> el diseño y <strong>en</strong> el mundo real.<br />

Cuando se ve el principio de sustitución es fácil <strong>en</strong>t<strong>en</strong>der cómo este <strong>en</strong>foque (sustitución<br />

pura) es la única forma de hacer las cosas, y de hecho es bu<strong>en</strong>o para que sus<br />

diseños funcion<strong>en</strong> de esta forma. Pero verá que hay ocasiones <strong>en</strong> que está igualm<strong>en</strong>te<br />

claro que se deb<strong>en</strong> añadir nuevas funciones a la interfaz de la clase derivada. Con<br />

experi<strong>en</strong>cia, ambos casos puede ser razonablem<strong>en</strong>te obvios.<br />

1.6. Objetos intercambiables gracias al polimorfismo<br />

Cuando se manejan jerarquías de tipos, se suele tratar un objeto no como el tipo<br />

específico si no como su tipo base. Esto le permite escribir código que no dep<strong>en</strong>de<br />

de los tipos específicos. En el ejemplo de la figura, las funciones manipulan figuras<br />

g<strong>en</strong>éricas sin preocuparse de si son círculos, cuadrados, triángulos, etc. Todas las<br />

figuras se pued<strong>en</strong> dibujar, borrar y mover, pero estas funciones simplem<strong>en</strong>te <strong>en</strong>vían<br />

un m<strong>en</strong>saje a un objeto figura, sin preocuparse de cómo se las arregla el objeto con<br />

cada m<strong>en</strong>saje.<br />

Semejante código no está afectado por la adición de nuevos tipos, y añadir nuevos<br />

tipos es la forma más común de ext<strong>en</strong>der un programa ori<strong>en</strong>tado a objetos para<br />

tratar nuevas situaciones. Por ejemplo, puede derivar un nuevo subtipo de figura llamado<br />

p<strong>en</strong>tágono sin modificar las funciones que tratan sólo con figuras g<strong>en</strong>éricas.<br />

Esta habilidad para ext<strong>en</strong>der un programa fácilm<strong>en</strong>te derivando nuevos subtipos es<br />

importante porque mejora <strong>en</strong>ormem<strong>en</strong>te los diseños al mismo tiempo que reduce el<br />

coste del mant<strong>en</strong>imi<strong>en</strong>to del software.<br />

11<br />

✐<br />

✐<br />

✐<br />

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!