Poo 01

Programacin orientada a objetos
Abdiel E. Cceres Gonzlez Centro de Investigacin y de Estudios Avanzados - IPN Mxico D.F., Mxico. 2004
A manera de Introduccin
Hace como 50 aos, solamente una computadora IBM7094 daba servicio a toda la Universidad de Chicago. Ahora cualquier persona puede tener ms poder de cmputo en su laptop que ellos en ese momento. All por los 70s era una noticia cuando alguien conectaba una computadora con otra, simplemente al otro lado de la calle. Ahora es comn usar emails transcontinentales.
A manera de Introduccin
Al principio las capacidades de hardware fueron aumentando muy rpido, abaratando los costos. Por el contrario, los desarrolladores de software seguan 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 haban encontrado cmo reusar los esfuerzos de otras personas. Cosa que no hacan los ingenieros de SW, pues sus programas eran nicos. Lo que resultaba muy caro y frecuentemente de poca calidad.
Construccin de sistemas
Antes de la revolucin industrial, la industria de las armas de fuego apenas era realmente una industria; se trataba ms bien de una coalicin dispersa de artesanos individuales. Cada arma de fuego era construida por un armero individual, que construa 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 inspiracin personal de un cierto armero. La revolucin se produjo cuano Eli Whitney recibi un gran contrato de fabricacin para hacer mosquetes para el gobierno.
La innovacin de Whitney consisti en dividir el trabajo, de tal manera que cada pieza era producida por un especialista, ajustndose a un cierto estndar especificado. Cada armero se centraba en una sola pieza, utilizando herramientas sofisticadas para optimizar aquella tarea.
Esto daba lugar a unas economas tan apreciables que los costos de fabricacion desminuyeron drsticamente y, lo que es mejor, el cliente de Whitney se dio cuenta rpidamente que los estndares permitiran el intercambio de piezas, simplificando muchsimo su problema de reparacin de armas de fuego.
La importancia de la POO es comparable a la que tuvo la innovacin 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 estn controlados mediante estndares 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 programacin. 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 innovacin similar que ha revolucionado la industria del HW de computadoras.
Qu es construir un sistema?
Sistema supermoderno con tecnologa de estaciones de trabajo distribudas y grficas para gestionar formularios de oficina en general
Elizabeth Aduen Ing Sistemas de una compaa recin fundada que desarrollan sistemas para hacer oficinas virtuales orientada a los clientes que usan grandes cantidades de papel, como compaas de seguros, bancos, gobierno.
SolicitudDePermisoDeConducir
FormularioParaSolicitudDeCredito
Memorandum
...
CuponDeGastoDeViaje
NotaMientrasNoEstabas
FormularioParaAtestadosDeSeguros
Los clientes de Elizabeth estn dispuestos a pagar muy bien una solucin viable para sus problemas de manejo de papeles. Pero, como consecuencia de sus escasos conocimientos acerca de las computadoras y tambin por la rapidez con que suceden los cambios, insisten en que todas las soluciones basadas en computadoras deben emular sus sistemas ya existentes.
$$
$$
$$
el sistema le gustar a los clientes, porque ataca los costos de manejo de papel dificultad de conseguir personal calificado
Pueden utilizar el mismo esquema por mucho tiempo
Elizabeth Aduen
Atraer nuevos clientes
El prototipo
Ing Sistemas de una compaa recin fundada que desarrollan sistemas para hacer oficinas virtuales orientada a los clientes que usan grandes cantidades de papel, como compaas de seguros, bancos, gobierno.
Es una excelente oportunidad para Elizabeth. Elizabeth tiene la responsabilidad principal en primersima lnea de la tecnologa del momento. Este sistema lo tiene todo!
Distribuido Grficas por computadora Lenguaje especializado orientado a iconos La gestin automtica de procedimientos implica posiblemente tcnicas de IA
La crisis del software
Esto es posible, por supuesto. Pero desafortunadamente, no es probable. La industria de la programacin tiene un historial muy malo con respecto a la construccin de sistemas, incluso siendo menos ambisiosos que el presente.
3% 19% 2% 29% 47%
Pagados sin ser suministrados Suministrados pero sin utilizarse Usado tal como se suministr Abandonado o reformado Utilizado despus de cambios
El resultado probable es que se cancele el proyecto de Elizabeth antes de que se produzca ni siquiera una lnea de cdigo.
Desencanto de los clientes
Bancarrota de la empresa
Bancarrota de la empresa
Desgracia personal de Elizabeth
Se exceden los presupuestos No se alcanzan los objetivos en los plazos establecidos Falta coltrol Baja calidad
Sntomas fatales
Cancelacin 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 ms

El HW no es un problema, porque que HW actual es capaz de admitir sistemas de este tipo, y ms a) Los sistemas distribuidos no son nada nuevo b) Las interfaces orientadas a formularios no son nada nuevo c) Sistemas nuevo de correo electrnico los hay muy sofisticados d) Los sistemas de archivos e) Estaciones de trabajo

El HW no es un problema, porque que HW actual es capaz de admitir sistemas de este tipo, y ms a) Los sistemas distribuidos no son nada nuevo b) Las interfaces orientadas a formularios no son nada nuevo c) Sistemas nuevo de correo electrnico los hay muy sofisticados d) Los sistemas de archivos e) Estaciones de trabajo
Estas tecnologas 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 programacin, nuestras metodologas ni nuestros conceptos.
Nuestro enemigo: El cambio
Elizabeth, como Ing. Software es la responsable de definir el nuevo sistema. Pero Qu significa esto?Cules son las actividades de Elizabeth, y qu es lo que debe ser la responsabilidad de los dems miembros del equipo? La arquitectura del sistema involucra
cdigo
cdigo
cdigo
diseo
Hay ingenieros de software que dicen:
Elizabeth debera empezar por seleccionar los componetes de hardware Despus 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 debera una arquitectura? Esto es empezar por seleccionar los componetes de hardware Es ms bien una fase inicial del Despus decidir la forma en que deben estar diseo? Elizabeth sera relacionados. probablemente, la primera que Las tareas de Elizabeth son: revisara el proyecto desde el punto de vista de la posibilidad tcnica Refinar la configuracion de hardware del sistema de hacerlo, y su principal responsabilidad consistira en Definir qu componentes de software van en cada evitar el peligro estadsticamente sitio probable. Seleccionar una estrategia de redes para interconectar estas piezas entre s
Desde luego, no podra desentenderse de las responsabilidades tradicionales de un ingeniero de software, porque el proyecto podra, ciertamente, fracasar como consecuencia de unas especificaciones tcnicas mal hechas y mal documentadas. Pero una brillante descomposicin en componentes de hardware, software y de red, hara poco por mejorar la prognosis de este proyecto.
En un safari, es lgico matar mosquitos, porque la malaria es un problema real e importante.
En un safari, es lgico matar mosquitos, porque la malaria es un problema real e importante.
Pero no es lgico 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 ms peligroso al que pueda enfrentarse cualquier proyecto de software, y sus primeros esfuerzos deberan ir encaminados a defender este proyecto contra la destruccin a manos del cambio.
del cambio dijeron?
S, pero de ese cambio no estamos hablando
La lnea 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 lnea de defensa Manigot.
La Lnea Maginot fue una lnea 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 lnea 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 Lnea 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 lnea de defensa militar construida en el mundo, siendo de una gran complejidad tecnolgica y militar. Su costo total fue 5 Millardos de FF (de la epoca). La lnea Maginot compretde 108 fuertes principales a 15 km de distancia entre si, mutitud se pequeos fuertes y mas de 100 km de galerias. Error de estrategia La lnea 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 programacin conocen este nico captulo, que contiene un nico versculo. El software, y sobretodo los grandes sistemas de software, debe ser desarrollado determinando primero los requisitos del sistema, y documentndolos
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 ningn trabajo adicional.
Una vez que los requisitos se han inmovilizado, se desarrolla toda una serie de diseos, que se revisan y documentan exhaustivamente como especificaciones formales de diseo. Por ltimo, los diseos se transforman en cdigo, ste paso debiera ser rutinario, suponiendo que se haya seguido un proceso de diseo suficientemente riguroso. Se prueba el cdigo (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? Ridculo! Mire estos documentos, que tienen su firma abajo!Ser necesario rehacer el diseo!Todo el planteamiento se vendr abajo!Tendr un costo adicional!
Desarrolladores de Software
Clientes
Cul es la solucin?
Cul es la solucin?
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 madera No se parece al acero No se astilla No se pudre No se oxida El SW no necesita ser desempolvado, encerado o limpiado. Pero s tiene fallos, que necesitan nuestra atencin, aunque esto NO SEA MANTENIMIENTO, sino REPARACION. La reparacin 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 energa para que est al da. Esto no es mantenimiento, no es mantenerse firmes para evitar la cada. La evolucin 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 evolucin. 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 debera hacer?
Podra asegurarse de que el cdigo tuviera muchos comentarios
Podra asegurarse de que el cdigo tuviera muchos comentarios Que el lenguaje de programacin sea legible (lo que sea que signifique)
Podra asegurarse de que el cdigo tuviera muchos comentarios Que el lenguaje de programacin sea legible (lo que sea que signifique) Prohibir los goto (si es que eso soluciona algo)
Podra asegurarse de que el cdigo tuviera muchos comentarios Que el lenguaje de programacin sea legible (lo que sea que signifique) Prohibir los goto (si es que eso soluciona algo) Escribir mucha documentacin interna
Podra asegurarse de que el cdigo tuviera muchos comentarios Que el lenguaje de programacin sea legible (lo que sea que signifique) Prohibir los goto (si es que eso soluciona algo) Escribir mucha documentacin interna Intentar que estuviese al da con respecto al cdigo que cambia contnuamente
Podra asegurarse de que el cdigo tuviera muchos comentarios Que el lenguaje de programacin sea legible (lo que sea que signifique) Prohibir los goto (si es que eso soluciona algo) Escribir mucha documentacin interna Intentar que estuviese al da con respecto al cdigo que cambia contnuamente
Pero, afectara realmente hacer todas estas cosas a la viabilidad tcnica de este sistema?
Probablemente NO, porque estos remedios caseros no atacan la raz del problema, que consiste en que el mundo real est verdaderamente coambiando, y la defensa Manigot intenta negarlo. La actitud de la Lnea Manigot impregna casi todas las herramientas de la industria de la programacin, sus metodologa y sus conceptos. los lenguajes de programacin responsabilizan de convertir los archivos fuente en cdigo ejecutable. Pero este cdigo es frgil y poco maleable eficiente, pero incapaz de resistir los impactos del exterior. La actitud de la Lnea Maginot hace que la maleabilidad sea responsabilidad del programador, y no de sus herramientas.
La mentalidad de la Lnea 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 daos 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 frgiles y casi inmutables sistemas de software.
cambios
sistemas de software
La defensa Suiza
El plan de negocios de la empresa de Elizabeth equivale a rechazar explcitamente la defensa de la Lnea Manigot. Tienen la intencin de construir un producto como prototipo, y lo utilizarn para atraer clientes, que sern quienes les paguen para cambiar su prototipo de modo que resuelva sus necesidades. La empresa de Elizabeth no puede proscribir el cambio, ni despachrselo a un grupo de mantenimiento. Su plan requiere una visin radicalmente distinta acerca del proceso de desarrollo de software se trata de una visin que trata el cambio como parte vital e inteligente del proceso global de desarrollo de software.
La defensa Suiza
La empresa de Elizabeth podra estar planeando utilizar algo parecido a la estrategia de defensa Suiza, contempornea de la Lnea Maginot. en lugar de invertir en una costosa (y a juzgar por sus vecinos, poco fiable) defensa de sus fronteras, Suiza se declar pas abierto, y daba la bienvenida a los visitantes de cualquier pas, raza o religin. Esta poltica 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 ms 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 Lnea Maginot de defensa no es aplicable, como, por ejemplo, en la ingeniera 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 cdigo fuente de todo el sistema est disponible de forma inmediata para cualquier programador, y todo el entorno de programacin de ese programador se puede modificar inmediatamente en casi cualquier aspecto, sin ms que modificar unas pocas lneas de cdigo.
La defensa Suiza
Advertencia!
En este curso no vamos a promover la lnea 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 filosofa de Smalltalk-80 son, casi con certeza, inadecuadas para proyectos de esta escala. La eficiencia de la mquina es una razn bastante evidente. Smalltalk exige mucho a los recursos de la mquina, puesto que invierte potencia de clculo cuantiosamente para ofrecer capacidades de productividad como la recoleccin automtica de basura, una interfaz de usuario muy grfica y un entorno uniforme basado en objetos.
La defensa Suiza
Advertencia!
El control es una razn an ms fundamental. El sistema de la compaa de Elizabeth implicar a un gran nmero de programadores, que deben trabajar en grupo como una organizacin coordinada, si es que un sistema de semejante complejidad ha de llegar a ser suministrado algn da. 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 podra tratarse a travs del potente conjunto de herramientas que ofrece Smalltalk para gestionar los cambios.
La defensa Suiza
Advertencia!
La compatibilidad es la razn ms fundamental, y es casi imposible de superar. Casi todas las organizaciones modernas tienen al menos algn tipo de inversin previa en software, desarrollado en lenguajes anteriores, y los clientes insistirn 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 hbrida
La defensa hbrida es parecida a la que preferira un militar experto en combate, combinando todas las posibles estrategias en una combinacin 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 dems tcticas pacficas para evitar los disparos, desde el primer momento.
La defensa hbrida
El dogma convencional de la ingeniera de software consiste en construir:
sistemas de software eficientes (pero frgiles)
La defensa hbrida
El dogma convencional de la ingeniera de software consiste en construir:
estructuras estticas de defensa que los protegen de los cambios
rodeados por
sistemas de software eficientes (pero frgiles)
La defensa hbrida
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 an se puede hacer ms:
Es posible hacer que los sistemas que sean maleables permitiendo que haya una cierta elasticidad en la ejecucin. Esto implica suavizar la exigencia habitual de que todo se haga en el momento de la compilacin (dynamic binding)
La defensa hbrida
Hacer sistemas que cambien ms fcilmente hacindolos ms pequeos y ligeros, y transformando, de esta manera, la funcionalidad tpica de un sistema en algo del tamao de un programa. Las tcnicas de encapsulacin y de herencia, hacen esto,integrando la reutilizabilidad en el aspecto principal del proceso de desaroollo de software
La defensa hbrida
Hacer sistemas que cambien ms fcilmente hacindolos ms pequeos y ligeros, y transformando, de esta manera, la funcionalidad tpica de un sistema en algo del tamao de un programa. Las tcnicas de encapsulacin y de herencia, hacen esto,integrando la reutilizabilidad en el aspecto principal del proceso de desaroollo de software Los sistemas pueden encapsular ms cuando adoptan la forma de objetos, que se pomportan como cajas negras blindadas, para limitar el efecto de transmisin cuando llega a tener lugar una penetracin de las defensas estticas. 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 solucin 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 ms tolerante con respecto al cambio:
La encapsulacin es el fundamento de todo este enfoque. Su contribucin consiste en restringir los efectos del cambio, situando un muro de cdigo 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 cmo hacer y ahora especificar el qu hacer.
No intentaremos dar una solucin 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 ms tolerante con respecto al cambio:
La herencia es la parte ms innovadora del enfoque. Se trata de una herramienta para retransmitir automticamente el cdigo a clases desarrolladas por distintos miembros de un equipo. Los programadores ya no empiezan cada mdulo 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 cmo estas tcnicas se aplican al problema de Elizabeth, examinemos de manera ms detallada las posibilidades del sistema prototipo, y la forma en que deben cambiar al transcurrir el tiempo.
El sistema inicial admitir un cierto nmero de objetos genricos de oficina:
Escritorio
Carpetas Buzones Sobres
Memos
NotaMientrasEstabasFuera
Escritorio
Carpetas Buzones Sobres
Memos
NotaMientrasEstabasFuera
El prototipo debe mostrar que el diseo 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 ms 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 dbilmente acopladas, Dbilmente acopladas: Es el grado en que el diseo de la coleccin depende del diseo de su contenido. Evidentemente, un escritorio electrnico no puede ser rediseado y recompilado cada vez que se agregue un nuevo objeto electrnico, puesto que el usuario toma esta decision en el momento de ejecucin. Mas an, 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 electrnico necesita relacionarse con su contenido.
Ejemplo:
Muestra un men con el contenido actual y ayuda al usuario a seleccionar el siguiente objeto que debe leer detalladamente.
Buzn muestraContenido:
Ejemplo:
Para realizar esta opcin, debe haber una forma de obtener informacin resumida acerca de todos los objetos que puedan aparecer en el buzn, y esto equivale a una operacin que el buzn debe aplicar a su contenido.
Ejemplo:
Memorando
muestraResumenMemorando:
Sobre
muestraResumenSobre:
Carpeta
muestraResumenCarpeta:
Para realizar esta opcin, debe haber una forma de obtener informacin resumida acerca de todos los objetos que puedan aparecer en el buzn, y esto equivale a una operacin que el buzn debe aplicar a su contenido.
Esta clase de problema no es fcil de resolver con los lenguajes de programacin convencionales, porque la programacin convencional hace que el consumidor de un operando sea responsable de seleccionar el operador apropiado para el tipo de operando en cuestin. En este caso, el desarrollador del buzn es el consumidor de los objetos que hay que enviar por correo. Para obtener una informacin resumida de estos objetos correctamente, debe seleccionar operadores (funciones) que extraigan de alguna manera la informacin necesaria de los distintos objetos. La solucin habitual consiste en almacenar el tipo dentro de cada objeto en un lugar estndar, de este modo: struct item { int codigoTipo; ...} Y comprobar despus el tipo mediante una sentencia switch.
Basndose en el tipo de objeto, el buzn puede llamar a la funcin 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 despus el tipo mediante una sentencia switch. Obsrvese lo que sucede si Elizabeth llega realmente a intentar construir un sistema as.
Programacin orientada a objetos El cdigo del buzn depende ahora explcitamente de los tipos de elementos que eran conocidos cuando se escribi el buzn. 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; } ... }
Las sentencias case indican explcitamente que este buzn no funcionar para contenidos que no sean MEMORANDO, CARPETA, NOTAMIENTRASESTABASFUERA y SOBRE
Programacin orientada a objetos El cdigo del buzn depende ahora explcitamente de los tipos de elementos que eran conocidos cuando se escribi el buzn. 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; } ... }
Las sentencias case indican explcitamente que este buzn 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 cdigo del buzn debe ser cambiado y recopilado.
An ms, estas sentencias switch no estn 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. Obsrvese lo que sucede cuando la responsabilidad de seleccionar la forma de realizar cada orden se traslada al proveedor del objeto, en lugar de asignrsele 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 cdigo del consumidor no necesita preocuparse. Cuando se extiende el sistema con un nuevo tipo de objeto, el cambio no se extiende ms all del cdigo que haya sido escrito por el proveedor del objeto. Esta encapsulacin hace que los sistemas sean ms maleables, restringiendo el dao 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 comn, puesto que se trata solamente de diferentes clases de contenedores.
La herencia permite que sus similitudes estn descritas en un lugar central (una clase Contenedor) y que sean retransmitidas a todas las clases que se comporten como contenedores.
Contenedor
caracterstica_A:
Escritorio
Carpeta
Sobre
La herencia permite que sus similitudes estn descritas en un lugar central (una clase Contenedor) y que sean retransmitidas a todas las clases que se comporten como contenedores.
Contenedor
caracterstica_A:
Escritorio
caracterstica_A:
Carpeta
caracterstica_A:
Sobre
caracterstica_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 estndar. Los sobres, carpetas y buzones se describen de la misma manera. Dado que la funcionalidad genrica se puede desarrollar una vez, y se puede utilizar en muchas ocasiones, la herencia proporciona un fuerte incremento de productividad.
Resulta ms difcil e impensable desarrollar un nuevo cdigo partiendo de cero, porque es casi siempre ms sencillo heredar unas capacidades portentes y probadas a partir de una biblioteca de trabajo anterior.
Contacto: acaceres@computacion.cs.cinvestav.mx abdiel@mazatlan.udo.mx

Abdiel E. Cceres Gonzlez Centro de Investigacin y de Estudios Avanzados - IPN Mxico D.F., Mxico. 2004

Poo 01

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Poo 01

Uploaded by

Copyright:

Available Formats

Programacin orientada a objetos

Pueden utilizar el mismo esquema por mucho tiempo

Atraer nuevos clientes

La crisis del software

La crisis del software

Desencanto de los clientes

La crisis del software

Desencanto de los clientes

La crisis del software

Desencanto de los clientes

Desgracia personal de Elizabeth

La crisis del software

La crisis del software

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

La crisis del software

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

La crisis del software

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

La crisis del software

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

Nuestro enemigo: El cambio

Nuestro enemigo: El cambio

Nuestro enemigo: El cambio

Nuestro enemigo: El cambio

Nuestro enemigo: El cambio

Hay ingenieros de software que dicen:

Nuestro enemigo: El cambio

Hay ingenieros de software que dicen:

Nuestro enemigo: El cambio

Nuestro enemigo: El cambio

En un safari, es lgico matar mosquitos, porque la malaria es un problema real e importante.

Nuestro enemigo: El cambio

En un safari, es lgico matar mosquitos, porque la malaria es un problema real e importante.

Nuestro enemigo: El cambio

Nuestro enemigo: El cambio

del cambio dijeron?

S, pero de ese cambio no estamos hablando

La lnea de defensa Manigot

La lnea de defensa Manigot

La lnea de defensa Manigot

La lnea de defensa Manigot

La lnea de defensa Manigot

La lnea de defensa Manigot

La lnea de defensa Manigot

La lnea de defensa Manigot

La lnea de defensa Manigot

La lnea de defensa Manigot

Podra asegurarse de que el cdigo tuviera muchos comentarios

La lnea de defensa Manigot

La lnea de defensa Manigot

La lnea de defensa Manigot

La lnea de defensa Manigot

La lnea de defensa Manigot

La lnea de defensa Manigot

La lnea de defensa Manigot

Puede funcionar esta defensa a efectos del software?

El dogma convencional de la ingeniera de software consiste en construir:

sistemas de software eficientes (pero frgiles)

El dogma convencional de la ingeniera de software consiste en construir:

estructuras estticas de defensa que los protegen de los cambios

estructuras estticas de defensa que los protegen de los cambios

estructuras estticas de defensa que los protegen de los cambios

sistemas de software eficientes (pero frgiles)