P. 1
POO-01

POO-01

|Views: 0|Likes:
Published by Victor Hernandez

More info:

Published by: Victor Hernandez on Dec 19, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

12/19/2011

pdf

text

original

Programación orientada a objetos

Abdiel E. Cáceres González Centro 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.

lo que es mejor.Construcción de sistemas • La innovación de Whitney consistió en dividir el trabajo. • Esto daba lugar a unas economías tan apreciables que los costos de fabricacion desminuyeron drásticamente y. simplificando muchísimo su problema de reparación de armas de fuego. ajustándose a un cierto estándar especificado. de tal manera que cada pieza era producida por un especialista. utilizando herramientas sofisticadas para optimizar aquella tarea. . el cliente de Whitney se dio cuenta rápidamente que los estándares permitirían el intercambio de piezas. Cada armero se centraba en una sola pieza.

Las dos redefinen la unidad de modularidad. en lugar de hacer esto. Estos componentes se denominan SW-IC para resaltar su similitud con el chip integrado de silicio. las mismas.Construcción de sistemas • • La importancia de la POO es comparable a la que tuvo la innovación de las piezas intercambiables producida por Whitney. producen componentes SW reutilizables. en gran parte. una innovación similar que ha revolucionado la industria del HW de computadoras. que son las sentencias y expresiones desnudas de un lenguaje de programación. ensamblando los componentes de otros programadores. y por razones que son. 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. de tal manera que los trabajadores producen subcomponentes en lugar de soluciones completas.

como compañías de seguros.¿Qué es construir un sistema? Sistema supermoderno con tecnología de estaciones de trabajo distribuídas y gráficas para gestionar formularios de oficina en general 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. . gobierno. bancos.

¿Qué es construir un sistema?

SolicitudDePermisoDeConducir

FormularioParaSolicitudDeCredito

Memorandum

Sistema supermoderno con tecnología de estaciones de trabajo distribuídas y gráficas para gestionar formularios de oficina en general

...

CuponDeGastoDeViaje

NotaMientrasNoEstabas

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.

FormularioParaAtestadosDeSeguros

¿Qué es construir un sistema?

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.
Sistema supermoderno con tecnología de estaciones de trabajo distribuídas y gráficas para gestionar formularios de oficina en general

$$

$$

$$
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.

¿Qué es construir un sistema?

el sistema le gustará a los clientes, porque ataca los costos de manejo de papel dificultad de conseguir personal calificado

Sistema supermoderno con tecnología de estaciones de trabajo distribuídas y gráficas para gestionar formularios de oficina en general

Pueden utilizar el mismo esquema por mucho tiempo

Elizabeth Aduen

Atraerá nuevos clientes

El prototipo

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.

¿Qué es construir un sistema?

• •

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
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.

por supuesto. 3% 19% 2% 29% 47% Pagados sin ser suministrados Suministrados pero sin utilizarse Usado tal como se suministró Abandonado o reformado Utilizado 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. incluso siendo menos ambisiosos que el presente. .La crisis del software • • Esto es posible. Pero desafortunadamente. no es probable. La industria de la programación tiene un historial muy malo con respecto a la construcción de sistemas.

.La crisis del software Desencanto de los clientes El resultado probable es que se cancele el proyecto de Elizabeth antes de que se produzca ni siquiera una línea de código.

La crisis del software Desencanto de los clientes Bancarrota de la empresa El resultado probable es que se cancele el proyecto de Elizabeth antes de que se produzca ni siquiera una línea de código. .

La crisis del software Desencanto de los clientes Bancarrota de la empresa Desgracia personal de Elizabeth El resultado probable es que se cancele el proyecto de Elizabeth antes de que se produzca ni siquiera una línea de código. .

La crisis del software Se exceden los presupuestos No se alcanzan los objetivos en los plazos establecidos Falta coltrol Baja calidad Síntomas fatales Cancelación y desgracia .

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? El HW no es un problema. y más . porque que HW actual es capaz de admitir sistemas de este tipo.

porque que HW actual es capaz de admitir sistemas de este tipo. y más a) Los sistemas distribuidos no son nada nuevo b) Las interfaces orientadas a formularios no son nada nuevo c) Sistemas nuevo de correo electrónico los hay muy sofisticados d) Los sistemas de archivos e) Estaciones de trabajo .La crisis del software ¿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 nuevo b) Las interfaces orientadas a formularios no son nada nuevo c) Sistemas nuevo de correo electrónico los hay muy sofisticados d) Los sistemas de archivos e) Estaciones de trabajo Estas tecnologías se han utilizado por separado.La crisis del software ¿Que es lo que hace que el sistema de Elizabeth sea tan ambicioso? El HW no es un problema. y juntas pueden ocasionar problemas .

nuestras metodologías ni nuestros conceptos.El verdadero problema es que este sistema imlica una actitud hacia el cambio que no contemplan nuestras herramientas de programación. .

Software es la responsable de definir el nuevo sistema. y qué es lo que debe ser la responsabilidad de los demás miembros del equipo? La arquitectura del sistema involucra .Nuestro enemigo: El cambio Elizabeth. Pero ¿Qué significa esto?¿Cuáles son las actividades de Elizabeth. como Ing.

como Ing. y qué es lo que debe ser la responsabilidad de los demás miembros del equipo? La arquitectura del sistema involucra código .Nuestro enemigo: El cambio Elizabeth. Software es la responsable de definir el nuevo sistema. Pero ¿Qué significa esto?¿Cuáles son las actividades de Elizabeth.

Nuestro enemigo: El cambio Elizabeth. Software es la responsable de definir el nuevo sistema. y qué es lo que debe ser la responsabilidad de los demás miembros del equipo? La arquitectura del sistema involucra código . como Ing. 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 diseño . Pero ¿Qué significa esto?¿Cuáles son las actividades de Elizabeth. Software es la responsable de definir el nuevo sistema. como Ing.Nuestro enemigo: El cambio Elizabeth.

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í .Nuestro enemigo: El cambio • 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.

probablemente. Seleccionar una estrategia de redes para interconectar estas piezas entre sí • • • . y su principal responsabilidad consistiría en Definir qué componentes de software van en cada evitar el peligro estadísticamente sitio probable.Nuestro enemigo: El cambio • Hay ingenieros de software que dicen: • • • Elizabeth debería una arquitectura? ¿Esto es empezar por seleccionar los componetes de hardware ¿Es más bien una fase inicial del Después decidir la forma en que deben estar diseño? Elizabeth sería relacionados. la primera que Las tareas de Elizabeth son: revisara el proyecto desde el punto de vista de la posibilidad técnica Refinar la configuracion de hardware del sistema de hacerlo.

haría poco por mejorar la prognosis de este proyecto. porque el proyecto podría.Nuestro enemigo: El cambio • Desde luego. software y de red. no podría desentenderse de las responsabilidades tradicionales de un ingeniero de software. • . ciertamente. Pero una brillante descomposición en componentes de hardware. fracasar como consecuencia de unas especificaciones técnicas mal hechas y mal documentadas.

Nuestro enemigo: El cambio En un safari. porque la malaria es un problema real e importante. es lógico matar mosquitos. .

Pero no es lógico hacerlo cuando se intenta detener a un elefante que se aproxima enfurecido.Nuestro enemigo: El cambio En un safari. es lógico matar mosquitos. porque la malaria es un problema real e importante. .

. que es el mayor oponente y más peligroso al que pueda enfrentarse cualquier proyecto de software.Nuestro enemigo: El cambio Elizabeth se enfrenta a un ataque mediante el cambio. y sus primeros esfuerzos deberían ir encaminados a defender este proyecto contra la destrucción a manos del cambio.

pero de ese “cambio” no estamos hablando .Nuestro enemigo: El cambio ¿“del cambio” dijeron? Sí.

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. . 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. como la famosa línea de defensa Manigot. Las defensas contra Italia suelen llamarse tambien Línea Alpina). (el termino línea Maginot se refiere al sistema entero o en ocaciones unicamente se usa para referirse a las defensas contra Alemania.

. La línea Maginot compretde 108 fuertes principales a 15 km de distancia entre si. en las diviciones alemanas la rodean y atacan en la region de Sedan. mutitud se pequeños fuertes y mas de 100 km de galerias. 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. Error de estrategia La línea no evita la derrota de Francia al comienzo de la Segunda Guerra Mundial en 1940. por el contrario. quien fue su promotor. los ejercito aliados fueron cortados en dos. Su costo total fue 5 Millardos de FF (de la epoca). en su extremidad occidental.La línea de defensa Manigot Este sistema debe su nombre a André Maginot. siendo de una gran complejidad tecnológica y militar.

que contiene un único versículo. El software. . antes de realizar ningún trabajo adicional.La línea de defensa Manigot Todos los directores de programación conocen este único capítulo. y estas se discuten con el cliente. debe ser desarrollado determinando primero los requisitos del sistema. y documentándolos Los requisitos se transforman en especificaciones. y sobretodo los grandes sistemas de software. que en última instancia las aprueba y las firma.

se desarrolla toda una serie de diseños. . los diseños se transforman en código. Por último. que se revisan y documentan exhaustivamente como especificaciones formales de diseño. suponiendo que se haya seguido un proceso de diseño suficientemente riguroso.La línea de defensa Manigot Una vez que los requisitos se han inmovilizado. Se prueba el código (por si acaso hubiera un error) y finalmente se le suministra al cliente. éste paso debiera ser rutinario.

el cliente tiene que estar satisfecho con el resultado.La línea de defensa Manigot Por supuesto. ¿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 . el trabajo debe ser planeado cuidadosamente. puesto que el sistema suministrado será precisamente el sistema que él dio por bueno originalmente. Si suponemos esto.

La línea de defensa Manigot ¿Cuál es la solución? .

. muy lejos de la corriente de nuevos y excitantes desarrollos. que se lleva a cabo donde nadie lo vea. que es donde se encuentran los programadores con verdadero talento. en la trastienda.La línea de defensa Manigot ¿Cuál es la solución? El mantenimiento Una actividad sucia.

que necesitan nuestra atención. Pero sí tiene fallos. o algo que siempre ha estado roto. La evolución consiste en cambiar para avanzar.La línea de defensa Manigot 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. Esto no es mantenimiento. no es mantenerse firmes para evitar la caída. a medida que el entorno que circunda al SW va cambiando. . es preciso invertir energía para que esté al día. encerado o limpiado. Por otra parte. aunque esto NO SEA MANTENIMIENTO. La reparación es arreglar algo que se ha roto por jugar con ello. sino REPARACION.

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

La línea de defensa Manigot Podría asegurarse de que el código tuviera muchos comentarios .

La línea de defensa Manigot Podría asegurarse de que el código tuviera muchos comentarios Que el lenguaje de programación sea legible (lo que sea que signifique) .

La línea de defensa Manigot Podría asegurarse de que el código tuviera muchos comentarios Que el lenguaje de programación sea legible (lo que sea que signifique) Prohibir los goto (si es que eso soluciona algo) .

La línea de defensa Manigot Podría asegurarse de que el código tuviera muchos comentarios Que el lenguaje de programación sea legible (lo que sea que signifique) Prohibir los goto (si es que eso soluciona algo) Escribir mucha documentación interna .

La línea de defensa Manigot Podría asegurarse de que el código tuviera muchos comentarios Que el lenguaje de programación sea legible (lo que sea que signifique) Prohibir los goto (si es que eso soluciona algo) Escribir mucha documentación interna Intentar que estuviese al día con respecto al código que cambia contínuamente .

La línea de defensa Manigot Podría asegurarse de que el código tuviera muchos comentarios Que el lenguaje de programación sea legible (lo que sea que signifique) Prohibir los goto (si es que eso soluciona algo) Escribir mucha documentación interna 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? .

Pero este código es frágil y poco maleableñ eficiente. sus metodología y sus conceptos. y la defensa Manigot intenta negarlo. La actitud de la Línea Maginot hace que la maleabilidad sea responsabilidad del programador. pero incapaz de resistir los impactos del exterior. que consiste en que el mundo real está verdaderamente coambiando. .La línea de defensa Manigot Probablemente NO. y no de sus herramientas. porque estos remedios caseros no atacan la raíz del problema. los lenguajes de programación responsabilizan de convertir los archivos fuente en código ejecutable. La actitud de la Línea Manigot impregna casi todas las herramientas de la industria de la programación.

tarde o temprano). Cuando esto no tiene éxito (y siempre acaba por fallar. cambios sistemas de software . la tarea de reparar los daños se les para a los de la trastienda.La línea de defensa Manigot La mentalidad de la Línea Maginot gestiona el cambio a base de intentar impedir que se produzca. 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. El resto del equipo pasa al proyecto siguiente. al equipo 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. Tienen la intención de construir un producto como prototipo. ni despachárselo a un grupo de mantenimiento. que serán quienes les paguen para cambiar su prototipo de modo que resuelva sus necesidades. .La defensa Suiza El plan de negocios de la empresa de Elizabeth equivale a rechazar explícitamente la defensa de la Línea Manigot. La empresa de Elizabeth no puede proscribir el cambio. y lo utilizarán para atraer clientes.

Suiza se declaró país abierto. cuyas consecuencias estremecieron al mundo. de la Segunda Guerra Mundial. poco fiable) defensa de sus fronteras. . raza o religión. y daba la bienvenida a los visitantes de cualquier país. en lugar de invertir en una costosa (y a juzgar por sus vecinos. y al mismo tiempo obtuvieron unos beneficios bastante decentes de todos los implicados.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. sin más que adaptarse a los sucesos con agilidad. Esta política les permitió capear el temporal.

y todo el entorno de programación de ese programador se puede modificar inmediatamente en casi cualquier aspecto. y sumamente complicados. No hay un sistema operativo protegido (y por lo tanto inmutable). . sin más que modificar unas pocas líneas de código. en la ingeniería del conocimiento. está descompuesto en objetos blindados. porque ya ha sido aplicada en varios sistemas especializados. como. Los creadores de Smalltalk-80 construyeron un sistema que es posible deformar en casi cualquier sentido.La defensa Suiza ¿Puede funcionar esta defensa a efectos del software? Es probable que así sea. Todo el sistema. Smalltalk-80 es uno de los ejemplos de otros entornos en los cuales la Línea Maginot de defensa no es aplicable. que se comunican enviando mensajes. incluso bajando a nivel de hardware. El código fuente de todo el sistema está disponible de forma inmediata para cualquier programador. por ejemplo.

una interfaz de usuario muy gráfica y un entorno uniforme basado en objetos. hay varias razones por las cuales otras partes de la filosofía de Smalltalk-80 son. . clases y herencia ofrecen un gran potencial para construir sistemas grandes y maleables. casi con certeza. mensajes. La eficiencia de la máquina es una razón bastante evidente. inadecuadas para proyectos de esta escala. puesto que invierte potencia de cálculo cuantiosamente para ofrecer capacidades de productividad como la recolección automática de basura. Aunque los conceptos de objetos.La defensa Suiza ¡Advertencia! En este curso no vamos a promover la línea de defensa Suiza como manera de construir sistemas grandes. Smalltalk exige mucho a los recursos de la máquina.

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

La defensa Suiza ¡Advertencia! La compatibilidad es la razón más fundamental. . y los clientes insistirán en que el software anterior siga siendo viable. desarrollado en lenguajes anteriores. Casi todas las organizaciones modernas tienen al menos algún tipo de inversión previa en software. 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. y es casi imposible de superar.

formadas por ordenes o mandatos. Se hace uso de la maniobrabilidad para evitar ataques.La defensa híbrida La defensa híbrida es parecida a la que preferiría un militar experto en combate. . para proporcionar un conocimiento del terreno. Se utilizan parapetos defensivos para defender las estructuras importantes contra ataques frontales Se emplean unidades dispersas. 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. combinando todas las posibles estrategias en una combinación activa.

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: estructuras estáticas de defensa que los protegen de los cambios estructuras estáticas de defensa que los protegen de los cambios estructuras estáticas de defensa que los protegen de los cambios rodeados por sistemas de software eficientes (pero frágiles) estructuras estáticas de defensa que los protegen de los cambios estructuras estáticas de defensa que los protegen de los cambios .

parchar el sistema) no es manera de construir complejos sistemas de software.La defensa híbrida El valor de esto no se puede negar. 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. puesto que el cambio incontrolado (”hacking”. Esto implica suavizar la exigencia habitual de que todo se haga en el momento de la compilación (dynamic binding) .

hacen esto.integrando la reutilizabilidad en el aspecto principal del proceso de desaroollo de software . Esto implica suavizar la exigencia habitual de que todo se haga en el momento de la compilación (dynamic binding) Hacer sistemas que cambien más fácilmente haciéndolos más pequeños y ligeros. la funcionalidad típica de un sistema en algo del tamaño de un programa.La defensa híbrida El valor de esto no se puede negar. parchar el sistema) no es manera de construir complejos sistemas de software. Las técnicas de encapsulación y de herencia. 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. y transformando. de esta manera. puesto que el cambio incontrolado (”hacking”.

. 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. parchar el sistema) no es manera de construir complejos sistemas de software. Un cambio de una parte del sistema no tiene por qué afectar al resto del sistema. y transformando.La defensa híbrida El valor de esto no se puede negar. Las técnicas de encapsulación y de herencia. para limitar el efecto de transmisión cuando llega a tener lugar una penetración de las defensas estáticas. la funcionalidad típica de un sistema en algo del tamaño de un programa. que se pomportan como cajas negras blindadas. sino que puede tratar desde el principio el interior de la parte afectada. Esto implica suavizar la exigencia habitual de que todo se haga en el momento de la compilación (dynamic binding) Hacer sistemas que cambien más fácilmente haciéndolos más pequeños y ligeros.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. de esta manera. hacen esto. puesto que el cambio incontrolado (”hacking”.

Todo el acceso a los datos está gestionado mediante procedimientos. 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. que se han puesto allí para hacer de mediadores en el acceso a los datos. Su contribución consiste en restringir los efectos del cambio. . situando un muro de código en torno a cada dato.Programación orientada a objetos • No intentaremos dar una solución que vaya a eliminar por arte de magia problemas de esta magnitud. Olvidarse del “cómo hacer” y ahora especificar el “qué hacer”.

. Se trata de una herramienta para retransmitir automáticamente el código a clases desarrolladas por distintos miembros de un equipo. Cada una de las sentencias subsiguientes describe la forma en que la nueva clase se diferencia de la que está en la biblioteca. sino que. escriben una sola sentencia que se refiere a una clase que ya esta en la biblioteca. Los programadores ya no empiezan cada módulo con una pagina en blanco. Pero sí vamos a proponer varios conceptos y herramientas.Programación orientada a objetos • No intentaremos dar una solución que vaya a eliminar por arte de magia problemas de esta magnitud. 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.

El sistema inicial admitirá un cierto número de objetos genéricos de oficina: .Programación orientada a objetos 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.

y la forma en que deben cambiar al transcurrir el tiempo. examinemos de manera más detallada las posibilidades del sistema prototipo.Programación orientada a objetos Para ver cómo estas técnicas se aplican al problema de Elizabeth. Escritorio Carpetas Buzones Sobres Memos NotaMientrasEstabasFuera El sistema inicial admitirá un cierto número de objetos genéricos de oficina: .

debe mostrar que estos objetos de oficina pueden emular la forma en que se comportan los objetos de oficina más familiares. examinemos de manera más detallada las posibilidades del sistema prototipo. Por ejemplo. . Escritorio Carpetas Buzones Sobres Memos NotaMientrasEstabasFuera El sistema inicial admitirá un cierto número de objetos genéricos de oficina: El prototipo debe mostrar que el diseño de Elizabeth satisface los objetivos del sistema. y que el sistema se puede extender con nuevos objetos de oficina en un momento posterior.Programación orientada a objetos Para ver cómo estas técnicas se aplican al problema de Elizabeth. y la forma en que deben cambiar al transcurrir el tiempo.

sobres. Evidentemente. . puesto que un escritorio electrónico necesita relacionarse con su contenido. un escritorio electrónico no puede ser rediseñado y recompilado cada vez que se agregue un nuevo objeto electrónico. el repertorio de objetos que debe contener el escritorio irá cambiando con el tiempo. puesto que el usuario toma esta decision en el momento de ejecución. buzones y carpetas son colecciones débilmente acopladas. Mas aún. debe existir un cierto grado de acoplamiento. a medida que el sistema se extienda con nuevos tipos de formularios de oficina. Sin embargo.Programación orientada a objetos Los escritorios. Débilmente acopladas: Es el grado en que el diseño de la colección depende del diseño de su contenido.

Programación orientada a objetos Ejemplo: Muestra un menú con el contenido actual y ayuda al usuario a seleccionar el siguiente objeto que debe leer detalladamente. Buzón muestraContenido: .

debe haber una forma de obtener información resumida acerca de todos los objetos que puedan aparecer en el buzón. Buzón muestraContenido: Para realizar esta opción. . y esto equivale a una operación que el buzón debe aplicar a su contenido.Programación orientada a objetos Ejemplo: Muestra un menú con el contenido actual y ayuda al usuario a seleccionar el siguiente objeto que debe leer detalladamente.

y esto equivale a una operación que el buzón debe aplicar a su contenido.Programación orientada a objetos Ejemplo: Memorando muestraResumenMemorando: Sobre muestraResumenSobre: Muestra un menú con el contenido actual y ayuda al usuario a seleccionar el siguiente objeto que debe leer detalladamente. Buzón muestraContenido: Carpeta muestraResumenCarpeta: 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.

. debe seleccionar operadores (funciones) que extraigan de alguna manera la información necesaria de los distintos objetos.Programación orientada a objetos Esta clase de problema no es fácil de resolver con los lenguajes de programación convencionales. Para obtener una información resumida de estos objetos correctamente.. 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.} Y comprobar después el tipo mediante una sentencia switch.. de este modo: struct item { int codigoTipo. . La solución habitual consiste en almacenar el tipo dentro de cada objeto en un lugar estándar.

case CARPETA:mostrarResumenCarpeta(objetoSiguiente).break. el buzón puede llamar a la función correcta para ese tipo: mostrarResumenDe(objetoSiguiente) struct objeto *objetoSiguiente..Programación orientada a objetos Basándose en el tipo de objeto. case NOTAMIENTRASESTABASFUERA:mostrarResumenNota(objetoSiguiente). } .. . { switch(objetoSiguiente->codigoTipo) { case MEMORANDO:mostrarResumenMemo(objetoSiguiente). } Y comprobar después el tipo mediante una sentencia switch.break. Obsérvese lo que sucede si Elizabeth llega realmente a intentar construir un sistema así.break.break. case SOBRE:mostrarResumenSobre(objetoSiguiente).

case SOBRE:mostrarResumenSobre(objetoSiguiente).break. case NOTAMIENTRASESTABASFUERA:mostrarResumenNota(objetoSiguiente). case CARPETA:mostrarResumenCarpeta(objetoSiguiente). CARPETA..break.break. } Las sentencias case indican explícitamente que este buzón no funcionará para contenidos que no sean MEMORANDO.. { switch(objetoSiguiente->codigoTipo) { case MEMORANDO:mostrarResumenMemo(objetoSiguiente). mostrarResumenDe(objetoSiguiente) struct objeto *objetoSiguiente. NOTAMIENTRASESTABASFUERA y SOBRE .Programación orientada a objetos El código del buzón depende ahora explícitamente de los tipos de elementos que eran conocidos cuando se escribió el buzón. } .break.

case SOBRE:mostrarResumenSobre(objetoSiguiente).break.break.. } . el código del buzón debe ser cambiado y recopilado. . NOTAMIENTRASESTABASFUERA y SOBRE Cada vez que se agrega un nuevo tipo de dato a este sistema.Programación orientada a objetos El código del buzón depende ahora explícitamente de los tipos de elementos que eran conocidos cuando se escribió el buzón. { switch(objetoSiguiente->codigoTipo) { case MEMORANDO:mostrarResumenMemo(objetoSiguiente). } Las sentencias case indican explícitamente que este buzón no funcionará para contenidos que no sean MEMORANDO. case CARPETA:mostrarResumenCarpeta(objetoSiguiente).break. CARPETA. mostrarResumenDe(objetoSiguiente) struct objeto *objetoSiguiente.break. case NOTAMIENTRASESTABASFUERA:mostrarResumenNota(objetoSiguiente)..

Programación orientada a objetos Aún más. . será necesario cambiar todas y cada una de las sentencias switch para agregar un caso para el nuevo tipo. Cada que se agregue un nuevo tipo de datos. } . Obsérvese lo que sucede cuando la responsabilidad de seleccionar la forma de realizar cada orden se traslada al proveedor del objeto.. Reflejan la responsabilidad del consumidor en lo que respecta a seleccionar operadores que sean compatibles con tipos de operandos. estas sentencias switch no están localizadas en ninguna manera. { [objetoSiguente mostrarResumen].. así que aparecen a lo largo de todo el sistema. en lugar de asignársele al consumidor: mostrarResumenDe(objetoSiguiente) struct objeto *objetoSiguiente.

Programación orientada a objetos Esto ordena al objeto llamado objetoSiguiente que lleve a cabo la orden denominada mostrarResumen... { [objetoSiguente mostrarResumen]. mostrarResumenDe(objetoSiguiente) struct objeto *objetoSiguiente. . } .

. memorandos.Programación orientada a objetos Esto ordena al objeto llamado objetoSiguiente que lleve a cabo la orden denominada mostrarResumen. El consumidor no sabe. } . y sobres pueden mostrarResumen de formas muy diferentes. Esta encapsulación hace que los sistemas sean más maleables. ni le importa. el código del consumidor no necesita preocuparse. mostrarResumenDe(objetoSiguiente) struct objeto *objetoSiguiente. Aunque distintas clases de objetos. el cambio no se extiende más allá del código que haya sido escrito por el proveedor del objeto. { [objetoSiguente mostrarResumen]. Cuando se extiende el sistema con un nuevo tipo de objeto.. restringiendo el daño que puede causar un cambio. como carpetas. . la forma en que objetoSiguiente lleva a cabo mostrarResumen. porque ésto es responsabilidad del que suministra objetoSiguiente.

tipos distintos de objetos. Los escritorios. puesto que se trata solamente de diferentes clases de contenedores. al contrario. . sirve para retransmitir los efectos a lo largo y ancho de todo el sistema. Sin embargo.Programación orientada a objetos La herencia. la verdad es que tienen muchas cosas en común. carpetas. a primera vista. sobres y buzones son.

Contenedor característica_A: Escritorio Carpeta Sobre .Programación orientada a objetos 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.

Programación orientada a objetos 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. Contenedor característica_A: Escritorio característica_A: Carpeta característica_A: Sobre característica_A: .

Los sobres. porque es casi siempre más sencillo heredar unas capacidades portentes y probadas a partir de una biblioteca de trabajo anterior. En lugar de hacer esto. carpetas y buzones se describen de la misma manera. la herencia proporciona un fuerte incremento de productividad.Programación orientada a objetos El desarrollador de escritorios no necesita construir estas propiedades comunes. Dado que la funcionalidad genérica se puede desarrollar una vez. describe la forma en que los escritorios difieren de los contenedores estándar. . Resulta más difícil e impensable desarrollar un nuevo código partiendo de cero. y se puede utilizar en muchas ocasiones.

Cáceres González Centro de Investigación y de Estudios Avanzados ..mx abdiel@mazatlan.cinvestav.cs.udo. 2004 .Contacto: acaceres@computacion. México.mx Abdiel E.IPN México D.F.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->