Poo 01

463 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
463
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Poo 01

  1. 1. 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
  2. 2. 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.
  3. 3. 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.
  4. 4. 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.
  5. 5. Construcción de sistemas• 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.
  6. 6. 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, 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.
  7. 7. ¿Qué es construir un sistema? Sistema supermoderno con tecnología de estaciones detrabajo 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.
  8. 8. ¿Qué es construir un sistema? SolicitudDePermisoDeConducir FormularioParaSolicitudDeCredito Sistema supermoderno con tecnología de estaciones deMemorandum trabajo distribuídas y gráficas ... para gestionar formularios de oficina en generalCuponDeGastoDeViaje 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 FormularioParaAtestadosDeSeguros cantidades de papel, como compañías de seguros, bancos, gobierno.
  9. 9. ¿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.
  10. 10. ¿Qué es construir un sistema?el sistema le gustará a los clientes, porque ataca los costos de dificultad de manejo de papel 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 Elizabeth Aduenel mismo esquema Atraerá nuevos Ing Sistemas de una compañíapor mucho tiempo clientes recién fundada que desarrollan sistemas para hacer oficinas virtuales orientada a los clientes que usan grandes cantidades de papel, como El prototipo compañías de seguros, bancos, gobierno.
  11. 11. ¿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 Elizabeth Aduen iconos Ing Sistemas de una compañía • recién fundada que desarrollan La gestión automática de procedimientos sistemas para hacer oficinas virtuales orientada a los implica posiblemente técnicas de IA clientes que usan grandes cantidades de papel, como compañías de seguros, bancos, gobierno.
  12. 12. 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% Pagados sin ser suministrados Suministrados pero sin utilizarse 2% 47% Usado tal como se suministró Abandonado o reformado 29% 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.
  13. 13. La crisis del softwareDesencanto 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.
  14. 14. La crisis del softwareDesencanto de Bancarrota de los clientes 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.
  15. 15. La crisis del software DesgraciaDesencanto de Bancarrota de personal de los clientes la empresa 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.
  16. 16. La crisis del software Se exceden los presupuestos No se alcanzan losSíntomas objetivos en los Cancelación fatales plazos establecidos y desgracia Falta coltrol Baja calidad
  17. 17. La crisis del software¿Que es lo que hace que el sistema de Elizabeth sea tan ambicioso?
  18. 18. La crisis del software ¿Que es lo que hace que el sistema de Elizabeth sea tan ambicioso? El HW no es un problema, porqueque HW actual es capaz de admitir sistemas de este tipo, y más
  19. 19. La crisis del software ¿Que es lo que hace que el sistema de Elizabeth sea tan ambicioso? El HW no es un problema, porque a) Los sistemas distribuidos noque HW actual es capaz de admitir son nada nuevo sistemas de este tipo, y más 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
  20. 20. La crisis del software ¿Que es lo que hace que el sistema de Elizabeth sea tan ambicioso? El HW no es un problema, porque a) Los sistemas distribuidos noque HW actual es capaz de admitir son nada nuevo sistemas de este tipo, y más 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, y juntas pueden ocasionar problemas
  21. 21. El verdadero problema es que estesistema imlica una actitud hacia el cambio que no contemplan nuestras herramientas de programación, nuestras metodologías ni nuestros conceptos.
  22. 22. Nuestro enemigo: El cambioElizabeth, como Ing. Software es la responsable de definirel 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
  23. 23. Nuestro enemigo: El cambioElizabeth, como Ing. Software es la responsable de definirel 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
  24. 24. Nuestro enemigo: El cambioElizabeth, como Ing. Software es la responsable de definirel 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
  25. 25. Nuestro enemigo: El cambioElizabeth, como Ing. Software es la responsable de definirel 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 diseño
  26. 26. 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. • 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í
  27. 27. 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. probablemente, 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, y su principal • responsabilidad consistiría en Definir qué componentes de software van en cada evitar el peligro estadísticamente sitio probable. • Seleccionar una estrategia de redes para interconectar estas piezas entre sí
  28. 28. Nuestro enemigo: El cambio• 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.
  29. 29. Nuestro enemigo: El cambioEn un safari, es lógico matar mosquitos, porque la malaria es un problema real e importante.
  30. 30. Nuestro enemigo: El cambioEn 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.
  31. 31. Nuestro enemigo: El cambio Elizabeth se enfrenta a un ataque mediante el cambio, que es el mayor oponente y más peligroso al que puedaenfrentarse cualquier proyecto de software, y sus primerosesfuerzos deberían ir encaminados a defender este proyecto contra la destrucción a manos del cambio.
  32. 32. Nuestro enemigo: El cambio ¿“del cambio” dijeron?Sí, pero de ese “cambio” no estamos hablando
  33. 33. La línea de defensa Manigot La estrategia convencional para enfrentarse al cambioconsiste en construir elaboradas estructuras defensivas paraevitar 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).
  34. 34. La línea de defensa ManigotEste sistema debe su nombre a André Maginot, quien fue su promotor, un veteranomutilado durante la Primera Guerra Mundial y murio en 1932 sin ver terminada laobra.La parte esencial de los trabajos se termino en 1936, en momentos en que laamenaza Hitleriana parecia darle toda la justificacion a este proyecto: es lamayor línea de defensa militar construida en el mundo, siendo de una grancomplejidad tecnológica y militar. Su costo total fue 5 Millardos de FF (de laepoca). La línea Maginot compretde 108 fuertes principales a 15 km de distanciaentre si, mutitud se pequeños fuertes y mas de 100 km de galerias.Error de estrategiaLa línea no evita la derrota de Francia al comienzo de la Segunda Guerra Mundialen 1940, por el contrario, en las diviciones alemanas la rodean y atacan en laregion de Sedan, en su extremidad occidental, los ejercito aliados fueroncortados en dos.
  35. 35. La línea de defensa Manigot 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 sediscuten con el cliente, que en última instancia las aprueba y las firma, antes de realizar ningún trabajo adicional.
  36. 36. La línea de defensa ManigotUna 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.
  37. 37. La línea de defensa Manigot Por supuesto, el trabajo debe ser planeado cuidadosamente. Si suponemos esto, el cliente tiene que estar satisfecho con elresultado, 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
  38. 38. La línea de defensa Manigot¿Cuál es la solución?
  39. 39. La línea de defensa Manigot¿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.
  40. 40. 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 oxidaEl SW no necesita ser desempolvado, encerado o limpiado.Pero sí tiene fallos, que necesitan nuestra atención, aunqueesto NO SEA MANTENIMIENTO, sino REPARACION. La reparación esarreglar algo que se ha roto por jugar con ello, o algo quesiempre ha estado roto. Por otra parte, a medida que elentorno que circunda al SW va cambiando, es preciso invertirenergía para que esté al día. Esto no es mantenimiento, noes mantenerse firmes para evitar la caída. La evoluciónconsiste en cambiar para avanzar.
  41. 41. La línea de defensa ManigotEs posible que Elizabeth debieraignorar el mantenimiento como algoturbio y poco importante, pero nopuede ignorar las reparaciones, y,ciertamente, no puede olvidar laevolución. Su ventaja frente a lacompetencia depende de su capacidadpara hacer que el productoevolucione, satisfaciendo lasnecesidades de sus clientes. Pero,¿qué es exactamente lo que deberíahacer?
  42. 42. La línea de defensa ManigotPodría asegurarse de que el código tuviera muchos comentarios
  43. 43. La línea de defensa ManigotPodría asegurarse de que el código tuviera muchos comentarios Que el lenguaje deprogramación sea legible (lo que sea que signifique)
  44. 44. La línea de defensa ManigotPodría asegurarse de que el código tuviera muchos comentarios Que el lenguaje deprogramación sea legible (lo que sea que signifique)Prohibir los goto (si es que eso soluciona algo)
  45. 45. La línea de defensa ManigotPodría asegurarse de que el código tuviera muchos comentarios Que el lenguaje deprogramación sea legible (lo que sea que signifique)Prohibir los goto (si es que eso soluciona algo)Escribir mucha documentación interna
  46. 46. La línea de defensa Manigot Podría asegurarse de que el código tuviera muchos comentarios Que el lenguaje deprogramación sea legible (lo que sea que signifique)Prohibir los goto (si es que eso soluciona algo)Escribir mucha documentación internaIntentar que estuviese al día con respecto al código que cambia contínuamente
  47. 47. 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ínuamentePero, ¿afectaría realmente hacer todas estas cosas a la viabilidad técnica de este sistema?
  48. 48. La línea de defensa Manigot 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.
  49. 49. La línea de defensa ManigotLa 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 proyectosiguiente, 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. cambiossistemas de software
  50. 50. La defensa SuizaEl plan de negocios de laempresa de Elizabeth equivale arechazar explícitamente ladefensa de la Línea Manigot.Tienen la intención deconstruir un producto comoprototipo, y lo utilizarán paraatraer clientes, que seránquienes les paguen para cambiarsu prototipo de modo queresuelva sus necesidades. Laempresa de Elizabeth no puedeproscribir el cambio, nidespachárselo a un grupo demantenimiento. Su plan requiereuna visión radicalmentedistinta acerca del proceso dedesarrollo de softwareñ setrata de una visión que tratael cambio como parte vital einteligente del proceso globalde desarrollo de software.
  51. 51. La defensa SuizaLa empresa de Elizabeth podría estarplaneando utilizar algo parecido a laestrategia de defensa Suiza, contemporáneade la Línea Maginot. en lugar de invertiren una costosa (y a juzgar por susvecinos, poco fiable) defensa de susfronteras, Suiza se declaró país abierto,y daba la bienvenida a los visitantes decualquier país, raza o religión. Estapolítica les permitió capear el temporal,cuyas consecuencias estremecieron almundo, de la Segunda Guerra Mundial, y almismo tiempo obtuvieron unos beneficiosbastante decentes de todos los implicados,sin más que adaptarse a los sucesos conagilidad.
  52. 52. 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 esposible 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.
  53. 53. La defensa Suiza ¡Advertencia!En este curso no vamos a promover la línea de defensa Suizacomo manera de construir sistemas grandes. Aunque losconceptos de objetos, mensajes, clases y herencia ofrecen ungran potencial para construir sistemas grandes y maleables;hay varias razones por las cuales otras partes de lafilosofía de Smalltalk-80 son, casi con certeza, inadecuadaspara 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, puestoque invierte potencia de cálculo cuantiosamente para ofrecercapacidades de productividad como la recolección automáticade basura, una interfaz de usuario muy gráfica y un entornouniforme basado en objetos.
  54. 54. La defensa Suiza ¡Advertencia!El control es una razón aún más fundamental. El sistema de lacompañía de Elizabeth implicará a un gran número deprogramadores, que deben trabajar en grupo como unaorganización coordinada, si es que un sistema de semejantecomplejidad ha de llegar a ser suministrado algún día. Laposibilidad de que cualquier programador pueda cambiar lo quese le antoje no es beneficioso para este tipo de trabajo,aunque este problema potencial podría tratarse a través delpotente conjunto de herramientas que ofrece Smalltalk paragestionar los cambios.
  55. 55. La defensa Suiza ¡Advertencia!La compatibilidad es la razón más fundamental, y es casiimposible de superar. Casi todas las organizaciones modernastienen al menos algún tipo de inversión previa en software,desarrollado en lenguajes anteriores, y los clientesinsistirán en que el software anterior siga siendo viable.Salvo que se ofrezca un hardware independiente para estasaplicaciones no parece que haya forma de evitar lacircunstancia consistente en que Smalltalk-80 necesita unentorno completo e independiente en sí mismo.
  56. 56. La defensa híbridaLa defensa híbrida es parecida a la que preferiría un militarexperto en combate, combinando todas las posibles estrategiasen una combinación activa.Se utilizan parapetos defensivos para defender las estructurasimportantes contra ataques frontalesSe emplean unidades dispersas, formadas por ordenes o mandatos,para proporcionar un conocimiento del terreno.Se hace uso de la maniobrabilidad para evitar ataques, si esposible.Y se echa mano de la diplomacia y demás tácticas pacíficas paraevitar los disparos, desde el primer momento.
  57. 57. La defensa híbridaEl dogma convencional de la ingeniería de software consiste enconstruir: sistemas de software eficientes (pero frágiles)
  58. 58. La defensa híbridaEl dogma convencional de la ingeniería de software consiste enconstruir: estructuras estáticas de defensa que los protegen de los cambios estructuras estáticas de estructuras estáticas de defensa que los protegen defensa que los protegen de los cambios de los cambios sistemas de software eficientesrodeados por (pero frágiles) estructuras estáticas de estructuras estáticas de defensa que los protegen defensa que los protegen de los cambios de los cambios
  59. 59. La defensa híbridaEl valor de esto no se puede negar, puesto que el cambioincontrolado (”hacking”, parchar el sistema) no es manera deconstruir complejos sistemas de software. Pero aún se puedehacer 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)
  60. 60. La defensa híbridaEl valor de esto no se puede negar, puesto que el cambioincontrolado (”hacking”, parchar el sistema) no es manera deconstruir complejos sistemas de software. Pero aún se puedehacer 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) 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
  61. 61. La defensa híbridaEl valor de esto no se puede negar, puesto que el cambioincontrolado (”hacking”, parchar el sistema) no es manera deconstruir complejos sistemas de software. Pero aún se puedehacer 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) 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.
  62. 62. Programación orientada a objetos • La encapsulación es el fundamento de todo este enfoque. Su contribución No intentaremos dar una consiste en restringir los solución que vaya a eliminar efectos del cambio,por arte de magia problemas de situando un muro de códigoesta magnitud. Pero sí vamos a en torno a cada dato. Todo proponer varios conceptos y el acceso a los datos está herramientas, que pueden gestionado mediante ayudarnos a producir un procedimientos, que se han software que sea mucho más puesto allí para hacer de tolerante con respecto al mediadores en el acceso a cambio: los datos. Olvidarse del “cómo hacer” y ahora especificar el “qué hacer”.
  63. 63. Programación orientada a objetos • La herencia es la parte más innovadora del enfoque. Se trata de una herramienta para retransmitir automáticamente el código a No intentaremos dar una clases desarrolladas por solución que vaya a eliminar distintos miembros de unpor arte de magia problemas de equipo. Los programadoresesta magnitud. Pero sí vamos a ya no empiezan cada módulo proponer varios conceptos y con una pagina en blanco, herramientas, que pueden sino que, escriben una sola ayudarnos a producir un sentencia que se refiere a software que sea mucho más una clase que ya esta en la tolerante con respecto al biblioteca. Cada una de las cambio: sentencias subsiguientes describe la forma en que la nueva clase se diferencia de la que está en la biblioteca.
  64. 64. Programación orientada a objetos Para ver cómo estas técnicas se aplican al problema de Elizabeth, examinemos de manera más detallada lasposibilidades 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:
  65. 65. Programación orientada a objetos Para ver cómo estas técnicas se aplican al problema de Elizabeth, examinemos de manera más detallada lasposibilidades del sistema prototipo, y la forma en que deben cambiar al transcurrir el tiempo. Escritorio Carpetas Buzones Sobres Memos NotaMientrasEstabasFuera El sistema inicial admitirá un cierto número de objetos genéricos de oficina:
  66. 66. Programación orientada a objetos Para ver cómo estas técnicas se aplican al problema de Elizabeth, examinemos de manera más detallada lasposibilidades del sistema prototipo, y la forma en que deben cambiar al transcurrir el tiempo. 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. Por ejemplo, debe mostrar que estos objetos de oficina pueden emular la formaen 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.
  67. 67. Programación orientada a objetosLos escritorios, sobres, buzones y carpetas son coleccionesdé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 serrediseñado y recompilado cada vez que se agregue un nuevoobjeto electrónico, puesto que el usuario toma esta decisionen el momento de ejecución. Mas aún, el repertorio deobjetos que debe contener el escritorio irá cambiando con eltiempo, a medida que el sistema se extienda con nuevos tiposde formularios de oficina. Sin embargo, debe existir un cierto grado de acoplamiento, puesto que un escritorio electrónico necesita relacionarse con su contenido.
  68. 68. Programación orientada a objetosEjemplo: Muestra un menú conel contenido actual y Buzón ayuda al usuario a seleccionar el muestraContenido: siguiente objeto que debe leer detalladamente.
  69. 69. Programación orientada a objetosEjemplo: Muestra un menú conel contenido actual y Buzón ayuda al usuario a seleccionar el muestraContenido: siguiente objeto que debe leer 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.
  70. 70. Programación orientada a objetosEjemplo: Memorando Sobre muestraResumenMemorando: muestraResumenSobre: Muestra un menú conel contenido actual y Buzón ayuda al usuario a seleccionar el muestraContenido: siguiente objeto que debe leer detalladamente. 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, y esto equivale a una operación que el buzón debe aplicar a su contenido.
  71. 71. Programación orientada a objetosEsta clase de problema no es fácil de resolver con los lenguajesde programación convencionales, porque la programaciónconvencional hace que el consumidor de un operando searesponsable de seleccionar el operador apropiado para el tipo deoperando en cuestión. En este caso, el desarrollador del buzónes el consumidor de los objetos que hay que enviar por correo.Para obtener una información resumida de estos objetoscorrectamente, debe seleccionar operadores (funciones) queextraigan de alguna manera la información necesaria de losdistintos objetos.La solución habitual consiste en almacenar el tipo dentro decada objeto en un lugar estándar, de este modo:struct item { int codigoTipo; ...}Y comprobar después el tipo mediante una sentencia switch.
  72. 72. Programación orientada a objetosBasándose en el tipo de objeto, el buzón puede llamar a lafunció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 intentarconstruir un sistema así.
  73. 73. Programación orientada a objetosEl código del buzón depende ahora explícitamente de los tipos deelementos que eran conocidos cuando se escribió el buzón. 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 explícitamente que estebuzón no funcionará para contenidos que no seanMEMORANDO, CARPETA, NOTAMIENTRASESTABASFUERA y SOBRE
  74. 74. Programación orientada a objetosEl código del buzón depende ahora explícitamente de los tipos deelementos que eran conocidos cuando se escribió el buzón. 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 explícitamente que estebuzón no funcionará para contenidos que no seanMEMORANDO, 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.
  75. 75. Programación orientada a objetos Aún más, estas sentencias switch no están localizadas enninguna manera. Reflejan la responsabilidad del consumidor enlo 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 alproveedor del objeto, en lugar de asignársele al consumidor: mostrarResumenDe(objetoSiguiente) struct objeto *objetoSiguiente; { [objetoSiguente mostrarResumen]; ... }
  76. 76. Programación orientada a objetos Esto ordena al objeto llamadoobjetoSiguiente que lleve a cabo la orden denominada mostrarResumen. mostrarResumenDe(objetoSiguiente) struct objeto *objetoSiguiente; { [objetoSiguente mostrarResumen]; ... }
  77. 77. Programación orientada a objetos El consumidor no sabe, ni le importa, la forma en que objetoSiguiente lleva a cabo mostrarResumen, porque ésto es responsabilidad del que suministra Esto ordena al objetoSiguiente. Aunque distintas clases de objetos, objeto llamado como carpetas, memorandos, y sobres puedenobjetoSiguiente que mostrarResumen de formas muy diferentes, el código del lleve a cabo la consumidor no necesita preocuparse. Cuando se extiende el sistema con un nuevo tipo de objeto, el cambio no orden denominada se extiende más allá del código que haya sido escrito mostrarResumen. 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. mostrarResumenDe(objetoSiguiente) struct objeto *objetoSiguiente; { [objetoSiguente mostrarResumen]; ... }
  78. 78. Programación orientada a objetos 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 primeravista, 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.
  79. 79. Programación orientada a objetosLa herencia permite que sus similitudes estén descritas en un lugar central (una clase Contenedor) y que seanretransmitidas a todas las clases que se comporten como contenedores. Contenedor característica_A: Escritorio Carpeta Sobre
  80. 80. Programación orientada a objetosLa herencia permite que sus similitudes estén descritas en un lugar central (una clase Contenedor) y que seanretransmitidas a todas las clases que se comporten como contenedores. Contenedor característica_A: Escritorio Carpeta Sobre característica_A: característica_A: característica_A:
  81. 81. Programación orientada a objetos El desarrollador de escritorios no necesita construir estas propiedades comunes. En lugar de hacer esto,describe la forma en que los escritorios difieren de loscontenedores 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 puedeutilizar 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ássencillo heredar unas capacidades portentes y probadas a partir de una biblioteca de trabajo anterior.
  82. 82. Contacto:acaceres@computacion.cs.cinvestav.mx abdiel@mazatlan.udo.mx Abdiel E. Cáceres GonzálezCentro de Investigación y de Estudios Avanzados - IPN México D.F., México. 2004

×