Guia Trabajos Practicos - Departamento de Computación ...

Programación Orientada a Objetos 

Guía de Trabajos Prácticos 

Departamento de Computación 

Facultad de Ciencias Exactas 

Universidad de Buenos Aires

Índice 

La materia................................................................................................................................................4 

Criterios de aprobación...................................................................................................................................4 

Materiales.........................................................................................................................................................4 

Prioridades.......................................................................................................................................................4 

Normas de entrega de ejercicios y trabajos prácticos.............................................................................5 

Términos generales..........................................................................................................................................5 

Código...............................................................................................................................................................5 

Informes............................................................................................................................................................5 

Pharo.................................................................................................................................................................5 

Notación y Ejemplos de Modelado..........................................................................................................6 

Notación gráfica para diagramas....................................................................................................................6 

Notación Sintáctica General...........................................................................................................................6 

Diagrama de Instancias (o de Objetos)...........................................................................................................6 

Diagrama de Secuencia (o de Colaboración)..................................................................................................7 

Diagrama de Clases........................................................................................................................................9 

Pare, Atención, Modele .................................................................................................................................10 

Enunciado.....................................................................................................................................................10 

Resolución del punto 1.................................................................................................................................10 

Resolución del punto 2.................................................................................................................................14 

Práctica 1 - Smalltalk ............................................................................................................................15 

Conociendo Smalltalk....................................................................................................................................15 

Normas de codificación Smalltalk.................................................................................................................15 

Errores comunes con Smalltalk....................................................................................................................16 

#add: retorna su argumento..........................................................................................................................16 

Cambiar la colección mientras se itera sobre la misma.................................................................................17 

Olvido de ^...................................................................................................................................................17 

Métodos de creación de instancia.................................................................................................................17 

Redefiniendo #= y #hash..............................................................................................................................19 

Usando True o False en lugar de true o false................................................................................................19 

Referencias......................................................................................................................................................19 

Práctica 2 - Smalltalk Avanzado...........................................................................................................19 

Blocks y Contexts...........................................................................................................................................19 

Práctica 3 – Teoría de Objetos...............................................................................................................21 

Objeto y Clase.................................................................................................................................................21 

Mensajes-Métodos vs. Rutinas......................................................................................................................21 

self y super......................................................................................................................................................21 

Índice guia 2011.doc Página 2

Method Lookup.............................................................................................................................................22 

Clases / Métodos Abstractos / Concretos.....................................................................................................23 

Objetos mutables vs. Inmutables..................................................................................................................23 

Programa de la materia.........................................................................................................................24 

Bibliografía............................................................................................................................................25 

Básica...........................................................................................................................................................25 

De Referencia...............................................................................................................................................25 

Artículos (provistos por la cátedra).......................................................................................................25 

Herramientas..........................................................................................................................................25 

Fuentes adicionales de información.....................................................................................................26 

Objetos............................................................................................................................................................26 

Grupos y Listas de Smalltalk........................................................................................................................26 

Smalltalks.......................................................................................................................................................26 

SELF...............................................................................................................................................................26 

NORMAS BÁSICAS DE SEGURIDAD...............................................................................................27 

Departamento de Computación....................................................................................................................27 


Programación Orientada a Objetos Facultad de Ciencias Exactas - UBA 

La materia 

“Success is often achieved by those who don't know that failure is inevitable” – Coco Chanel 

“Start by doing what's necessary, then what's possible and suddenly you are doing the impossible” – Saint 

Francis of Assisi 

Criterios de aprobación 

La aprobación de la materia incluye los siguientes hitos: 

• Criterios de aprobación 

• Entrega de Ejercicios: 20 % de la nota 

• Parcial Teórico: 40 % de la nota 

• Parcial Prácitco: 40 % de la nota 

Materiales 

La materia comprende las siguientes fuentes de información, comunicación y ejercicios: 

• Guía de trabajos prácticos 

• Bibliografía, compuesta por libros, papers y artículos 

• Página web de la materia: www.dc.uba.ar/people/materias/poo 

• Lista de e-mail: www.yahoogroups.com/group/poo-uba 

• Lista de e-mail de docentes: www.yahoogroups.com/group/doc-objetos-uba 

Prioridades 

De todos los aspectos que conforman el software, los que nos interesa priorizar en la materia son los 

relacionados con la abstracción y el saber modelar. En este marco, consideraremos secundarios, aunque no 

indiferentes, los criterios relacionados con performance y formalidad. 

Integrantes: 

Máximo Prieto (Jefe de Cátedra): mprieto@dc.uba.ar 

Hernán Wilkinson (JTP): hernan.wilkinson@gmail.com 

Emilio Oca (Ayudante de 1ra) emiliooca@gmail.com 

Y además: 

Lista de docentes: doc-objetos-uba@yahoogroups.com 

Todos (alumnos y docentes): poo-uba@yahoogroups.com 

Páginas web de la materia: www.yahoogroups.com/group/poo-uba 

www.dc.uba.ar/people/materias/poo/homepage.html 

Normas de entrega de ejercicios y TPs guia 2011.doc Página 4


Normas de entrega de ejercicios y trabajos prácticos 

“The one important thing I have learned over the years is the difference between taking one's work seriously 

and taking one's self seriously. The first is imperative, and the second is disastrous” – Margaret Fontey 

Términos generales 

• Cumplir con las fechas. 

• Se debe entregar informe usando el formato de entrega de la materia, con diagramas relevantes que 

expliquen el modelo, código impreso. Las hojas deben estar abrochadas 

• Se debe mandar por mail a la lista de docentes el informe y el código fuente en formato electrónico 

Código 

• Debe funcionar en Pharo 

• Incluir todos los paquetes Monticello necesarios para cargarlo y correrlo 

• Incluir un archivo Leanme.txt con lo que sea necesario aclarar. Incluyendo el orden de carga de los 

paquetes, si lo hay. 

• Debe seguir las normas de codificación de la cátedra. 

• Los nombres de las Clases, variables, atributos y selectores deben ser claros, significativos y acordes con la 

semántica. 

• Puede incluirse un archivo de texto llamado WorkSpace.txt para importar en el Workspace y facilitar el 

testeo y ejecución. Recomendado. 

Informes 

• El formato debe ser Microsoft Word 6.0 o superior (el número de versión, no el producto). 

• Debe ser prolijo, claro y contener una cantidad razonablemente BAJA de errores de ortografía. 

• Incluirlo en el directorio correspondiente con el nombre Informe.doc. 

• Debe contener: 

• El enunciado del ejercicio. 

• Nombre y correo electrónico del/los integrante/s del grupo. 

• La respuesta del ejercicio (incluyendo código de haberlo). 

• Comentarios sobre el ejercicio y su enunciado. Si no tienen ninguno, escríbanlo. 

• Numerar las hojas. 

• Usar el template Informe.dot provisto por la cátedra. (Ver archivos en la página del grupo) 

Pharo 

Bajar la versión de http://www.pharo-project.org/home 

Ejercicios resueltos guia 2011.doc Página 5


Notación y Ejemplos de Modelado 

“If you can't write it down in English, you can't code it” – Peter Halpern 

Objetos y Mensajes 

En el paradigma de Objetos, sólo hay objetos y mensajes (que también son objetos). 

NADA MÁS. 

Notación gráfica para diagramas 

Leer con atención como se deben realizar los diagramas que se utilizarán durante el curso para comunicar los 

diseños realizados. 

Notación Sintáctica General 

Las colaboraciones se notan siempre O M, donde O representa un objeto y M un mensaje. 

Salvo excepciones, cada nombre, tanto de O como de M, cumple con el siguiente formato: 

• Comienza con minúscula. 

• Si el nombre es compuesto, cada palabra comienza con mayúscula (salvo la primera) y no hay espacios 

intermedios. 

Para la sintaxis de O tener en cuenta que los objetos globalmente conocidos comienzan con mayúscula y el 

resto: colaboradores internos, externos y variables temporarias, lo hacen con minúscula. 

El texto que conforma el nombre de los mensajes M, sin los parámetros, se llama selector. 

Existen tres formatos diferentes para los selectores: 

1. Mensajes tipo unary. 

No tienen parámetros y, por ende, no llevan : (dos puntos). 

Ejemplos: size, refresh, open 

2. Mensajes tipo keyword. 

Están formados por una lista de pares keyword: parameter, donde keyword cumple con el mismo 

formato de siempre y, además, lleva pegado atrás un : (dos puntos). 

Ejemplos: between: anInteger and: anotherInteger, lessThan: aChar 

3. Mensajes tipo binary. 

Llevan un parámetro y el nombre del mensaje es un símbolo SIN un : (dos puntos) atrás. 

Ejemplos: + anInteger, < aChar 

Diagrama de Instancias (o de Objetos) 

Representa una vista estática del modelo, en él se incluyen los objetos intervinientes y las relaciones de 

colaboración entre ellos. No es indispensable representar todas las posibles relaciones de colaboración entre 

ellos, solamente las necesarias para transmitir lo que se desea. Si bien puede utilizarse para modelar de modo 

genérico, esto ocurre rara vez. La intención del diagrama es representar una situación particular, un ejemplo 

puntual. 

Programa de la materia guia 2011.doc Página 6


interno 23 de 

la Línea 17 

unPasajero 

carrocería 

• Cada “cajita” representa un objeto. Esto es, una instancia particular y única en el universo, y no una forma 

genérica de referirse a objetos como podría ser “Colectivo”. 

• El nombre del objeto es desde el punto de vista del modelador, no es un nombre propio del objeto. Si fuese 

así debería notárselo con mayúscula, como por ejemplo el nombre de una persona especial (Ej. “Juan 

Perez”) 

• Las flechas indican una relación estructural entre los objetos. Mas específicamente, indica que los objetos 

pueden colaborar, o sea, enviarse mensajes. 

• La flecha simple hace referencia a una instancia particular, mientras que la doble indica una colección de 

objetos. Esto es un grupo de objetos, no necesariamente homogéneos. La relación indica conocimiento del 

grupo, algo distinto a conocer cada integrante por separado. 

• Puede colocarse una etiqueta sobre la flecha, indicando el nombre con que el objeto origen conoce al objeto 

destino, si esto es importante para distinguirla de otras o para aclarar el significado de esta relación, pero se 

recomienda su uso únicamente cuando la aclaración es necesaria. 

Diagrama de Secuencia (o de Colaboración) 

unaCarrocería 

El Indio 

Representa una vista dinámica del modelo, incluyendo la secuencia de envío de mensajes (colaboraciones), que 

tiene lugar entre algunos objetos del modelo para llevar a cabo una tarea. Al igual que en el diagrama de 

instancias, no es indispensable representar todos los envíos de mensajes, solamente los necesarios para 

transmitir lo que se desea. La intención del diagrama es representar una situación particular, un ejemplo 

puntual. 



tiempo 

unGalán unaDama 

Invitada 

contestar: '¿Qué querés tomar?' 

^ 'Una Coca' 

servir: 'Una Coca' 

^ unaPesi 

pensarQueTomar 

unMozo 

• Cada cajita, al igual que en el diagrama de objetos, representa un objeto. 

• El sentido del avance del tiempo es de arriba hacia abajo. 

• Cada flecha está representando el envío de un mensaje de un objeto al otro, o el retorno de un objeto, que se 

nota mediante el símbolo ^. 

• El mensaje tipo rulo significa un mensaje enviado a sí mismo. 



Diagrama de Clases 

Representa las clases intervinientes en un modelo y el vínculo de herencia existente entre ellas. El diagrama 

incluye el protocolo que poseen los objetos instancias de las mismas. 

AM/FM Radio 

sintonizeAM 

“Cambia de banda a AM” 

dialIn: aFrequency band: aBand 

advanceDial: aRange 

SonyDigitalRadio 

voltage 

sintonizeAM 

off 

ElectricDevice 

• Cada cajita representa una clase. 

• El nombre de la clase en itálica indica que la misma es abstracta. 

• La flecha indica relación de herencia y va desde la subclase hacia la superclase. Por convención se intenta 

que las flechas vayan en sentido ascendente. 

• El hecho de que en una subclase reaparezca un mensaje que estaba en una de sus superclases indica que la 

clase redefine el método que lo implementa. 

• No se incluyen los colaboradores internos, pero se indican si tienen métodos de acceso a los mismos. De 

éstos, solamente se usan getters en representación de ambos. 

• Los métodos de clase van, separados por una raya, arriba de los de instancia. 

• Puede agregarse una línea de comentario bajo algún método utilizando comillas dobles (“”). 

• Excepcionalmente, pueden incluirse cajas que representen objetos individuales, con una flecha punteada 

indicando que son instancia de alguna de las clases del diagrama. 

Programa de la materia guia 2011.doc Página 9 

on 

off 

isOn 

WashingMachine 

changeSpeedTo: aSpeed 

miRadioPortatil


Pare, Atención, Modele 

Lea con atención la resolución del siguiente ejercicio. El objetivo es que empiece a familiarizarse con la 

resolución de los problemas que se presentarán, utilizando la notación de la cátedra. 

Enunciado 

1. Modele un semáforo. 

2. Modele un semáforo para peatones. 

Resolución del punto 1 

Identificar los objetos 

En esta primera iteración, intentamos identificar los objetos que vamos a 

necesitar. Sin entrar demasiado en detalle, parece obvio que vamos a 

necesitar al semáforo y a las lámparas de colores. 

Notar que se puso unaLamparaVerde y no unaLuzVerde, ya que el 

semáforo interactúa con las lámparas y no con la luz que éstas emiten. 

Primer diagrama de secuencia 

Intentemos hacer un diagrama de secuencia que muestre el funcionamiento normal del semáforo. Para eso 

describimos primero qué queremos mostrar exactamente. 

Este diagrama de secuencia muestra un ciclo de funcionamiento de un semáforo, desde que está en verde hasta 

que vuelve a estarlo. 

Empecemos entonces... 

unSemaforo unaLamparaVerde unaLamparaAmarilla unaLamparaRoja 

encender 

Nos encontramos ahora con el primer problema: ¿cómo se apaga la lámpara verde? Es decir, ¿cuándo se apaga? 

¿Quién la apaga? 

Una opción es que la lámpara se apague sola, pero parece más coherente que 

el semáforo la apague, ya que él la prende. 

Esto no resuelve el hecho de saber cuándo apagarla, por más que el semáforo 

pueda saber que la luz verde debe estar encendida por 40 segundos por 

ejemplo, decidir cuándo pasaron los 40 segundos parece demasiado para el 

semáforo. Necesitamos un timer: 

¿Qué mensaje le enviamos al timer entonces? 



Bueno, pensemos en qué es un timer, qué queremos de él. En principio, queremos que avise a alguien cuando 

transcurre determinada cantidad de tiempo. Asociamos esto con lo que sabemos de hardware, parece que lo que 

estamos necesitando son interrupciones. Definimos entonces que el mensaje será interrumpirA: 

unObjeto en: unaCantidadDeTiempo. 

Sigamos entonces con el diagrama de secuencia. 

Revisar el protocolo de los objetos 

El diagrama parece completo, revisemos entonces los mensajes que estamos enviando a cada objeto, a ver si 

parecen coherentes: 

• Del mensaje del timer ya hablamos. 

• Enviarles encender y apagar a las lámparas no parece nada raro, parecen mensajes que una 

lámpara sabe responder. 

• Enviarle interrumpir al semáforo...no suena muy bien...lo que queremos es que cambie la luz, 

suena mejor cambiar. 



Ahora, ¿cómo sabe el timer que debe mandarle el mensaje cambiar al semáforo? Ni siquiera tiene por qué 

saber que lo que está interrumpiendo es un semáforo. 

Esto podemos resolverlo modificando el protocolo del timer, para que en lugar de interrumpirA:... el 

mensaje sea enviar: unMensaje a: unObjeto en: unaCantidadDeTiempo. No parece mal, 

después de todo mandar la interrupción era mandarle un mensaje al objeto. 

El diagrama de secuencia queda finalmente así: 

¿Qué más queremos mostrar? 

Bueno, sabemos que a veces los semáforos están desactivados, titilando en amarillo. 

Este diagrama de secuencia muestra cómo desactivan al semáforo y vuelven a activarlo luego de que titila dos 

veces la luz amarilla, para que retome su ciclo de funcionamiento normal: 





Resolución del punto 2 

Diagrama de Instancia de un Semáforo para peatones 

El semáforo para peatones parece casi igual al semáforo para autos, por lo 

que los diagramas no merecen otras explicaciones. 

Diagramas de Secuencia de un Semáforo para peatones 

Este diagrama muestra un ciclo de funcionamiento de un semáforo para peatones, desde que está en verde hasta 

que vuelve a estarlo: 



Práctica 1 - Smalltalk 

“The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense” - Edsger 

Dijkstra 

“It is practically impossible to teach good programming style to students that [sic] have had prior exposure to 

BASIC; as potential programmers they are mentally mutilated beyond hope of regeneration” - Edsger Dijkstra 

Simplicidad de la Sintaxis 

La sintaxis de Smalltalk es muy simple: la escritura de su gramática ocupa una sola página; 

tiene pocas “palabras reservadas” y ningún “comando”. 

Conociendo Smalltalk 

1) Bajar Pharo de la página (www.pharo-project..org) y levantar la imagen.En la ventana “Welcome To Pharo” 

verán una invitación a realizar el tutorial que se realiza evaluando la siguiente colaboración: 

ProfStef go. 

(Recuerden que para ejecutar una colaboración deben seleccionarla y luego presionar CTRL+D o botón derecho 

del mouse y seleccionar “Do it”) 

Este ejercicio es por lo tanto, realizar todo el tutorial. 

Normas de codificación Smalltalk 

“… every curve and line has to have real meaning; it can not be arbitrary” – Frank Lloyd Wright 

Por favor lea estas normas de codificación, las cuales deberá utilizar en todos los trabajos que impliquen 

codificar con Smalltalk. 

Estas normas son guías, no leyes inapelables. Sin embargo, la decisión de no seguirlas en un caso particular 

debería estar fundamentada. 

• Elija nombres que sean significativos. 

• Los nombres de clase, variables globales, de clase y pool dictionaries, comienzan con mayúscula. Si el nombre es 

compuesto, comience cada palabra con mayúscula. 

• Los nombres de método, variables de instancia, temporarias y parámetros de método, comienzan con minúscula. Si el 

nombre es compuesto, comience cada palabra, salvo la primera, con mayúscula. 

• Evite elegir para una clase un nombre que diga algo sobre su implementación. 

• Use sustantivos y oraciones comunes para objetos que no son Boolean. 

• Use cláusulas predicativas o adjetivos para objetos o estados Boolean, pero no para estados no Boolean. 

• Use oraciones y verbos imperativos para métodos que realizan una acción. 

• Use oraciones que comiencen con un verbo, tales como is o has, para métodos que respondan Boolean cuando se 

interroga por el estado de un objeto. 

• Use #new: o #new solamente para métodos de creación de instancia. Use #initialize para establecer los 

valores iniciales de las variables de instancia. 

Material de lectura y trabajo guia 2011.doc Página 15


• Los métodos que devuelven el estado de una variable (getters) deberían tener de nombre el de la variable. 

• Los métodos que establecen el valor de una variable (setters), deberían tener de nombre el de la variable, seguido de un 

: (dos puntos). 

• No utilice un mismo nombre de variable temporaria dentro del mismo scope para más de un propósito. 

• Utilice el siguiente esquema genérico para los métodos: 

Selector del Mensaje y nombres de Argumentos 

“Comentario” 

| Variables temporarias | 

Sentencias 

• Utilice por lo menos un blanco antes y después de los siguientes operadores binarios: * + < = > | := == = y - (usado como operador binario). Omita espacios a ambos lados del operador binario /. Preceda el signo - 

(usado como operador unario) con, por lo menos, un blanco. 

• Cuando los paréntesis () delimitan una expresión o una lista de argumentos, deje por lo menos un blanco antes del 

paréntesis izquierdo y luego del derecho, pero no deje espacios entre múltiples paréntesis izquierdos o derechos. Esto 

aplica también a los delimitadores de bloque []. 

• Deje al menos un blanco luego, pero no antes, de una , (coma), un ; (punto y coma), y un : (dos puntos) cuando 

forma parte de un selector. No deje un blanco entre un : (dos puntos) y el argumento de un bloque. 

• Indente para marcar el anidamiento lógico. Si hay casos alternativos encolúmnelos consistentemente. 

• Parta los mensajes de varios keywords en múltiples líneas para evitar los line wraps. Indente cada línea. 

• Use mensajes en cascada en lugar de repetir el objeto receptor, aún el caso en el que el receptor es self. 

• En un mensaje en cascada, coloque cada mensaje en línea aparte e indentado, separados del objeto receptor. 

• Los métodos, salvo contadas excepciones, deberían tener una longitud máxima de entre 6 y 8 líneas. 1 

• Limite la longitud de las líneas de código a 60 caracteres o al ancho de la ventana, lo que sea menor. 

• Utilice paréntesis extras para simplificar la lectura de una expresión complicada. Use paréntesis para hacer el orden de 

evaluación claro y explícito. 

“Specifying an object, sending it a message, and getting back another object as the result are the only things 

that ever happen in Smalltalk code” – Ted Kaehler, Dave Patterson 

Errores comunes con Smalltalk 

“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better” – Samuel Beckett 

“The only man who never makes mistakes is the man who never does anything” – Theodore Roosevelt 

Leer con atención este punto, le ahorrará algunos dolores de cabeza posteriormente. 

#add: retorna su argumento 

En toda collection que crece, #add: retorna su argumento y no el receptor, que es lo que la gente 

usualmente asume. Así, se suele escribir: 

(c 

add: x) 

add: y 

1 Un análisis de la imagen de Smalltalk mostró un promedio de 7.01 líneas de código y 2.25 de comentario por 

método. 

Regla del Objeto en Smalltalk 

En Smalltalk cada objeto, incluso una clase, es una instancia de alguna clase. 



Cuando corresponde: 

c 

add: x; 

add: y. 

O si no: 

c add: x. 

c add: y 

Notar que esta es una buena oportunidad para usar yourself: 

^ Set new 

add: x; 

add: y; 

…; 

yourself. 

Para asegurarse el retorno del nuevo Set. 

Notar que hay buenas razones por las que #add: tiene ese comportamiento. Una de ellas es evitar el uso de 

variables temporarias, puesto que pueden crearse los argumentos en el momento (como por ejemplo un literal) y 

utilizarlo para otras cosas luego del #add:. Si quiere accederse a la colección, también se puede hacerlo 

utilizando mensajes en cascada. 

De todas formas, este comportamiento ya forma parte del folclore Smalltalk, y no sería bueno modificarlo. 

Cambiar la colección mientras se itera sobre la misma 

Nunca debiera modificarse una collection mientras se la itera. Habrá elementos que serán movidos, y 

elementos que serán salteados o recorridos más de una vez. En cambio, debe hacerse una copia de la 

collection sobre la que se va a iterar. 

Por ejemplo: 

aCollection copy do: [:each | aCollection remove: each ] 

Olvido de ^ 

Es muy fácil olvidarse el caret (^) en una expresión. Si no hay un retorno al final del método, Smalltalk retorna 

el receptor del mismo. Solamente se requiere la falta de un ^ para arruinar una larga cadena de invocaciones a 

métodos. 

Métodos de creación de instancia 

Dos formas correctas de escribir un método para crear una instancia son algo así: 

new 

new 

^ super new 

initialize; 

yourself 



^ super basicNew 

initialize; 

yourself 

Debe redefinirse el método de instancia initialize en cada clase para inicializar las variables de instancia 

del objeto: 

initialize 

super initialize. “inicializa las variables heredadas” 

“inicializo las variables que yo defino” 

… 

Hay muchas formas de hacer esto mal. Quizás el error más común es olvidar el ^: 

new 

super new 

initialize; 

yourself 

El resultado es que se retorna una clase cuando lo que se quiere es una instancia de la misma. 

Otro error es olvidar la inicialización de la superclase, como en: 

initialize 

“inicializo las variables que yo defino” 

… 

El resultado es un objeto parcialmente inicializado. 

Otro error típico es crear un ciclo infinito escribiendo: 

new 

^ self new 

initialize; 

yourself 

Tener en cuenta que cuando se crear un objeto que necesita colaboradores para que el mismo tenga sentido, 

estos se deben pasar en el mensaje de construcción e inicialización. Por ejemplo: 

Person class>>named: aString bornOn: aDate 

^self new initializeNamed: aString bornOn: aDate 

Person>> initializeNamed: aString bornOn: aDate 

name := aString. 

dateOfBirth := aDate. 



Vean como de esta manera el objeto queda bien definido desde el momento que se crea y no es necesario tener 

setter para realizar cambio de sus colaboradores (al menos que el objeto así lo requiera) 

Redefiniendo #= y #hash 

Si se redefine el método #= (igualdad) en alguna clase, y sus instancias van a ser agregadas a un Set o un 

Dictionary 2 , se DEBE también redefinir el método #hash en esa clase. 

La razón es que los sets y dictionaries usan una clave hash para buscar rápidamente los elementos y la 

igualdad para completar la identificación. 

Si no se redefine el #hash, el método por omisión (en Object) usa el valor de #identityHash. Así, si 

solamente se redefine el #=, los objetos pueden compararse como iguales pero no retornarán la misma clave 

hash. Los sets y los dictionaries tendrán problemas para manejar correctamente estos objetos. 

La regla para el método #hash es la siguiente: 

x = y implica x hash = y hash. 

Otro punto a tener en cuenta es que, de cambiarse el método de hash, los objetos ya agregados en sets o 

dictionaries pueden no volver a encontrarse. 

Usando True o False en lugar de true o false 

Los valores booleanos son true y false, no True y False que son sus clases. 

Referencias 

http://www.exept.de/sites/exept/onlineDoc/english/programming/classicBugs.html 

Práctica 2 - Smalltalk Avanzado 

“A language that doesn't affect the way you think about programming, is not worth knowing” – Alan J. Perlis 

“A programming language is low level when its programs require attention to the irrelevant” – Alan J. Perlis 

La Cultura de la Reusabilidad 

Desarrolle todo el software bajo la premisa de que será reusado. 

No crea que ningún software es reusable hasta que no lo haya visto siendo reusado. 

Blocks y Contexts 

1. Escriba la definición de Bloque 

2. Implemente el mensaje #timesRepeat: aNumber de tal manera que lo sepan responder los Bloques 

3. Dado el siguiente código, responder que devuelve cuando se envían los mensajes #m1, #m2 y #m3. ¿Por 

qué devuelven esos objetos? 

A>>m1: anArg 

| tempVar | 

tempVar := 1. 

instVar := 20. 

^ [ self size + anArg + tempVar + instVar ] 

2 Esto no es válido para IdentitySet ni IdentityDictionary 



B>>m2 

| a | 

a := A new. 

a size: 10. 

Transcript show: (a m1: 300) value asString. 

C>>m3 

| tempVar a | 

a := A new. 

a size: 10. 

tempVar := 2000. 

Transcript show: (a m1: 300) value asString 

4. ¿Qué se obtiene al evaluar? 

a) [ self ] 

b) [ super ] 

c) [ .... 

^ self ] 

d) [.... 

^ super ] 

5. Si tengo este método: 

Test>>bloque1 

| var1 | 

var1 := 0. 

^ [ var1 := var1 + 1 ] 

Y después ejecuto en el Transcript: 

Test new bloque1 inspect 

Y dentro del inspector le mando el mensaje value varias veces, ¿Qué sucede?. 

Ahora corro de vuelta, sin cerrar el inspector anterior 

Test new bloque1 inspect 

¿Qué sucede? ¿Qué valores obtengo en cada inspector al enviar el mensaje #value? 

Referencias: 

• Chamond Liu. Smalltalk, Objects and Design. Sección 3.10: Control Flow 

• Chamond Liu. Smalltalk, Objects and Design. Página 55: Blocks [...] 

• http://wiki.cs.uiuc.edu/VisualWorks/Closures 

No corte la rama sobre la que se sienta 

El ambiente Smalltalk permite modificar sus propias herramientas de trabajo. Esto es muy 

útil y muy atractivo, pero sea cuidadoso al modificar cosas “de base”. En general, no 

conviene modificar las herramientas provistas por el ambiente, sino subclasificarlas e 

introducir las modificaciones en la subclase. Luego, se puede modificar el new de la 

herramienta para que nos de una instancia de la subclase, o proveer otro mecanismo de 

acceso. 



Práctica 3 – Teoría de Objetos 

Objeto y Clase 

1. Defina qué es un objeto. De ejemplos concretos 

2. Defina qué es una clase. De ejemplos concretos. 

3. ¿Cuál es la diferencia entre un objeto y una clase? 

4. ¿Todos los lenguajes de objetos poseen clases? ¿Cualés no? ¿Qué ventajas y desventajas tienen entre sí? 

Mensajes-Métodos vs. Rutinas 

5. ¿Cuál es la diferencia entre mensaje y método? 

6. ¿Cuál es la diferencia entre enviar un mensaje e invocar una función en el paradigma estructurado? 

7. ¿Qué relación tiene la separación mensaje/método con el dynamic binding? 

8. ¿Qué relación tiene esta separación con el polimorfismo? 

9. +-*/ ¿Son mensajes, métodos o funciones? 

self y super 

“No man can produce great things who is not thoroughly sincere in dealing with himself” – James Russell 

Lowell 

1. De la definición de las pseudo-variables self y super 

2. Señale las diferencias entre variables y pseudo-variables 

3. ¿Cuál es el resultado de evaluar …? (No evalúe estas colaboraciones en Pharo puesto que algunas no 

funcionan debido a la implementación de dicho Smalltalk. Simplemente piense que significa cada una de 

ellas y escriba el resultado que se le ocurre que debería generar) 

a) super = self 

b) self := x 

c) super := x 

d) x := self 

e) x := super 

4. Si ejecuta el siguiente código, ¿qué se obtiene?. 

A>>m2 

| a | 

a := super. 

a m1 “tanto A como SuperA implementan m1” 

5. ¿Cuál es la diferencia entre utilizar super y utilizar una sintaxis de la forma nombreDeSuperclase::mensaje? 

(al estilo C++) 

6. Para hacer en velocidad: 

MyClass>>test1 

^ super == self 

MyClass>>test2 

^ self class == super class 



Evaluar MyClass new test1 y MyClass new test2 da: 

a) true true 

b) true false 

c) false true 

d) false false 

7. Analice el resultado de los siguientes mensajes 

A 

m1 : ^ 'A' 

m8 : ^ self m1 

m9 : ^ super m1 

m10 : ^ self m8 

m11 : ^ self m9 

m12 : ^ 'A' 

B 

m1 : ^ 'B' 



m12 : ^ 'B' 

C 

m1 : ^ 'C' 





a) C new m1 

b) C new m2 

c) C new m3 

d) C new m4 

e) C new m5 

f) C new m6 

g) C new m7 

h) C new m8 

i) C new m9 

j) C new m10 

k) C new m11 

l) C new m12 

Referencias: 

1. Chamond Liu. Smalltalk, Objects and Design. Página 54: Special variables self and super 

Method Lookup 

1. Escriba el algoritmo de MethodLookup 

2. ¿Pondría la ejecución del method lookup del lado del emisor o del lado del receptor de un mensaje? 

3. ¿Qué ventajas nos brinda que el primero en enterarse de un MNU sea el receptor del mensaje? 

4. ¿Podría el method lookup resolverse en un lenguaje dinámico al compilarse el método que se está 

programando? ¿Hay excepciones? ¿Y en lenguajes estáticamente tipados? 

5. Piense 3 ejemplos para qué le sería útil redefinir el MNU 

Referencias: 

1. Chamond Liu. Smalltalk, Objects and Design. Sección 16.2: Method lookup 



Clases / Métodos Abstractos / Concretos 

1. Escriba la definición de Clases / Métodos Abstractos / Concretos 

2. ¿Qué debe redefinirse al subclasificar? 

3. Considerar todas las combinaciones de clases y métodos, abstractos y concretos, y decidir existencia. 

Ejemplo: ¿Puede una clase concreta tener métodos abstractos? ¿Una abstracta todos los métodos 

concretos?, etc. 

4. ¿Para qué sirven los métodos concretos en las clases abstractas? 

5. ¿Qué problemas podría ocasionarle heredar de una clase concreta? ¿Lo haría igual? 

6. El objetivo de modelar usando clases abstractas es compartir código. ¿Verdadero o Falso? Justifique. 

Referencias: 

1. Chamond Liu. Smalltalk, Objects and Design. Capítulo 5: Abstract classes 

2. Chamond Liu. Smalltalk, Objects and Design. Capítulo 9: When (not) to inherit 

Objetos mutables vs. Inmutables 

1. Ensaye una definición de inmutabilidad de los objetos 

2. ¿Cómo considera a las siguientes clases? ¿Cómo las considera Smalltalk?: 

a) Symbol 

b) String 

c) MonetaryUnit 

d) Date 

e) Measure 

3. ¿Y si a un objeto número (clase Integer por ejemplo) le cambiase el valor? 

Referencias: 

1. Chamond Liu. Smalltalk, Objects and Design. Páginas 35-36 



Programa de la materia 

“The only thing that makes life possible is permanent, intolerable uncertainty, not knowing what comes next” – 

Ursula K. Leguin 

1. Calidad de Software y Calidad de Desarrollo 

2. Paradigma y Modelo Computacional 

3. Paradigma de Orientación a Objetos 

3.1. Programa 

3.2. Objeto 

3.3. Mensaje 

3.4. Colaboraciones 

3.5. Protocolo 

3.6. Colaboradores (Internos y Externos) 

3.7. Método 

3.8. Polimorfismo y Binding Dinámico 

3.9. Creación de Objetos 

3.9.1. Clases 

3.9.2. Prototipos 

3.10. Destrucción de Objetos 

3.10.1. Automática 

3.10.2. Manual 

3.11. Mecanismos de Sharing 

3.11.1. Herencia (Simple vs. Múltiple. Estricta vs. No Estricta) 

3.11.2. Delegación (Implícita vs. Explícita) 

3.12. Mecanismos de Abstracción 

3.12.1. Clasificación (Clases Abstractas y Concretas) 

3.12.2. Subclasificación 

3.12.3. Protocolos en Distintos Niveles 

4. Modelos Básicos con Objetos 

4.1. Magnitudes 

4.2. Lógica Booleana 

4.3. Contextos de Ejecución 

4.4. Colecciones 

5. Aplicaciones Orientadas a Objetos 

5.1. Definición de Aplicación 

5.2. Paradigmas Model-View-Controller y Morphic 

5.3. Mecanismos de Observación 

5.3.1. Dependencias 

5.3.2. Eventos 

6. Concepto de Tipo en la Orientación a Objetos 

6.1. Revisión de TAD 

6.2. Aserciones y Contratos 

6.3. Jerarquías Polimórficas 

7. Recursión y Orientación a Objetos 



Bibliografía 

“Libros para ser libres” – Mafalda. Quino. 

“If you believe everything you read, you better not read” – Proverbio Japonés 

Básica 

• Ducasse, Black, Nierstrasz, Pollet: “Pharo by Example”, http://pharobyexample.org/ 

• Chamond Liu. Smalltalk, Objects, and Design. toExcel, iUniverse.com, Inc. 1996. 

• Adele Golderg, David Robson. Smalltalk-80: The Language. Addison Wesley. 1989. 

• Lauren Wiener, Brian Wilkerson, Rebecca Wirfs-Brock. Designing Object-Oriented Software. Prentice 

Hall. 1990. 

De Referencia 

• Wilf R. LaLonde, John R. Pugh. Inside Smalltalk volumes I y II. Prentice Hall. 1991. 

• Bertrand Meyer. Object-Oriented Software Construction. Prentice Hall. 2 nda edición. 1997. 

• Edward J. Klimas, Suzanne Skublics, David A. Thomas. Smalltalk with Style. Prentice Hall. 1995. 

Artículos (provistos por la cátedra) 

• Brian Foote, Ralph Johnson. “Designing Reusable Classes”. Journal of Object-Oriented Programming. 

June/July 1988, volume 1, number 2, pages 22-35. 

• Bobby Woolf. “Polymorphic Hierarchy”. The Smalltalk Report. January 1997, volume 6, number 4, 

pages 15-18. 

• Henry Lieberman. “Using Prototypical Objects to Implement Shared Behaviour in OO Systems”. 

OOPSLA '86, SIGPLAN Notices, volume 21, number 9, pages 214-223. Portland, OR. 1986. 

• Randall Smith, David Ungar. “Self: The Power of Simplicity”. OOPSLA '87 Conference Proceedings, 

pages 227-241. Orlando, FL. 1987. 

• Henry Lieberman, Laura Stein, David Ungar. “The Treaty of Orlando”. Birds of a Feather Session, 

A.C.M. Conference on OOPSLA '87. Orlando, FL. 1987. 

• Henry Lieberman, Laura Stein, David Ungar. “A Shared View of Sharing: The Treaty of Orlando”. Object-Oriented 

Concepts, Databases, and Applications, A.C.M. Press, pages 31-48. 1989. 

• Henry Lieberman, Laura Stein, David Ungar. “Of Types and Prototypes: The Treaty of Orlando”. 

SIGPLAN Notices, volume 23, number 5, pages 43-44. 1988. 

Herramientas 

Pharo: http://www.pharo-project.org/home 

Fuentes adicionales de información guia 2011.doc Página 25


Fuentes adicionales de información 

"We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire 

works of Shakespeare. Now, thanks to the Internet, we know this is not true" – Robert Wilensky 

Objetos 

The Object-Oriented Page www.well.com/user/ritchie/oo.html 

Grupos y Listas de Smalltalk 

Smalltalk Archive at the University of Illinois st-www.cs.uiuc.edu 

Recursos de Smalltalk iamwww.unibe.ch/~scg/Resources/Smalltalk/index.html 

ClubSmalltalk http://groups.google.com/group/clubSmalltalk 

SUGAR (Smalltalk User Group of Argentina) www.sugarweb.com 

Smalltalking www.smalltalking.net 

Paper fundacional de Squeak users.ipa.net/~dwighth/squeak/oopsla_squeak.html 

Smalltalks 

Pharo http://www.pharo-project.org/home 

VisualWorks www.cincomsmalltalk.com 

VisualAge Smalltalk http://www.instantiations.com/VAST/index.html 

Dolphin Smalltalk http://www.object-arts.com/ 

Squeak www.squeak.org 

Squeak Swiki minnow.cc.gatech.edu/squeak 

SELF 

The SELF Project www.sunlabs.com/research/self 



NORMAS BÁSICAS DE SEGURIDAD 

“The world is a dangerous place to live, not because of the people who are evil, but because of the people who 

don't do anything about it” – Albert Einstein 

Departamento de Computación 

Las normas básicas de seguridad son un conjunto de medidas destinadas a proteger la salud de todos, prevenir 

accidentes y promover el cuidado del material de los laboratorios. Son un conjunto de prácticas de sentido 

común: el elemento clave es la actitud responsable y la concientización de todos: personal y alumnado. 

RESPÉTELAS y HÁGALAS RESPETAR. 

1. Se deberá conocer la ubicación de los elementos de seguridad en el lugar de trabajo, tales como: matafuegos, 

salidas de emergencia, accionamiento de alarmas, etc. 

Observar de qué tipo – A, B o C – es cada matafuego ubicado en el departamento de computación, y verificar 

qué material combustible – papel, madera, pintura, material eléctrico – se puede apagar con él. Por ejemplo, 

nunca usar un matafuego tipo A (sólo A) para apagar fuego provocado por un cortocircuito. 

Matafuegos Tipo A: sirven para fuego de materiales combustibles sólidos (madera, papel, tela, etc.). 

Matafuegos Tipo B: para fuego de materiales combustibles líquidos (nafta, kerosén, etc.). 

Matafuegos Tipo C: para fuegos en equipos eléctricos (artefactos, tableros, etc.). 

Existen matafuegos que sirven para los tres tipos de fuegos. Generalmente son de polvo. 

En caso de un fuego de tipo C, si se corta la corriente eléctrica se transforma en uno de tipo A. 

El agua en general apaga fuegos de tipo A. La arena sirve para apagar fuegos de tipo B. 

Salidas: 

Ante una emergencia: se podrá solicitar a un docente – JTP o profesor, u otra persona autorizada – que obtenga 

la llave de la puerta de planta baja. La persona autorizada que abra la puerta se hará responsable del cierre de la 

puerta y de la devolución de la llave. 

Las únicas ventanas sin reja son las de los cuartos 11 y 12 – dan a un balcón. 

No se deben bloquear las rutas de escape o pasillos con equipos, mesas, máquinas u otros elementos que 

entorpezcan la correcta circulación. 

2. No se permitirá comer, beber, ni fumar en los laboratorios. Recordar que el polvo y la tiza dañan las PC. 

3. No se permitirá enchufar ni desenchufar periféricos a las CPU de los laboratorios sin la supervisión del 

docente o administradores de la red. No se modificará la instalación de ningún equipo. 



4. Es indispensable recalcar la prudencia y el cuidado con que se debe manipular todo aparato que funcione con 

corriente eléctrica. Nunca debe tocar un artefacto eléctrico si usted está mojado o descalzo. 

5. No se permitirán instalaciones eléctricas precarias o provisorias. Se dará aviso inmediato a la Secretaría 

Técnica en caso de filtraciones o goteras que puedan afectar las instalaciones o equipos y puedan provocar 

incendios por cortocircuitos (Interno 355). 

6. Es imprescindible mantener el orden y la limpieza. Cada persona es responsable directa del lugar donde está 

trabajando y de todos los lugares comunes. 

7. Los laboratorios contarán con un botiquín de primeros auxilios con los elementos indispensables para atender 

casos de emergencia. 

8. Se recomienda descansar la vista por lo menos 15 minutos por cada hora de trabajo frente al monitor, según 

la Organización Mundial de la Salud. 

Procedimientos ante emergencias: 

* Emergencias médicas 

Si ocurre una emergencia tal como: cortes o abrasiones, quemaduras o ingestión accidental de algún producto 

químico, tóxico o peligroso, se deberá proceder: 

1. A los accidentados se les proveerán los primeros auxilios. 

2. Simultáneamente se tomará contacto con el Servicio Médico (Interno 482), o al Servicio Médico de Deportes 

(4784-4351 / 3948) 

3. Avise al Jefe de Laboratorio o autoridad del Departamento, quienes solicitarán asistencia de la Secretaría 

Técnica (interno 380) para que envíen personal del Dpto. de Mantenimiento, Seguridad y Control o Servicios 

Generales según correspondan. 

4. El Jefe de Departamento notificará el accidente al Servicio de Higiene y Seguridad para su evaluación e 

informe, donde se determinarán las causas y se elaborarán las propuestas para modificar dichas causas y evitar 

futuras repeticiones. 

5. Centros para requerir ayuda médica: 

S.A.M.E. 

Teléfono 107 

Hospital Pirovano 

Av. Monroe 3555. Capital Federal. Tel. 4542-5552 / 9279 

INTOXICACIONES : 



* Incendio: 

Hospital de Niños Dr. R. Gutiérrez 

Sánchez de Bustamante 1399. Capital Federal. Tel. 4962-6666. 

Hospital de Niños Dr. P. de Elizalde 

Av. Montes de Oca 40. Capital Federal. Tel. 4307-7491 Toxicología 4300-2115 

QUEMADURAS : 

Hospital de Quemados 

Pedro Goyena 369. Capital Federal. Tel. 4923-4082 / 3022 

OFTALMOLOGÍA 

Hospital Santa Lucía 

San Juan 2021. Capital Federal. Tel. 4941-7077 

Hospital Dr. P. Lagleyze 

Av. Juan B. Justo 4151. Capital Federal. Tel. 4581-0645 / 2792 

1. Mantenga la calma. Lo más importante es ponerse a salvo y dar aviso a los demás. 

2. Si hay alarma, acciónela. Si no, grite para alertar al resto. 

3. Se dará aviso inmediatamente al Departamento de Seguridad y Control (Interno 311) informando el lugar y 

las características del siniestro. 

4. Si el fuego es pequeño y sabe utilizar un extintor, úselo. Si el fuego es de consideración, no se arriesgue y 

manteniendo la calma ponga en marcha el plan de evacuación. 

5. Si debe evacuar el sector apague los equipos eléctricos y cierre las llaves de gas y ventanas. 

6. Evacue la zona por la ruta asignada. 

7. No corra, camine rápido, cerrando a su paso la mayor cantidad de puertas. No utilice ascensores. Descienda 

siempre que sea posible. 

8. No lleve consigo objetos, pueden entorpecer su salida. 

9. Si pudo salir, por ninguna causa vuelva a entrar. Deje que los equipos especializados se encarguen. 

10. Recuerde que las mayores causas de accidentes son – y en este orden: 

1) el pánico 

2) el humo 

3) el fuego. 

* Teléfonos útiles 



BOMBEROS Teléfono 100 

DIVISIÓN CENTRAL DE ALARMA: 4381-2222 / 4383-2222 / 4304-2222. 

CUARTEL V DE BELGRANO: 

Obligado 2254. Capital Federal. Tel. 4783-2222 

BOMBEROS DE VICENTE LÓPEZ: 

Av. Maipú 1669. Vicente López. Tel. 4795-2222 

BOMBEROS DE SAN ISIDRO: 

Santa Fe 650. Martínez. Tel. 4747-2222 

La corriente eléctrica como factor de accidentes y lesiones. 

Es imprescindible la concientización del riesgo que engendra la corriente eléctrica. Ya que si bien no es la 

mayor fuente de accidentes, se trata generalmente de accidentes graves, en muchos casos mortales. 

Riesgos de la electricidad. 

Riesgos de incendios por causas eléctricas. 

Los incendios provocados por causas eléctricas son muy frecuentes. Ellos ocurren por: 

* sobrecalentamiento de cables o equipos bajo tensión debido a sobrecarga de los conductores. 

* sobrecalentamiento debido a fallas en termostatos o fallas en equipos de corte de temperatura. 

* fugas debidas a fallas de aislación. 

* auto ignición debida a sobrecalentamiento de materiales inflamables ubicados demasiado cerca o dentro de 

equipos bajo tensión, cuando en operación normal pueden llegar a estar calientes. 

* ignición de materiales inflamables por chispas o arco. 

Shock Eléctrico. 

Un shock eléctrico puede causar desde una sensación de cosquilleo hasta un desagradable estímulo doloroso 

resultado de una pérdida total del control muscular y llegar a la muerte. 

Control de los riesgos eléctricos. 

Los factores principales a considerar son : 

* el diseño seguro de las instalaciones. 

* el diseño y construcción de los equipos de acuerdo a normas adecuadas. 

* la autorización de uso después que se ha comprobado que es seguro 

* el mantenimiento correcto y reparaciones 

* las modificaciones que se efectuen se realicen según normas 

Las precauciones generales contra el shock eléctrico son: 

* la selección del equipo apropiado y el ambiente adecuado 



* las buenas prácticas de instalación 

* el mantenimiento programado y regular 

* el uso de acuerdo a las instrucciones del fabricante. 

La protección contra el shock eléctrico se consigue usando : 

* equipos de maniobra con baja tensión. 

* la doble aislación o la construcción aislada 

* las conexiones a tierra y la protección por equipos de desconexión automática 

* la separación eléctrica entre las fuentes y la tierra. 

* Frecuentemente se usan adaptadores de enchufes. Tenga siempre en cuenta que cuando se usan estos 

aditamentos puede desconectarse la tierra del equipo que está usando. 

Generales: 

. Todo material corrosivo, tóxico, inflamable, oxidante, radiactivo, explosivo o nocivo deberá estar 

adecuadamente etiquetado. 

. El material de vidrio roto no se depositará con los residuos comunes. Será conveniente ubicarlo en cajas 

resistentes, envuelto en papel y dentro de bolsas plásticas. 

. Ante un problema, consultar al Servicio de Higiene y Seguridad (Interno 275).

Guia Trabajos Practicos - Departamento de Computación ...

Create successful ePaper yourself

Delete template?

Save as template?