programación orientada a objetos · a manera de introducción • al principio las capacidades de...

Programación orientada a objetos

Abdiel E. Cáceres GonzálezCentro de Investigación y de Estudios Avanzados - IPN

México D.F., México.2004

A manera de Introducción

• Hace como 50 años, solamente una computadora IBM7094 daba servicio a toda la Universidad de Chicago. Ahora cualquier persona puede tener más poder de cómputo en su laptop que ellos en ese momento.

• Allá por los 70´s era una noticia cuando alguien conectaba una computadora con otra, simplemente al otro lado de la calle. Ahora es común usar emails transcontinentales.

A manera de Introducción

• Al principio las capacidades de hardware fueron aumentando muy rápido, abaratando los costos.

• Por el contrario, los desarrolladores de software seguían haciendo las mismas cosas en los mismos lenguajes.

• Esto hizo que los costos de HW estuvieran muy por debajo de los costos de SW.

• Los ingenieros de HW habían encontrado cómo reusar los esfuerzos de otras personas. Cosa que no hacían los ingenieros de SW, pues sus programas eran únicos. Lo que resultaba muy caro y frecuentemente de poca calidad.

Construcción de sistemas

• Antes de la revolución industrial, la industria de las armas de fuego apenas era realmente una industria; se trataba más bien de una coalición dispersa de artesanos individuales. Cada arma de fuego era construida por un armero individual, que construía cada una de las partes a partir de materias primas. Las armas de fuego así producidas eran muy caras, y casa una de ellas era el producto de la inspiración personal de un cierto armero.

• La revolución se produjo cuano Eli Whitney recibió un gran contrato de fabricación para hacer mosquetes para el gobierno.


• La innovación de Whitney consistió en dividir el trabajo, de tal manera que cada pieza era producida por un especialista, ajustándose a un cierto estándar especificado. Cada armero se centraba en una sola pieza, utilizando herramientas sofisticadas para optimizar aquella tarea.

• Esto daba lugar a unas economías tan apreciables que los costos de fabricacion desminuyeron drásticamente y, lo que es mejor, el cliente de Whitney se dio cuenta rápidamente que los estándares permitirían el intercambio de piezas, simplificando muchísimo su problema de reparación de armas de fuego.


• La importancia de la POO es comparable a la que tuvo la innovación de las piezas intercambiables producida por Whitney, y por razones que son, en gran parte, las mismas.

• Las dos redefinen la unidad de modularidad, de tal manera que los trabajadores producen subcomponentes en lugar de soluciones completas. Los subcomponentes están controlados mediante estándares y se pueden intercambiar entre productos distintos. Los programadores ya no construyen programas completos a partir de materias primas, que son las sentencias y expresiones desnudas de un lenguaje de programación. en lugar de hacer esto, producen componentes SW reutilizables, ensamblando los componentes de otros programadores. Estos componentes se denominan SW-IC para resaltar su similitud con el chip integrado de silicio, una innovación similar que ha revolucionado la industria del HW de computadoras.

¿Qué es construir un sistema?

Elizabeth Aduen

Ing Sistemas de una compañía recién fundada que desarrollan sistemas para hacer oficinas virtuales orientada a los clientes que usan grandes cantidades de papel, como compañías de seguros, bancos, gobierno.

Sistema supermoderno con tecnología de estaciones de

trabajo distribuídas y gráficas para gestionar formularios de

oficina en general


Elizabeth Aduen


NotaMientrasNoEstabas

Memorandum

FormularioParaAtestadosDeSeguros

FormularioParaSolicitudDeCreditoSolicitudDePermisoDeConducir

CuponDeGastoDeViaje

...



oficina en general


Elizabeth Aduen


$$$$ $$

• Los clientes de Elizabeth están dispuestos a pagar muy bien una solución viable para sus problemas de manejo de papeles. Pero, como consecuencia de sus escasos conocimientos acerca de las computadoras y también por la rapidez con que suceden los cambios, insisten en que todas las soluciones basadas en computadoras deben emular sus sistemas ya existentes.



oficina en general


Elizabeth Aduen


el sistema le gustará a los clientes, porque ataca

Atraerá nuevos clientes

los costos de manejo de papel

Pueden utilizar el mismo esquema por mucho tiempo

dificultad de conseguir personal

calificado

El prototipo



oficina en general


Elizabeth Aduen


• Es una excelente oportunidad para Elizabeth. Elizabeth tiene la responsabilidad principal en primerísima línea de la tecnología del momento.

• ¡Este sistema lo tiene todo!

• Distribuido

• Gráficas por computadora

• Lenguaje especializado orientado a iconos

• La gestión automática de procedimientos implica posiblemente técnicas de IA

La crisis del software

• Esto es posible, por supuesto. Pero desafortunadamente, no es probable.

• La industria de la programación tiene un historial muy malo con respecto a la construcción de sistemas, incluso siendo menos ambisiosos que el presente.

3%19%

2%

29%

47%

Pagados sin ser suministradosSuministrados pero sin utilizarseUsado tal como se suministróAbandonado o reformadoUtilizado después de cambios

El resultado probable es que se cancele el proyecto de Elizabeth antes de que se produzca ni

siquiera una línea de código.




Desencanto de los clientes





Bancarrota de la empresa





Bancarrota de la empresa

Desgracia personal de Elizabeth


Síntomasfatales

Se exceden los presupuestos

No se alcanzan los objetivos en los

plazos establecidos

Falta coltrol

Baja calidad

Cancelación y desgracia


¿Que es lo que hace que el sistema de Elizabeth sea tan ambicioso?


El HW no es un problema, porque que HW actual es capaz de admitir

sistemas de este tipo, y más






a) Los sistemas distribuidos no son nada nuevob) Las interfaces orientadas a formularios no son nada nuevoc) Sistemas nuevo de correo electrónico los hay muy sofisticadosd) Los sistemas de archivose) Estaciones de trabajo





a) Los sistemas distribuidos no son nada nuevob) Las interfaces orientadas a formularios no son nada nuevoc) Sistemas nuevo de correo electrónico los hay muy sofisticadosd) Los sistemas de archivose) Estaciones de trabajo

Estas tecnologías se han utilizado por separado, y juntas pueden ocasionar

problemas

El verdadero problema es que este sistema imlica una actitud hacia el cambio que no contemplan nuestras

herramientas de programación, nuestras metodologías ni nuestros

conceptos.

Nuestro enemigo: El cambio

Elizabeth, como Ing. Software es la responsable de definir el nuevo sistema. Pero ¿Qué significa esto?¿Cuáles son las

actividades de Elizabeth, y qué es lo que debe ser la responsabilidad de los demás miembros del equipo?

La arquitectura del sistema involucra





código





código diseño


• Hay ingenieros de software que dicen:

• Elizabeth debería empezar por seleccionar los componetes de hardware

• Después decidir la forma en que deben estar relacionados.

• Las tareas de Elizabeth son:

• Refinar la configuracion de hardware del sistema

• Definir qué componentes de software van en cada sitio

• Seleccionar una estrategia de redes para interconectar estas piezas entre sí


• Hay ingenieros de software que dicen:

• Elizabeth debería empezar por seleccionar los componetes de hardware

• Después decidir la forma en que deben estar relacionados.

• Las tareas de Elizabeth son:

• Refinar la configuracion de hardware del sistema

• Definir qué componentes de software van en cada sitio

• Seleccionar una estrategia de redes para interconectar estas piezas entre sí

¿Esto es una arquitectura?

¿Es más bien una fase inicial del diseño? Elizabeth sería

probablemente, la primera que revisara el proyecto desde el punto de vista de la posibilidad técnica

de hacerlo, y su principal responsabilidad consistiría en

evitar el peligro estadísticamente probable.


• Desde luego, no podría desentenderse de las responsabilidades tradicionales de un ingeniero de software, porque el proyecto podría, ciertamente, fracasar como consecuencia de unas especificaciones técnicas mal hechas y mal documentadas.

• Pero una brillante descomposición en componentes de hardware, software y de red, haría poco por mejorar la prognosis de este proyecto.


En un safari, es lógico matar mosquitos, porque la malaria

es un problema real e importante.


En un safari, es lógico matar mosquitos, porque la malaria

es un problema real e importante.

Pero no es lógico hacerlo cuando se intenta detener a un elefante que se aproxima

enfurecido.


Elizabeth se enfrenta a un ataque mediante el cambio, que es el mayor oponente y más peligroso al que pueda

enfrentarse cualquier proyecto de software, y sus primeros esfuerzos deberían ir encaminados a defender este proyecto

contra la destrucción a manos del cambio.


¿“del cambio” dijeron?

Sí, pero de ese “cambio” no estamos hablando

La línea de defensa Manigot

La estrategia convencional para enfrentarse al cambio consiste en construir elaboradas estructuras defensivas para evitar el cambio en cualquiera de sus formas, como la famosa

línea de defensa Manigot.

La Línea Maginot fue una línea de fortificacion y defensa contruida por Francia a lo largo de su frontera con [Alemania] e Italia, despues del fin de la Primera Guerra Mundial. (el termino línea Maginot se refiere al sistema entero o en ocaciones unicamente se usa para referirse a las defensas contra Alemania. Las defensas contra Italia suelen llamarse tambien Línea Alpina).


Este sistema debe su nombre a André Maginot, quien fue su promotor, un veterano mutilado durante la Primera Guerra Mundial y murio en 1932 sin ver terminada la obra.

La parte esencial de los trabajos se termino en 1936, en momentos en que la amenaza Hitleriana parecia darle toda la justificacion a este proyecto: es la mayor línea de defensa militar construida en el mundo, siendo de una gran complejidad tecnológica y militar. Su costo total fue 5 Millardos de FF (de la epoca). La línea Maginot compretde 108 fuertes principales a 15 km de distancia entre si, mutitud se pequeños fuertes y mas de 100 km de galerias.

Error de estrategia

La línea no evita la derrota de Francia al comienzo de la Segunda Guerra Mundial en 1940, por el contrario, en las diviciones alemanas la rodean y atacan en la region de Sedan, en su extremidad occidental, los ejercito aliados fueron cortados en dos.


Todos los directores de programación conocen este único capítulo, que contiene un único versículo.

El software, y sobretodo los grandes sistemas de software, debe ser desarrollado

determinando primero los requisitos del sistema, y documentándolos

Los requisitos se transforman en especificaciones, y estas se discuten con el cliente, que en última instancia las aprueba y

las firma, antes de realizar ningún trabajo adicional.


Una vez que los requisitos se han inmovilizado, se desarrolla toda una serie de diseños, que se revisan y documentan

exhaustivamente como especificaciones formales de diseño.

Por último, los diseños se transforman en código, éste paso debiera ser rutinario, suponiendo que se haya seguido un

proceso de diseño suficientemente riguroso.

Se prueba el código (por si acaso hubiera un error) y finalmente se le suministra al cliente.


Por supuesto, el trabajo debe ser planeado cuidadosamente. Si suponemos esto, el cliente tiene que estar satisfecho con el

resultado, puesto que el sistema suministrado será precisamente el sistema que él dio por bueno originalmente.

¿Cambiar los requisitos? ¡Ridículo! ¡Mire estos documentos, que tienen su firma abajo!¡Será necesario rehacer el diseño!¡Todo el planteamiento se vendrá abajo!¡Tendrá un costo adicional!

Desarrolladores de Software Clientes


¿Cuál es la solución?


¿Cuál es la solución? El mantenimiento

Una actividad sucia, que se lleva a cabo donde nadie lo vea, en la trastienda, muy lejos de la corriente de nuevos y excitantes desarrollos, que es donde se encuentran los programadores con verdadero talento.


El software

No se parece a la maderaNo se parece al acero

No se astillaNo se pudreNo se oxida

El SW no necesita ser desempolvado, encerado o limpiado. Pero sí tiene fallos, que necesitan nuestra atención, aunque esto NO SEA MANTENIMIENTO, sino REPARACION. La reparación es arreglar algo que se ha roto por jugar con ello, o algo que siempre ha estado roto. Por otra parte, a medida que el entorno que circunda al SW va cambiando, es preciso invertir energía para que esté al día. Esto no es mantenimiento, no es mantenerse firmes para evitar la caída. La evolución consiste en cambiar para avanzar.


Es posible que Elizabeth debiera ignorar el mantenimiento como algo turbio y poco importante, pero no puede ignorar las reparaciones, y, ciertamente, no puede olvidar la evolución. Su ventaja frente a la competencia depende de su capacidad para hacer que el producto evolucione, satisfaciendo las necesidades de sus clientes. Pero, ¿qué es exactamente lo que debería hacer?


Podría asegurarse de que el código tuviera muchos

comentarios



comentarios

Que el lenguaje de programación sea legible (lo

que sea que signifique)



comentarios



Prohibir los goto (si es que eso soluciona algo)



comentarios




Escribir mucha documentación interna



comentarios





Intentar que estuviese al día con respecto al código que

cambia contínuamente



comentarios





Intentar que estuviese al día con respecto al código que

cambia contínuamente

Pero, ¿afectaría realmente hacer todas estas cosas a la viabilidad técnica de este sistema?


Probablemente NO, porque estos remedios caseros no atacan la raíz del problema, que consiste en que el mundo real está verdaderamente coambiando, y la defensa Manigot intenta

negarlo. La actitud de la Línea Manigot impregna casi todas las herramientas de la industria de la programación, sus

metodología y sus conceptos. los lenguajes de programación responsabilizan de convertir los archivos fuente en código ejecutable. Pero este código es frágil y poco maleableñ

eficiente, pero incapaz de resistir los impactos del exterior. La actitud de la Línea Maginot hace que la maleabilidad sea responsabilidad del programador, y no de sus herramientas.


La mentalidad de la Línea Maginot gestiona el cambio a base de intentar impedir que se produzca. Cuando esto no tiene éxito (y siempre acaba por fallar, tarde o temprano), la tarea de reparar los daños se les para a los de la trastienda, al

equipo de mantenimiento. El resto del equipo pasa al proyecto siguiente, mientras todo el mundo intenta ignorar los clamores cuando el equipo de mantenimiento lucha para evitar que una horda hambrienta de cambios devore a estos frágiles y casi

inmutables sistemas de software.

sistemas de software

cambios

La defensa Suiza

El plan de negocios de la empresa de Elizabeth equivale a rechazar explícitamente la defensa de la Línea Manigot. Tienen la intención de construir un producto como prototipo, y lo utilizarán para atraer clientes, que serán quienes les paguen para cambiar su prototipo de modo que resuelva sus necesidades. La empresa de Elizabeth no puede proscribir el cambio, ni despachárselo a un grupo de mantenimiento. Su plan requiere una visión radicalmente distinta acerca del proceso de desarrollo de softwareñ se trata de una visión que trata el cambio como parte vital e inteligente del proceso global de desarrollo de software.

La defensa Suiza

La empresa de Elizabeth podría estar planeando utilizar algo parecido a la estrategia de defensa Suiza, contemporánea de la Línea Maginot. en lugar de invertir en una costosa (y a juzgar por sus vecinos, poco fiable) defensa de sus fronteras, Suiza se declaró país abierto, y daba la bienvenida a los visitantes de cualquier país, raza o religión. Esta política les permitió capear el temporal, cuyas consecuencias estremecieron al mundo, de la Segunda Guerra Mundial, y al mismo tiempo obtuvieron unos beneficios bastante decentes de todos los implicados, sin más que adaptarse a los sucesos con agilidad.

La defensa Suiza

¿Puede funcionar esta defensa a efectos del software?

Es probable que así sea, porque ya ha sido aplicada en varios sistemas especializados, y sumamente complicados.

Smalltalk-80 es uno de los ejemplos de otros entornos en los cuales la Línea Maginot de defensa no es aplicable, como,

por ejemplo, en la ingeniería del conocimiento. Los creadores de Smalltalk-80 construyeron un sistema que es

posible deformar en casi cualquier sentido. Todo el sistema, incluso bajando a nivel de hardware, está descompuesto en objetos blindados, que se comunican enviando mensajes. No

hay un sistema operativo protegido (y por lo tanto inmutable). El código fuente de todo el sistema está

disponible de forma inmediata para cualquier programador, y todo el entorno de programación de ese programador se puede modificar inmediatamente en casi cualquier aspecto, sin más

que modificar unas pocas líneas de código.

La defensa Suiza

¡Advertencia!

En este curso no vamos a promover la línea de defensa Suiza como manera de construir sistemas grandes. Aunque los conceptos de objetos, mensajes, clases y herencia ofrecen un gran potencial para construir sistemas grandes y maleables; hay varias razones por las cuales otras partes de la filosofía de Smalltalk-80 son, casi con certeza, inadecuadas para proyectos de esta escala.

La eficiencia de la máquina es una razón bastante evidente. Smalltalk exige mucho a los recursos de la máquina, puesto que invierte potencia de cálculo cuantiosamente para ofrecer capacidades de productividad como la recolección automática de basura, una interfaz de usuario muy gráfica y un entorno uniforme basado en objetos.

La defensa Suiza

¡Advertencia!

El control es una razón aún más fundamental. El sistema de la compañía de Elizabeth implicará a un gran número de programadores, que deben trabajar en grupo como una organización coordinada, si es que un sistema de semejante complejidad ha de llegar a ser suministrado algún día. La posibilidad de que cualquier programador pueda cambiar lo que se le antoje no es beneficioso para este tipo de trabajo, aunque este problema potencial podría tratarse a través del potente conjunto de herramientas que ofrece Smalltalk para gestionar los cambios.

La defensa Suiza

¡Advertencia!

La compatibilidad es la razón más fundamental, y es casi imposible de superar. Casi todas las organizaciones modernas tienen al menos algún tipo de inversión previa en software, desarrollado en lenguajes anteriores, y los clientes insistirán en que el software anterior siga siendo viable. Salvo que se ofrezca un hardware independiente para estas aplicaciones no parece que haya forma de evitar la circunstancia consistente en que Smalltalk-80 necesita un entorno completo e independiente en sí mismo.

La defensa híbrida

La defensa híbrida es parecida a la que preferiría un militar experto en combate, combinando todas las posibles estrategias en una combinación activa.

Se utilizan parapetos defensivos para defender las estructuras importantes contra ataques frontales

Se emplean unidades dispersas, formadas por ordenes o mandatos, para proporcionar un conocimiento del terreno.

Se hace uso de la maniobrabilidad para evitar ataques, si es posible.

Y se echa mano de la diplomacia y demás tácticas pacíficas para evitar los disparos, desde el primer momento.

La defensa híbrida

El dogma convencional de la ingeniería de software consiste en construir:

sistemas de software eficientes

(pero frágiles)

La defensa híbrida

El dogma convencional de la ingeniería de software consiste en construir:

sistemas de software eficientes

(pero frágiles)

estructuras estáticas de defensa que los protegen de los cambios





rodeados por

La defensa híbrida

El valor de esto no se puede negar, puesto que el cambio incontrolado (”hacking”, parchar el sistema) no es manera de construir complejos sistemas de software. Pero aún se puede hacer más:

Es posible hacer que los sistemas que sean maleables permitiendo que haya una cierta elasticidad en la ejecución. Esto implica

suavizar la exigencia habitual de que todo se haga en el momento de la compilación (dynamic binding)

La defensa híbrida




Hacer sistemas que cambien más fácilmente haciéndolos más pequeños y ligeros, y transformando, de esta manera, la

funcionalidad típica de un sistema en algo del tamaño de un programa. Las técnicas de encapsulación y de herencia, hacen

esto,integrando la reutilizabilidad en el aspecto principal del proceso de desaroollo de software

La defensa híbrida




Hacer sistemas que cambien más fácilmente haciéndolos más pequeños y ligeros, y transformando, de esta manera, la

funcionalidad típica de un sistema en algo del tamaño de un programa. Las técnicas de encapsulación y de herencia, hacen

esto,integrando la reutilizabilidad en el aspecto principal del proceso de desaroollo de software

Los sistemas pueden encapsular más cuando adoptan la forma de objetos, que se pomportan como cajas negras blindadas, para

limitar el efecto de transmisión cuando llega a tener lugar una penetración de las defensas estáticas. Un cambio de una parte

del sistema no tiene por qué afectar al resto del sistema, sino que puede tratar desde el principio el interior de la parte

afectada.


No intentaremos dar una solución que vaya a eliminar

por arte de magia problemas de esta magnitud. Pero sí vamos a proponer varios conceptos y herramientas, que pueden ayudarnos a producir un

software que sea mucho más tolerante con respecto al

cambio:

• La encapsulación es el fundamento de todo este enfoque. Su contribución consiste en restringir los efectos del cambio, situando un muro de código en torno a cada dato. Todo el acceso a los datos está gestionado mediante procedimientos, que se han puesto allí para hacer de mediadores en el acceso a los datos. Olvidarse del “cómo hacer” y ahora especificar el “qué hacer”.


No intentaremos dar una solución que vaya a eliminar

por arte de magia problemas de esta magnitud. Pero sí vamos a proponer varios conceptos y herramientas, que pueden ayudarnos a producir un

software que sea mucho más tolerante con respecto al

cambio:

• La herencia es la parte más innovadora del enfoque. Se trata de una herramienta para retransmitir automáticamente el código a clases desarrolladas por distintos miembros de un equipo. Los programadores ya no empiezan cada módulo con una pagina en blanco, sino que, escriben una sola sentencia que se refiere a una clase que ya esta en la biblioteca. Cada una de las sentencias subsiguientes describe la forma en que la nueva clase se diferencia de la que está en la biblioteca.


Para ver cómo estas técnicas se aplican al problema de Elizabeth, examinemos de manera más detallada las

posibilidades del sistema prototipo, y la forma en que deben cambiar al transcurrir el tiempo.

El sistema inicial admitirá un cierto número de objetos genéricos de oficina:




Escritorio Carpetas Buzones Sobres Memos NotaMientrasEstabasFuera





Escritorio Carpetas Buzones Sobres Memos NotaMientrasEstabasFuera


El prototipo debe mostrar que el diseño de Elizabeth satisface los objetivos del sistema. Por ejemplo, debe

mostrar que estos objetos de oficina pueden emular la forma en que se comportan los objetos de oficina más familiares, y

que el sistema se puede extender con nuevos objetos de oficina en un momento posterior.


Los escritorios, sobres, buzones y carpetas son colecciones débilmente acopladas,

Débilmente acopladas: Es el grado en que el diseño de la colección depende del diseño de su contenido.

Evidentemente, un escritorio electrónico no puede ser rediseñado y recompilado cada vez que se agregue un nuevo objeto electrónico, puesto que el usuario toma esta decision en el momento de ejecución. Mas aún, el repertorio de objetos que debe contener el escritorio irá cambiando con el tiempo, a medida que el sistema se extienda con nuevos tipos de formularios de oficina.

Sin embargo, debe existir un cierto grado de acoplamiento, puesto que un escritorio electrónico

necesita relacionarse con su contenido.


Ejemplo:

Buzón

muestraContenido:

Muestra un menú con el contenido actual y

ayuda al usuario a seleccionar el

siguiente objeto que debe leer

detalladamente.


Ejemplo:

Buzón

muestraContenido:




detalladamente.

Para realizar esta opción, debe haber una forma de obtener información resumida acerca de todos los objetos que puedan aparecer en el buzón, y esto equivale a una operación que el buzón debe aplicar a su contenido.


Ejemplo:

Buzón

muestraContenido:




detalladamente.

Para realizar esta opción, debe haber una forma de obtener información resumida acerca de todos los objetos que puedan aparecer en el buzón, y esto equivale a una operación que el buzón debe aplicar a su contenido.

Memorando

muestraResumenMemorando:

Sobre

muestraResumenSobre:

Carpeta

muestraResumenCarpeta:


Esta clase de problema no es fácil de resolver con los lenguajes de programación convencionales, porque la programación convencional hace que el consumidor de un operando sea responsable de seleccionar el operador apropiado para el tipo de operando en cuestión. En este caso, el desarrollador del buzón es el consumidor de los objetos que hay que enviar por correo.

Para obtener una información resumida de estos objetos correctamente, debe seleccionar operadores (funciones) que extraigan de alguna manera la información necesaria de los distintos objetos.

La solución habitual consiste en almacenar el tipo dentro de cada objeto en un lugar estándar, de este modo:

struct item { int codigoTipo; ...}

Y comprobar después el tipo mediante una sentencia switch.


Basándose en el tipo de objeto, el buzón puede llamar a la función correcta para ese tipo:

mostrarResumenDe(objetoSiguiente)struct objeto *objetoSiguiente;{ switch(objetoSiguiente->codigoTipo) { case MEMORANDO:mostrarResumenMemo(objetoSiguiente);break; case CARPETA:mostrarResumenCarpeta(objetoSiguiente);break; case NOTAMIENTRASESTABASFUERA:mostrarResumenNota(objetoSiguiente);break; case SOBRE:mostrarResumenSobre(objetoSiguiente);break; }...}

Y comprobar después el tipo mediante una sentencia switch.

Obsérvese lo que sucede si Elizabeth llega realmente a intentar construir un sistema así.



El código del buzón depende ahora explícitamente de los tipos de elementos que eran conocidos cuando se escribió el buzón.

Las sentencias case indican explícitamente que este buzón no funcionará para contenidos que no sean MEMORANDO, CARPETA, NOTAMIENTRASESTABASFUERA y SOBRE



El código del buzón depende ahora explícitamente de los tipos de elementos que eran conocidos cuando se escribió el buzón.

Las sentencias case indican explícitamente que este buzón no funcionará para contenidos que no sean MEMORANDO, CARPETA, NOTAMIENTRASESTABASFUERA y SOBRE

Cada vez que se agrega un nuevo tipo de dato a este sistema, el código del buzón debe ser cambiado y recopilado.


Aún más, estas sentencias switch no están localizadas en ninguna manera. Reflejan la responsabilidad del consumidor en lo que respecta a seleccionar operadores que sean compatibles con tipos de operandos, así que aparecen a lo largo de todo el sistema. Cada que se agregue un nuevo tipo de datos, será necesario cambiar todas y cada una de las sentencias switch

para agregar un caso para el nuevo tipo.

Obsérvese lo que sucede cuando la responsabilidad de seleccionar la forma de realizar cada orden se traslada al

proveedor del objeto, en lugar de asignársele al consumidor:

mostrarResumenDe(objetoSiguiente)struct objeto *objetoSiguiente;{ [objetoSiguente mostrarResumen]; ...}


Esto ordena al objeto llamado

objetoSiguiente que lleve a cabo la orden denominada mostrarResumen.



Esto ordena al objeto llamado

objetoSiguiente que lleve a cabo la orden denominada mostrarResumen.


El consumidor no sabe, ni le importa, la forma en que objetoSiguiente lleva a cabo mostrarResumen, porque

ésto es responsabilidad del que suministra objetoSiguiente. Aunque distintas clases de objetos,

como carpetas, memorandos, y sobres pueden mostrarResumen de formas muy diferentes, el código del consumidor no necesita preocuparse. Cuando se extiende el sistema con un nuevo tipo de objeto, el cambio no se extiende más allá del código que haya sido escrito por el proveedor del objeto. Esta encapsulación hace que los sistemas sean más maleables, restringiendo el

daño que puede causar un cambio.


La herencia, al contrario, sirve para retransmitir los efectos a lo largo y ancho de todo el sistema. Los

escritorios, carpetas, sobres y buzones son, a primera vista, tipos distintos de objetos. Sin embargo, la verdad es que tienen muchas cosas en común, puesto que se trata

solamente de diferentes clases de contenedores.


La herencia permite que sus similitudes estén descritas en un lugar central (una clase Contenedor) y que sean

retransmitidas a todas las clases que se comporten como contenedores.

Escritorio

Contenedor

característica_A:

Carpeta Sobre


La herencia permite que sus similitudes estén descritas en un lugar central (una clase Contenedor) y que sean

retransmitidas a todas las clases que se comporten como contenedores.

Escritorio

característica_A:

Contenedor

característica_A:

Carpeta

característica_A:

Sobre

característica_A:


El desarrollador de escritorios no necesita construir estas propiedades comunes. En lugar de hacer esto,

describe la forma en que los escritorios difieren de los contenedores estándar. Los sobres, carpetas y buzones se describen de la misma manera. Dado que la funcionalidad

genérica se puede desarrollar una vez, y se puede utilizar en muchas ocasiones, la herencia proporciona un

fuerte incremento de productividad.

Resulta más difícil e impensable desarrollar un nuevo código partiendo de cero, porque es casi siempre más

sencillo heredar unas capacidades portentes y probadas a partir de una biblioteca de trabajo anterior.

Abdiel E. Cáceres GonzálezCentro de Investigación y de Estudios Avanzados - IPN

México D.F., México.2004

Contacto:

[email protected]@mazatlan.udo.mx

programación orientada a objetos · a manera de introducción • al principio las capacidades de...

Documents