Pensar en C++ (Volumen 1) - Grupo ARCO
Pensar en C++ (Volumen 1) - Grupo ARCO Pensar en C++ (Volumen 1) - Grupo ARCO
✐ ✐ ✐ “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 ✐ ✐ ✐ ✐
- Page 1 and 2: ✐ ✐ ✐ “Volumen1” — 2012
- Page 3 and 4: ✐ ✐ ✐ “Volumen1” — 2012
- Page 5 and 6: ✐ ✐ ✐ “Volumen1” — 2012
- Page 7 and 8: ✐ ✐ ✐ “Volumen1” — 2012
- Page 9 and 10: ✐ ✐ ✐ “Volumen1” — 2012
- Page 11 and 12: ✐ ✐ ✐ “Volumen1” — 2012
- Page 13 and 14: ✐ ✐ ✐ “Volumen1” — 2012
- Page 15 and 16: ✐ ✐ ✐ “Volumen1” — 2012
- Page 17 and 18: ✐ ✐ ✐ “Volumen1” — 2012
- Page 19 and 20: ✐ ✐ ✐ “Volumen1” — 2012
- Page 21 and 22: ✐ ✐ ✐ “Volumen1” — 2012
- Page 23 and 24: ✐ ✐ ✐ “Volumen1” — 2012
- Page 25 and 26: ✐ ✐ ✐ “Volumen1” — 2012
- Page 27 and 28: ✐ ✐ ✐ “Volumen1” — 2012
- Page 29 and 30: ✐ ✐ ✐ “Volumen1” — 2012
- Page 31 and 32: ✐ ✐ ✐ “Volumen1” — 2012
- Page 33 and 34: ✐ ✐ ✐ “Volumen1” — 2012
- Page 35 and 36: ✐ ✐ ✐ “Volumen1” — 2012
- Page 37 and 38: ✐ ✐ ✐ “Volumen1” — 2012
- Page 39 and 40: ✐ ✐ ✐ “Volumen1” — 2012
- Page 41 and 42: ✐ ✐ ✐ “Volumen1” — 2012
- Page 43 and 44: ✐ ✐ ✐ “Volumen1” — 2012
- Page 45 and 46: ✐ ✐ ✐ “Volumen1” — 2012
- Page 47: ✐ ✐ ✐ “Volumen1” — 2012
- Page 51 and 52: ✐ ✐ ✐ “Volumen1” — 2012
- Page 53 and 54: ✐ ✐ ✐ “Volumen1” — 2012
- Page 55 and 56: ✐ ✐ ✐ “Volumen1” — 2012
- Page 57 and 58: ✐ ✐ ✐ “Volumen1” — 2012
- Page 59 and 60: ✐ ✐ ✐ “Volumen1” — 2012
- Page 61 and 62: ✐ ✐ ✐ “Volumen1” — 2012
- Page 63 and 64: ✐ ✐ ✐ “Volumen1” — 2012
- Page 65 and 66: ✐ ✐ ✐ “Volumen1” — 2012
- Page 67 and 68: ✐ ✐ ✐ “Volumen1” — 2012
- Page 69 and 70: ✐ ✐ ✐ “Volumen1” — 2012
- Page 71 and 72: ✐ ✐ ✐ “Volumen1” — 2012
- Page 73 and 74: ✐ ✐ ✐ “Volumen1” — 2012
- Page 75 and 76: ✐ ✐ ✐ “Volumen1” — 2012
- Page 77 and 78: ✐ ✐ ✐ “Volumen1” — 2012
- Page 79 and 80: ✐ ✐ ✐ “Volumen1” — 2012
- Page 81 and 82: ✐ ✐ ✐ “Volumen1” — 2012
- Page 83 and 84: ✐ ✐ ✐ “Volumen1” — 2012
- Page 85 and 86: ✐ ✐ ✐ “Volumen1” — 2012
- Page 87 and 88: ✐ ✐ ✐ “Volumen1” — 2012
- Page 89 and 90: ✐ ✐ ✐ “Volumen1” — 2012
- Page 91 and 92: ✐ ✐ ✐ “Volumen1” — 2012
- Page 93 and 94: ✐ ✐ ✐ “Volumen1” — 2012
- Page 95 and 96: ✐ ✐ ✐ “Volumen1” — 2012
- Page 97 and 98: ✐ ✐ ✐ “Volumen1” — 2012
✐<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 />
✐