Este documento describe la programación orientada a objetos. Explica que antes los programadores construían programas únicos a partir de lenguajes de programación, mientras que ahora producen componentes de software reutilizables ensamblando componentes de otros programadores, llamados SW-IC. También compara esta innovación con la introducción de piezas intercambiables en la industria de armas, revolucionando su construcción de sistemas.

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

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. 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. 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. 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. 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. ¿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, como
compañías de seguros, bancos,
gobierno.

8. ¿Qué es construir un sistema?
SolicitudDePermisoDeConducir FormularioParaSolicitudDeCredito
Sistema supermoderno con
tecnología de estaciones de
Memorandum 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
FormularioParaAtestadosDeSeguros cantidades de papel, como
compañías de seguros, bancos,
gobierno.

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. ¿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 Aduen
el mismo esquema Atraerá nuevos Ing Sistemas de una compañía
por 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. ¿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. 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. 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.

14. La crisis del software
Desencanto 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. La crisis del software
Desgracia
Desencanto 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. La crisis del software
Se exceden los
presupuestos
No se alcanzan los
Síntomas objetivos en los Cancelación
fatales plazos establecidos y desgracia
Falta coltrol
Baja calidad

17. La crisis del software
¿Que es lo que hace que el sistema de
Elizabeth sea tan ambicioso?

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

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 no
que 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. 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 no
que 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. El verdadero problema es que este
sistema imlica una actitud hacia el
cambio que no contemplan nuestras
herramientas de programación,
nuestras metodologías ni nuestros
conceptos.

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

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

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

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

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. 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. 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. Nuestro enemigo: El cambio
En un safari, es lógico matar
mosquitos, porque la malaria
es un problema real e
importante.

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

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 pueda
enfrentarse cualquier proyecto de software, y sus primeros
esfuerzos deberían ir encaminados a defender este proyecto
contra la destrucción a manos del cambio.

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

33. La línea de defensa Manigot
La estrategia convencional para enfrentarse al cambio
consiste en construir elaboradas estructuras defensivas para
evitar el cambio en cualquiera de sus formas, como la famosa
línea de defensa Manigot.
La Línea Maginot fue una línea de fortificacion y
defensa contruida por Francia a lo largo de su
frontera con [Alemania] e Italia, despues del fin de
la Primera Guerra Mundial. (el termino línea Maginot
se refiere al sistema entero o en ocaciones
unicamente se usa para referirse a las defensas
contra Alemania. Las defensas contra Italia suelen
llamarse tambien Línea Alpina).

34. La línea de defensa Manigot
Este sistema debe su nombre a André Maginot, quien fue su promotor, un veterano
mutilado durante la Primera Guerra Mundial y murio en 1932 sin ver terminada la
obra.
La parte esencial de los trabajos se termino en 1936, en momentos en que la
amenaza Hitleriana parecia darle toda la justificacion a este proyecto: es la
mayor línea de defensa militar construida en el mundo, siendo de una gran
complejidad tecnológica y militar. Su costo total fue 5 Millardos de FF (de la
epoca). La línea Maginot compretde 108 fuertes principales a 15 km de distancia
entre si, mutitud se pequeños fuertes y mas de 100 km de galerias.
Error de estrategia
La línea no evita la derrota de Francia al comienzo de la Segunda Guerra Mundial
en 1940, por el contrario, en las diviciones alemanas la rodean y atacan en la
region de Sedan, en su extremidad occidental, los ejercito aliados fueron
cortados en dos.

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 se
discuten con el cliente, que en última instancia las aprueba y
las firma, antes de realizar ningún trabajo adicional.

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

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 el
resultado, puesto que el sistema suministrado será precisamente
el sistema que él dio por bueno originalmente.
¿Cambiar los requisitos? ¡Ridículo! ¡Mire estos documentos, que
tienen su firma abajo!¡Será necesario rehacer el diseño!¡Todo
el planteamiento se vendrá abajo!¡Tendrá un costo adicional!
Desarrolladores de Software Clientes

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

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

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

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

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

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

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

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

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ínuamente
Pero, ¿afectaría realmente hacer todas estas cosas a la viabilidad técnica de este sistema?

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. La línea de defensa Manigot
La mentalidad de la Línea Maginot gestiona el cambio a base de
intentar impedir que se produzca. Cuando esto no tiene éxito
(y siempre acaba por fallar, tarde o temprano), la tarea de
reparar los daños se les para a los de la trastienda, al
equipo de mantenimiento. El resto del equipo pasa al proyecto
siguiente, mientras todo el mundo intenta ignorar los clamores
cuando el equipo de mantenimiento lucha para evitar que una
horda hambrienta de cambios devore a estos frágiles y casi
inmutables sistemas de software.
cambios
sistemas de software

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

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

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 es
posible deformar en casi cualquier sentido. Todo el sistema,
incluso bajando a nivel de hardware, está descompuesto en
objetos blindados, que se comunican enviando mensajes. No
hay un sistema operativo protegido (y por lo tanto
inmutable). El código fuente de todo el sistema está
disponible de forma inmediata para cualquier programador, y
todo el entorno de programación de ese programador se puede
modificar inmediatamente en casi cualquier aspecto, sin más
que modificar unas pocas líneas de código.

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

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

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

56. La defensa híbrida
La defensa híbrida es parecida a la que preferiría un militar
experto en combate, combinando todas las posibles estrategias
en una combinación activa.
Se utilizan parapetos defensivos para defender las estructuras
importantes contra ataques frontales
Se emplean unidades dispersas, formadas por ordenes o mandatos,
para proporcionar un conocimiento del terreno.
Se hace uso de la maniobrabilidad para evitar ataques, si es
posible.
Y se echa mano de la diplomacia y demás tácticas pacíficas para
evitar los disparos, desde el primer momento.

57. La defensa híbrida
El dogma convencional de la ingeniería de software consiste en
construir:
sistemas de software
eficientes
(pero frágiles)

58. 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 estructuras estáticas de
defensa que los protegen defensa que los protegen
de los cambios de los cambios
sistemas de software
eficientes
rodeados 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. La defensa híbrida
El valor de esto no se puede negar, puesto que el cambio
incontrolado (”hacking”, parchar el sistema) no es manera de
construir complejos sistemas de software. Pero aún se puede
hacer más:
Es posible hacer que los sistemas que sean maleables permitiendo
que haya una cierta elasticidad en la ejecución. Esto implica
suavizar la exigencia habitual de que todo se haga en el momento
de la compilación (dynamic binding)

60. La defensa híbrida
El valor de esto no se puede negar, puesto que el cambio
incontrolado (”hacking”, parchar el sistema) no es manera de
construir complejos sistemas de software. Pero aún se puede
hacer más:
Es posible hacer que los sistemas que sean maleables permitiendo
que haya una cierta elasticidad en la ejecución. Esto implica
suavizar la exigencia habitual de que todo se haga en el momento
de la compilación (dynamic binding)
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. La defensa híbrida
El valor de esto no se puede negar, puesto que el cambio
incontrolado (”hacking”, parchar el sistema) no es manera de
construir complejos sistemas de software. Pero aún se puede
hacer más:
Es posible hacer que los sistemas que sean maleables permitiendo
que haya una cierta elasticidad en la ejecución. Esto implica
suavizar la exigencia habitual de que todo se haga en el momento
de la compilación (dynamic binding)
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. 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ódigo
esta 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. 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 un
por arte de magia problemas de
equipo. Los programadores
esta 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. 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.
El sistema inicial admitirá un cierto
número de objetos genéricos de oficina:

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 las
posibilidades 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. 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.
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 forma
en que se comportan los objetos de oficina más familiares, y
que el sistema se puede extender con nuevos objetos de
oficina en un momento posterior.

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

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

69. Programación orientada a objetos
Ejemplo:
Muestra un menú con
el 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. Programación orientada a objetos
Ejemplo: Memorando Sobre
muestraResumenMemorando: muestraResumenSobre:
Muestra un menú con
el 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. Programación orientada a objetos
Esta clase de problema no es fácil de resolver con los lenguajes
de programación convencionales, porque la programación
convencional hace que el consumidor de un operando sea
responsable de seleccionar el operador apropiado para el tipo de
operando en cuestión. En este caso, el desarrollador del buzón
es el consumidor de los objetos que hay que enviar por correo.
Para obtener una información resumida de estos objetos
correctamente, debe seleccionar operadores (funciones) que
extraigan de alguna manera la información necesaria de los
distintos objetos.
La solución habitual consiste en almacenar el tipo dentro de
cada objeto en un lugar estándar, de este modo:
struct item { int codigoTipo; ...}
Y comprobar después el tipo mediante una sentencia switch.

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

73. 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.
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 este
buzón no funcionará para contenidos que no sean
MEMORANDO, CARPETA, NOTAMIENTRASESTABASFUERA y SOBRE

74. 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.
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 este
buzón no funcionará para contenidos que no sean
MEMORANDO, CARPETA, NOTAMIENTRASESTABASFUERA y SOBRE
Cada vez que se agrega un nuevo tipo de dato a este sistema,
el código del buzón debe ser cambiado y recopilado.

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

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

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 pueden
objetoSiguiente 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. 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 primera
vista, tipos distintos de objetos. Sin embargo, la verdad
es que tienen muchas cosas en común, puesto que se trata
solamente de diferentes clases de contenedores.

79. 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 Carpeta Sobre

80. 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 Carpeta Sobre
característica_A: característica_A: característica_A:

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 los
contenedores estándar. Los sobres, carpetas y buzones se
describen de la misma manera. Dado que la funcionalidad
genérica se puede desarrollar una vez, y se puede
utilizar en muchas ocasiones, la herencia proporciona un
fuerte incremento de productividad.
Resulta más difícil e impensable desarrollar un nuevo
código partiendo de cero, porque es casi siempre más
sencillo heredar unas capacidades portentes y probadas
a partir de una biblioteca de trabajo anterior.

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