p.

1 de 14

Guía  de  ejemplos  

Semana  1  

Juego  de  dados  (Ejemplo  1).  

Hay 2 versiones del programa. Está la estructura inicial del programa y una segunda
versión que contiene la estructura completa del programa, pero sin implementar
totalmente la clase jugador y conjuntoJugadores.
Se explica cómo se da la dependencia entre dos clases: definiendo atributos del tipo de
una clase o métodos con una lista de parámetros del tipo de la clase. También puede
existir dependencia por el uso de una variable local. Los tres casos representan el uso
posible de variables en un programa. Se excluye el uso de variables globales, por inducir
problemas de opacidad referencial.

Práctica  1.  
Se propone terminar la arquitectura (diagrama de clases) del problema propuesto en
el primer ejemplo, para completar la implementación.

Semana  2  

Juego  de  dados  (Ejemplo  1).  

La versión inicial del programa define la estructura completa de la arquitectura, pero
no implementa las funciones principales del juego. La versión final sí implementa el juego
totalmente.
La versión 1.1 modifica el juego para mostrar cómo se puede generalizar el juego
utilizando un arreglo de jugadores en lugar de instancias individuales. El manejo del
arreglo se implementa directamente en la clase conjuntoJugadores. Se introduce el
concepto de asociación con multiplicidad mayor a uno. Se mencionan los conceptos de
agregación y composición (no se detallan aún).
Se utiliza una clase objetoBase que sirve como tipo general para implementar el
método toString(), que permite la conversión general de cualquier instancia a una
representación legible como una cadena de texto (ver ejemplo 3).

© 2010. Georges E. Alfaro S.

 p. 2 de 14

Semana  3  

Grupo  de  personas  (Ejemplo  2).  

El ejemplo 2 toma la forma de implementación del arreglo en el ejemplo de la semana
anterior y define una clase conjuntoPersonas para manejar una colección de personas.
El objetivo del ejemplo es mostrar la implementación para considerar cómo debería
hacerse una generalización que permita trabajar con colecciones más flexibles. El énfasis
de los ejemplos es en el uso de herencia (generalización y especialización) para
manejar colecciones. En ejemplos posteriores, cuando se profundice en el concepto de
asociación, se utilizará la herencia para especializar comportamiento o manejar
excepciones de diseño.
Hay dos variaciones del ejemplo 2 (que son extensiones de la versión anterior): una
utiliza herencia (generalización) partiendo del manejo del arreglo. Se crea una clase base
y se definen las operaciones necesarias en la clase base. La implementación de los
métodos se extrae de la subclase (clase derivada) hacia la superclase (clase base). Esto es
una operación de re
La otra versión utiliza delegación en lugar de herencia. Los métodos se implementan
en la clase general y la clase conjuntoPersonas delega la implementación. Esto obliga
a escribir la definición e implementar todos los métodos de la clase, pero permite
construir un método restringido (agregar) que solamente recibe parámetros de un tipo
específico, en lugar de un tipo más general, como en la implementación anterior. Esto se
hace así ya que de lo contrario no se respetaría el principio de sustituibilidad de
Liskov (programación por contrato) en la clase conjuntoPersonas. Si la clase
arreglo se mantiene específica no se puede reutilizar fácilmente. Si la clase arreglo se
hace general, podría permitir operaciones incorrectas en la implementación del programa.

© 2010. Georges E. Alfaro S.

 p. 3 de 14
Ejemplo  3.  
Muestra cómo la clase arreglo se puede utilizar creando una clase simple a partir
del objetoBase. El objetoBase funciona como la superclase Object de Java. Como
esta implementación no permite el uso de tipos simples, como en Java o C#, la clase
objetoBase se cambiará más delante por medio de una implementación de plantillas
(templates).
Es importante ver cómo al ser el mismo arreglo del tipo del objetoBase, puede
contener instancias del mismo tipo, permitiendo crear arreglos de arreglos o de otros tipos
diferentes. Esto facilita el uso de objetos polimórficos en una colección.
El uso del objetoBase permite definir también métodos genéricos que pueden ser
útiles en cualquier clase, como el método toString(). El uso del método toString()
para obtener una representación de una instancia en forma de una hilera está
implementado en otros lenguajes como Java o C#.

Semana  4  

Movimientos  a  una  cuenta  (Ejemplo  4).  

Este ejemplo usa una implementación por delegación para crear una clase cuenta con
un conjunto de movimientos asociados. El objetivo del ejercicio es mostrar cómo la
implementación por delegación permite la extensión de la clase a través de métodos
propios de la colección (conjuntoMovimientos).

Ejemplo  5.  
Este ejemplo muestra la relación entre una interfaz, una clase adaptadora
(abstracta) y dos implementaciones concretas.
Principios teóricos estudiados:
• Principio de Responsabilidad Única
• Patrón de delegación (Delegate)

Práctica  2.  
Se plantea un problema de mediana complejidad donde se utilicen las clases
implementadas en los ejemplos anteriores. Se debe crear una nueva clase (cliente) que
es una especialización de la clase persona, agregando un nuevo atributo (id) y una
asociación con la clase cuenta del ejemplo 4. Se crea una clase para encapsular el manejo
de los clientes en la aplicación, proveyendo métodos que serán llamados directamente
desde una clase de frontera (interfaz). Se menciona cómo el término interfaz es utilizado
con diferente significado en diferentes contextos: como el conjunto de métodos públicos
de una clase, como la declaración de un conjunto de métodos públicos que deben
implementarse en una clase derivada, como un estereotipo de clase (donde la clase sirve
de frontera entre la aplicación y el usuario u otros sistemas) y como una clase específica
para manejar las entradas del usuario y el despliegue de resultados.

© 2010. Georges E. Alfaro S.

 p. 4 de 14

Semana  5  

Práctica  3.  
Sirve de ejemplo para el manejo de la interfaz de usuario desde la consola (para que
los estudiantes completen la práctica anterior). Se define una clase de control que maneja
las opciones del usuario solicitadas a través de la interfaz. El ejemplo sirve para también
presentar el concepto de arquitectura de software y el modelo MVC.

Ejemplo  6.  
Es un ejemplo simple para mostrar los problemas asociados a la técnica de
encadenamiento de métodos: transitividad de las dependencias (Ley de Deméter o
del Conocimiento Mínimo) y exposición de la implementación. Los problemas se
resuelven fácilmente por delegación.
(Nota: se debería verificar el caso de la dependencia transitiva que no es visible en un
diagrama de clase)

Semana  6  

Ejemplo  7.  
Se utilizan las clases de la práctica 3 para mostrar cómo hacer una generalización de
la clase arreglo a un contenedor. Luego se muestra la implementación de una clase
concreta que implementa la interfaz del contenedor (lista), y se sustituye en la clase
conjuntoPersonas. Así se muestra como se puede sustituir una implementación por
otra si las dependencias son hacia interfaces o clases abstractas, en lugar de clases
concretas.

Ejemplo  8.  
Este ejemplo se utiliza para estudiar la implementación de la clase lista. Se agrega
un apuntador al final de la lista para facilitar el agregar elementos al final de la lista. Se
agregan métodos generales que pueden utilizarse para el manejo de colecciones, que
serán generalizados luego a la interfaz del contenedor e implementados también en el
arreglo.
Se sugiere que la lista podría utilizarse para implementar pilas y colas utilizando
delegación.
Se escribe un método para eliminar todos los elementos de la lista considerando una
implementación por agregación o por composición, purgando la memoria asignada a cada
elemento individual de la colección.
La implementación de los métodos que permiten insertar y eliminar un elemento en
una posición arbitraria se dejan como tarea, implementando solamente stubs de dichos
métodos.

Ejemplo  9.  (Diferencia  entre  agregación  y  composición)  

En este ejemplo se crea un conjunto de clases para mostrar la diferencia en la

© 2010. Georges E. Alfaro S.

 p. 5 de 14
implementación de las relaciones de agregación y composición por medio de un
contenedor general. En el código de la clase que contiene los agregados o componentes, se
señalan las diferencias en el método destructor de la clase y la forma de pasar parámetros
a los métodos que incluyen elementos.

Semana  8  

Experimento  1.  
Este ejemplo es para mostrar qué problemas pueden presentarse si se llama a un
método virtual en un constructor o en un destructor. En general, el polimorfismo NO
funciona en un constructor o un destructor, aunque trabaje correctamente en otro
contexto.

Ejemplo  10.  
Este ejemplo introduce el concepto del patrón Iterador, como una solución
generalizada (a través de una clase). La idea principal a mostrar es cómo el recorrido de
un contenedor puede implementarse utilizando una clase con métodos generales
(masElementos() y proximoElemento()) sin tener que exponer la implementación. En
el caso de la lista, se puede proveer la funcionalidad sin que el cliente de la clase requiera
conocer la clase Nodo, por ejemplo.

Práctica  4.  
Se propone construir un programa para modelar la siguiente situación: se tiene un
grupo de personas, cada una de las cuales tiene un nombre, dos apellidos y un género
(femenino o masculino). Las personas pueden tener un padre y una madre (de géneros
diferentes), que son a su vez personas. Además, cada persona puede tener un conjunto
(lista) de hijos de tamaño indeterminado.

© 2010. Georges E. Alfaro S.

 p. 6 de 14
Esto define una clase con tres (3) relaciones diferentes hacia sí misma, tal como se
muestra en el diagrama:

Observe que cada relación es efectivamente diferente (tiene un significado distinto) en

cada caso.
Hay que definir dos constructores para la clase Persona: uno que reciba los apellidos
de la persona como parámetro (string) y otro que reciba una referencia a la instancia
del padre y la madre (que son instancias de Persona). Cuando se reciban instancias de la
clase Persona como argumento, éstas se usarán para calcular el valor de los apellidos: el
primer apellido se toma del primer apellido del padre y el segundo apellido del primer
apellido de la madre. Si una persona tiene apellido materno pero no paterno, o cuando la
referencia a la instancia del padre sea nula, se asignará al primer apellido el apellido de
la madre, en ambos casos.
Hay que escribir además dos métodos: uno para calcular todos los antecesores de una
persona (los padres, abuelos, bisabuelos, etc.) y otro para calcular la lista de sucesores
(hijos, nietos, etc.), en cuyo caso se requiere recorrer el contenedor utilizado. Ambas
funciones regresan como resultado una lista de la clase Persona (o un contenedor).
El propósito del ejercicio es estudiar la implementación de las relaciones y el uso de
un contenedor (lista) para manejar un conjunto de agregados. Es importante observar que
no es posible que la relación entre una persona y sus hijos sea de composición sino de
agregación (con ciertas restricciones, impuestas por el hecho de que una persona
solamente puede tener dos padres de diferente género). También hay que construir un
contenedor general para todas las personas, para poder liberar la memoria asignada a las
instancias de manera correcta (se pide mostrar de qué manera son invocados los
destructores).

Ejemplo  11.  
Solamente se hacen varias declaraciones para verificar la sintaxis.

Biblioteca  de  contenedores  

Es la versión completa de la implementación de los contenedores básicos: uno por
medio de un arreglo (usando almacenamiento contiguo) y otro por medio de una lista
simple (usando almacenamiento enlazado).
© 2010. Georges E. Alfaro S.
 p. 7 de 14
Arreglo (Vector) Lista Tabla de dispersión Árbol (binario de
(hash table) búsqueda)
Implementación Arreglo asignado Lista simple (no implementado) (no implementado)
de manera enlazada con un
dinámica en el apuntador al
constructor de la primer y último
clase. elemento.
Tamaño Fijo determinado al Variable Variable Variable
instanciar la clase.
Organización No ordenado por No ordenado por Los elementos son Ordenado de
valor. Los valor. Los accesibles por acuerdo con alguna
elementos tiene elementos tiene medio de una llave. función de
una posición una posición La posición física comparación.
relativa. relativa. del elemento está
determinada por
una función de
dispersión (hash).
No hay ningún
orden determinado.
Recuperación Según la posición Secuencial. Permite Asociativa, por Asociativa, por
relativa del acceso relativo a medio del valor de medio del valor del
elemento. los elementos. la llave. elemento (puede
utilizarse una llave
en la función de
comparación).
Inclusión de En cualquier En cualquier Por medio de una Por medio del valor
elementos posición del posición del llave. No hay un del elemento. Los
contenedor. Por contendor. Por orden relativo elementos están
defecto, los defecto, los determinado. ordenados de
elementos se elementos se acuerdo con el
agregan al final del agregan al inicio valor de alguna
contenedor. del contenedor. función de
comparación.
Eliminación Cualquier posición Cualquier posición Cualquier posición Cualquier posición
(relativa). (relativa). de acuerdo con el de acuerdo con el
valor de la llave valor del elemento
(asociativa). (asociativa).
Búsquedas Secuencial. Secuencial. No se Directa. Dirigida por el
puede implementar valor. Eficiente en
de manera general. términos generales.
Comentarios sobre El tiempo de acceso El tiempo de acceso Los elementos no Si los elementos no
la implementación a cada elemento es a cada elemento se encuentran en se pueden ordenar
constante. La puede depender del ningún orden según algún
inserción y número total de particular. criterio, no es más
eliminación de elementos. eficiente que una
Facilita la búsqueda
elementos es lista enlazada.
El uso del espacio de elementos
ineficiente en
es muy eficiente. particulares. Facilita la búsqueda
general, para
de elementos
posiciones
particulares.
diferentes al inicio
o final del
contenedor.
El tamaño del
contenedor es fijo.

© 2010. Georges E. Alfaro S.

 p. 8 de 14
Semanas  9-­‐11  

Ejemplo  12.  
Muestra el funcionamiento del constructor de copia. El ejemplo muestra uno de los
problemas que existen al utilizar instancias de una clase en lugar de apuntadores
(referencias). Cuando se utiliza una instancia como argumento de una función, esto
fuerza la creación de una copia del objeto (parámetro por valor). Es preferible utilizar
un parámetro por referencia.

Ejemplo  13  (13b).  

Este ejemplo muestra la implementación básica de la regla de tres:
La regla de tres (en C++) establece que cuando una clase tiene al menos uno de los
tres: un destructor, una constructor de copia o la sobrecarga del operador de asignación,
deben existir los tres (todos). La razón de ello es que cualquiera implica la existencia de al
menos un atributo que se maneja por medio de un puntero. Esto hace necesario hacer
copias del objeto en profundidad (deep copy), y liberar la memoria correspondiente al
finalizar la instancia. Es importante notar que cuando se tiene una relación de
agregación, es correcto hacer una copia superficial (shallow copy). (Consultar la
presentación del ejemplo).
Se introduce el concepto de sobrecarga de operadores. Para ello, se utiliza el operador
de asignación y el operador de salida para flujos (<<), permitiendo la impresión directa de
instancias de la clase objetoBase.
Es usual implementar primero el destructor, luego el constructor de copia y por
último sobrecargar el operador de asignación, ya que este último reproduce la
funcionalidad de los dos primeros. Es importante observar que no es usual implementar
la funcionalidad común utilizando métodos, ya que no se utilizan métodos virtuales, pero
es perfectamente correcto. Hay que observar que aunque los destructores sí se declaran
como virtuales, los métodos invocados no lo son (en un constructor o destrcutor no debe
usarse métodos virtuales), por lo que debe tenerse especial cuidado de invocar los
métodos explícitamente y no depender del polimorfismo para ello. Como al utilizar los
métodos se usan los que corresponden a la declaración del objeto (tipo estático) en lugar
de los que están definidos para el tipo asignado (tipo dinámico), no es posible lograr que
solamente se ejecuten las versiones sobrecargadas.

Ejemplo  14.  
Muestra la forma de implementar una matriz (arreglo de dos dimensiones) de
apuntadores a objetos. Este ejemplo sirve de apoyo para la implementación del proyecto
asignado (juego de ajedrez).

Ejemplo  15  (15b)  

Es similar el ejemplo 13, haciendo énfasis en la estructura de control del operador de
asignación, que debe duplicar la funcionalidad del destructor y del constructor de copia.
Se llama la atención sobre la comprobación del puntero this para evitar asignaciones
sobre una misma instancia (x = x;). Cuando se hace una operación de este tipo, es

© 2010. Georges E. Alfaro S.

 p. 9 de 14
posible que el código del destructor libere memoria de un atributo que no se puede
recuperar luego, ya que pertenece a la misma instancia.
Se muestra también (15b) como el operador de asignación se puede utilizar solamente
con objetos existentes, pero no cuando se inicializa una instancia en la declaración. Si se
depende del operador de asignación para hacer una copia, esto obliga generalmente a que
exista un constructor por defecto para la clase. De no existir el constructor por defecto, es
necesario inicializar los valores de los atributos con valores que son especificados desde la
clase cliente, lo que no siempre tendría sentido.

Experimento  2  
Muestra el uso de una declaración por referencia, para poder tener dos variables
asociadas a la misma dirección de memoria. Es una característica de bajo nivel, propia de
C++.

Experimento  3  
Se utiliza el ejemplo (asociado al proyecto asignado) para mostrar cómo manejar el
caso de dos clases que dependen mutuamente.
Cuando ocurre una situación similar, una de las dos instancias debe crearse primero,
y luego se establecerá la dependencia al crear la segunda instancia. Generalmente la
primera instancia crea la segunda (lo que establece una relación de composición), la cual
recibe como argumento en el constructor la referencia del objeto principal por medio de
un apuntador this. (Ver el ejemplo 16)

Ejemplo  16.  
Muestra cómo se implementa la dependencia mutua entre dos clases.

Puntos importantes a resaltar:

• La clase deben declarase antes de definirse, porque de lo contrario no es posible
declarar los atributos (Esto es particular de C++).
• Los atributos se definen como apuntadores, ya que no es posible asignar la
memoria previamente al inicializar los objetos (Siempre debe crearse uno de los
objetos primero).
• Una de las clases (la clase componente o subordinada) generalmente recibe
como argumento una referencia a la clase contenedora (o principal) en un
método que establece la asociación entre los dos objetos.
• Como las definiciones de los constructores no están disponibles en la
© 2010. Georges E. Alfaro S.
 p. 10 de 14
declaración, éstos deben implementarse luego; generalmente en un archivo
fuente (.cpp), mientras que las declaraciones se colocan en un archivo de
cabecera (.h, .hpp).
• La relación entre las clases no necesariamente es una de composición, puede
ser una simple dependencia.

Ejemplo  17.  
Muestra la definición de dos clases en una jerarquía simple para ilustrar la diferencia
entre los conceptos de upcasting y downcasting. Se menciona el hecho de que el
upcasting es siempre seguro e implícito, pero asume que una subclase es un subtipo (lo
cual no es cierto siempre). El término casting (coerción) se refiere usualmente al concepto
de downcasting, que debe ser explícito. A menudo es inseguro, si no se puede determinar
el tipo dinámico de una variable.

Notas  sobre  agregación  y  composición.  

Cuando una clase es parte de una relación de agregación como componente, puede formar
parte de otra relación de agregación, pero no el caso de la composición. Los
componentes (partes) en una relación de composición no pueden ser
compartidos. Las relaciones de agregación y composición modelan una relación “tiene
un” entre el objeto agregado (compuesto) y sus elementos componentes.

Por lo anterior, la relación de composición entre las clases a1 y c2, en el diagrama

anterior, es una relación incorrecta, aunque sí podría existir una relación de agregación.

© 2010. Georges E. Alfaro S.

 p. 11 de 14

Esto implica también que la relación de composición solamente puede tener una
multiplicidad de 1 en el extremo del objeto compuesto, ya que un objeto componente
solamente puede serlo de un único compuesto, aunque también podría formar parte de
varios agregados.
Al copiar un objeto agregado, los componentes no se copian, en general.
Suponga, por ejemplo, que se tienen dos clases en una relación de agregación como se
muestra:

Por ejemplo, suponga que existe si se copia el objeto obj1 de la clase c1, la copia
mantiene la referencia al mismo atributo asociado de tipo a1

Sin embargo si la relación entre las clases es una de composición, el atributo asociado no
puede compartirse entre las dos instancias de la clase c1 (la original y la copia). Por lo
tanto, es necesario hacer una copia del atributo:

© 2010. Georges E. Alfaro S.

 p. 12 de 14

Resumiendo, a menudo se mencionan diversos criterios para identificar agregación

versus composición1:
• En una composición, los elementos (componentes) no pueden ser
compartidos. Esto puede observarse en el diagrama donde el extremo de la
asociación que corresponde al objeto compuesto no puede tener una multiplicidad
mayor a 1.
• En una composición, los elementos (componentes) no pueden serlo de dos clases
compuestas de manera simultánea (consecuencia de la afirmación anterior)
• La agregación se denomina algunas veces como asociación por referencia. La
composición se denomina como asociación por valor. Cuando se copia un
agregado, se copian las referencias a las partes, pero no las partes en sí. Cuando se
copia un compuesto, deben copiarse a sí mismo cada una de las partes
(componentes). (Referirse a la especificación de UML 2.0.)
• En una relación de composición, el tiempo de vida de un compuesto es el mismo
que el de sus partes2. Esta afirmación implica que, al utilizar C++, si se utilizan
atributos declarados del tipo de una clase directamente (sin utilizar apuntadores),
como éstos son asignados y desasignados de manera automática, solamente pueden
usarse para relaciones de composición, y nunca de agregación. Este problema no se
presenta en lenguajes de programación que manejan objetos siempre de forma

1 http://ootips.org/uml-hasa.html
http://www.c-sharpcorner.com/UploadFile/pcurnow/compagg07272007062838AM/compagg.aspx
http://wiki.answers.com/Q/Whats_the_difference_between_aggregation_and_composition
http://stackoverflow.com/questions/885937/difference-between-association-aggregation-and-composition

2 Es importante notar que por restricciones de la implementación, algunas veces debe crearse primero el
objeto compuesto y luego los componentes. Sin embargo, al destruir el objeto compuesto, los componentes
se destruyen primero, por lo que el tiempo de vida de los componentes no puede exceder en ningún caso
el del compuesto. Cuando se trata de un agregado, los objetos componentes pueden existir aunque se
haya eliminado el agregado, o éste haya salido de alcance. Algunas veces se usa como ejemplo de
agregación un objeto cuyas partes son “reutilizadas” en otro agregado (como en el ejemplo del avión que
es destruido y sus piezas son empleadas entonces para otro avión), pero éste es un ejemplo
INCORRECTO, ya que la relación es de composición estrictamente (las piezas no pueden serlo de dos
aviones de manera simultánea).

© 2010. Georges E. Alfaro S.

 p. 13 de 14
indirecta, como en Java o C#. En C++, si se usan apuntadores para manejar una
relación de composición, es importante recuperar la memoria asignada a los
componentes, lo que usualmente se hace en el destructor de la clase compuesta.
Existen situaciones donde una relación de agregación debe implementarse como una
composición, por limitaciones de representación (por ejemplo, el caso de los puntos de un
polígono) o de las operaciones que pueden definirse. El problema conceptual es que en
algunos casos los objetos se modifican (sus atributos cambian) mientras que en otros el
objeto es transformado o cambiado por otro. Por ejemplo, una variable entera no es
conceptualmente idéntica al valor que almacena. Cuando se cambia el valor de la
variable, realmente se trata de un objeto diferente, no del mismo con otro valor. Por
ejemplo, la edad puede ser el atributo de una persona, y tener diferentes valores en
momentos distintos. Pero cuando se cambian las coordenadas de un punto de un polígono,
no es que esté cambiando el valor de un atributo, sino que se está asignando un atributo
diferente (compare por ejemplo el concepto de identidad cuando dos variables distintas
contienen el mismo valor). Distinguir conceptualmente entre un atributo y el valor
asociado en un momento dado no es relevante en la mayoría de los casos.
Es importante mencionar que los últimos tres criterios son consecuencia
directa del primero, pero no al revés, por lo que no deben considerarse
lógicamente equivalentes.

Semana  12  

Ejemplo  18  
Este ejemplo construye una clase que encapsula un arreglo (una versión más simple
que la utilizada en general) usando plantillas (templates). Se llama la atención sobre el
problema de incluir la implementación de los métodos en un archivo fuente (.cpp). En su
lugar, todos los métodos (las plantillas de los métodos) deben incluirse en los archivos de
cabecera (.h).
Se estudian los conceptos de:
• Polimorfismo estático (plantillas)
• Sobrecarga de operadores
Se plantea la modificación de las clases que implementan contendores (arreglos y
listas) para que utilicen polimorfismo estático (plantillas) en lugar de polimorfismo
dinámico (herencia).
Se enuncia un principio importante de POO: en general, deberá preferirse la
delegación al uso de polimorfismo, y deberá preferirse el polimorfismo estático
(programación genérica o plantillas) al polimorfismo dinámico (herencia).

Ejemplo  19a,  19b  

Ejemplo sencillos de implementación de una función genérica (plantilla de función) y
una clase genérica (parametrizada).

Ejemplo  20  
Ejemplo básico de uso de excepciones.
© 2010. Georges E. Alfaro S.
 p. 14 de 14
Ejemplo  21  
Ejemplo de uso de una clase de excepción y de anidamiento de bloques try – catch.

Ejemplo  22  
Implementación de funciones de biblioteca para la conversión de texto a mayúsculas y
minúsculas (no es un ejemplo dentro de la secuencia del curso).

Ejemplo  23  
Muestra de los mecanismos de indirección disponibles en C++ (no es un ejemplo
dentro de la secuencia del curso).

Semana  14.  

Biblioteca  de  contenedores  

Se implementa la biblioteca de contenedores utilizando plantillas. El contenedor
(arreglo o lista) asume que el parámetro de la plantilla es un apuntador a un tipo que
puede mostrarse directamente en un flujo de salida.

© 2010. Georges E. Alfaro S.