guía de trabajos prácticos - dc.uba.ar · pdf fileprograma de la materia guia...

Programación Orientada a Objetos

Guía de Trabajos Prácticos

Departamento de ComputaciónFacultad de Ciencias ExactasUniversidad 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....................................................................................................................6Notación Sintáctica General...........................................................................................................................6Diagrama de Instancias (o de Objetos)...........................................................................................................6Diagrama de Secuencia (o de Colaboración)..................................................................................................7Diagrama de Clases........................................................................................................................................9

Pare, Atención, Modele .................................................................................................................................10Enunciado.....................................................................................................................................................10Resolución del punto 1.................................................................................................................................10Resolució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..........................................................................................................................16Cambiar la colección mientras se itera sobre la misma.................................................................................17Olvido de ^...................................................................................................................................................17Métodos de creación de instancia.................................................................................................................17Redefiniendo #= y #hash..............................................................................................................................19Usando 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............................................................................................................................................25Básica...........................................................................................................................................................25De 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): [email protected] Hernán Wilkinson (JTP): [email protected] Oca (Ayudante de 1ra) [email protected]

Y además:Lista de docentes: [email protected] (alumnos y docentes): [email protected]á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

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

http://www.yahoogroups.com/group/poo-uba

mailto:[email protected]





http://www.yahoogroups.com/group/doc-objetos-uba

http://www.yahoogroups.com/group/poo-uba

http://www.dc.uba.ar/people/materias/poo


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)

PharoBajar 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

Notación gráfica para diagramasLeer 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

Objetos y MensajesEn el paradigma de Objetos, sólo hay objetos y mensajes (que también son objetos). NADA MÁS.


• 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)

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.


interno 23 de la Línea 17

unaCarrocería El Indio

unPasajero

carrocería


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


unGalán unaDama Invitada

unMozo

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

'Una Coca'

pensarQueTomar

servir: 'Una Coca'

unaPesi

tiempo


Diagrama de ClasesRepresenta 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.

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


AM/FM Radio

sintonizeAM

dialIn: aFrequency band: aBand advanceDial: aRange

ElectricDevice

on off isOn

WashingMachine

changeSpeedTo: aSpeed

SonyDigitalRadio

voltage

sintonizeAM off

“Cambia de banda a AM”

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.

Enunciado1. Modele un semáforo.2. Modele un semáforo para peatones.

Resolución del punto 1Identificar los objetosEn 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 secuenciaIntentemos 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 unaLamparaAmarilla unaLamparaRojaunaLamparaVerde

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 objetosEl 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 2Diagrama de Instancia de un Semáforo para peatonesEl 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 peatonesEste 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” - Eds-ger 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

Conociendo Smalltalk1) 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

Simplicidad de la SintaxisLa 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”.


• 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 argumentoEn 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 SmalltalkEn 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 mismaNunca 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 instanciaDos formas correctas de escribir un método para crear una instancia son algo así:new

^ super newinitialize;yourself

new



^ super basicNewinitialize;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 newinitialize;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 newinitialize;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 #hashSi se redefine el método #= (igualdad) en alguna clase, y sus instancias van a ser agregadas a un Set o un Dictionary2, 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 falseLos valores booleanos son true y false, no True y False que son sus clases.

Referenciashttp://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

Blocks y Contexts1. Escriba la definición de Bloque2. Implemente el mensaje #timesRepeat: aNumber de tal manera que lo sepan responder los Bloques3. 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


La Cultura de la ReusabilidadDesarrolle 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.

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


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 inspectY dentro del inspector le mando el mensaje value varias veces, ¿Qué sucede?.Ahora corro de vuelta, sin cerrar el inspector anteriorTest 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 sientaEl 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.

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


Práctica 3 – Teoría de Objetos

Objeto y Clase1. Defina qué es un objeto. De ejemplos concretos2. 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. Rutinas5. ¿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 super2. Señale las diferencias entre variables y pseudo-variables3. ¿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 = selfb) self := xc) super := xd) x := selfe) 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 trueb) true falsec) false trued) false false

7. Analice el resultado de los siguientes mensajes

a) C new m1b) C new m2c) C new m3d) C new m4e) C new m5f) C new m6g) C new m7h) C new m8i) C new m9j) C new m10k) C new m11l) C new m12

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

Method Lookup1. Escriba el algoritmo de MethodLookup2. ¿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


Cm1 : ^ 'C'm4 : ^ self m1m5 : ^ super m1m6 : ^ super m2m7 : ^ super m3

Am1 : ^ 'A'm8 : ^ self m1m9 : ^ super m1m10 : ^ self m8m11 : ^ self m9m12 : ^ 'A'

Bm1 : ^ 'B'm2 : ^ self m1m3 : ^ super m1m12 : ^ 'B'


Clases / Métodos Abstractos / Concretos1. Escriba la definición de Clases / Métodos Abstractos / Concretos2. ¿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 classes2. Chamond Liu. Smalltalk, Objects and Design. Capítulo 9: When (not) to inherit

Objetos mutables vs. Inmutables1. Ensaye una definición de inmutabilidad de los objetos2. ¿Cómo considera a las siguientes clases? ¿Cómo las considera Smalltalk?:

a) Symbolb) Stringc) MonetaryUnitd) Datee) 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 Desarrollo2. Paradigma y Modelo Computacional3. Paradigma de Orientación a Objetos

3.1. Programa3.2. Objeto3.3. Mensaje3.4. Colaboraciones3.5. Protocolo3.6. Colaboradores (Internos y Externos)3.7. Método3.8. Polimorfismo y Binding Dinámico3.9. Creación de Objetos

3.9.1. Clases3.9.2. Prototipos

3.10. Destrucción de Objetos3.10.1. Automática3.10.2. Manual

3.11. Mecanismos de Sharing3.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ón3.12.1. Clasificación (Clases Abstractas y Concretas)3.12.2. Subclasificación3.12.3. Protocolos en Distintos Niveles

4. Modelos Básicos con Objetos4.1. Magnitudes4.2. Lógica Booleana4.3. Contextos de Ejecución4.4. Colecciones

5. Aplicaciones Orientadas a Objetos5.1. Definición de Aplicación5.2. Paradigmas Model-View-Controller y Morphic5.3. Mecanismos de Observación

5.3.1. Dependencias5.3.2. Eventos

6. Concepto de Tipo en la Orientación a Objetos6.1. Revisión de TAD6.2. Aserciones y Contratos6.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. 2nda 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”. Ob-ject-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

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

Grupos y Listas de SmalltalkSmalltalk Archive at the University of Illinois st-www.cs.uiuc.eduRecursos de Smalltalk iamwww.unibe.ch/~scg/Resources/Smalltalk/index.htmlClubSmalltalk http://groups.google.com/group/clubSmalltalkSUGAR (Smalltalk User Group of Argentina) www.sugarweb.comSmalltalking www.smalltalking.netPaper fundacional de Squeak users.ipa.net/~dwighth/squeak/oopsla_squeak.html

SmalltalksPharo http://www.pharo-project.org/home VisualWorks www.cincomsmalltalk.comVisualAge Smalltalk http://www.instantiations.com/VAST/index.htmlDolphin Smalltalk http://www.object-arts.com/Squeak www.squeak.orgSqueak Swiki minnow.cc.gatech.edu/squeak

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


http://www.sunlabs.com/research/self

http://www.minnow.cc.gatech.edu/squeak

http://www.squeak.org/

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

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

http://www.cincomsmalltalk.com/

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

http://www.smalltalking.net/

http://www.sugarweb.com/

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

http://iamwww.unibe.ch/~scg/Resources/Smalltalk/index.html

http://www.well.com/user/ritchie/oo.html


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 PirovanoAv. Monroe 3555. Capital Federal. Tel. 4542-5552 / 9279

INTOXICACIONES :



Hospital de Niños Dr. R. GutiérrezSánchez de Bustamante 1399. Capital Federal. Tel. 4962-6666.

Hospital de Niños Dr. P. de ElizaldeAv. Montes de Oca 40. Capital Federal. Tel. 4307-7491 Toxicología 4300-2115

QUEMADURAS :Hospital de QuemadosPedro Goyena 369. Capital Federal. Tel. 4923-4082 / 3022

OFTALMOLOGÍAHospital Santa Lucía San Juan 2021. Capital Federal. Tel. 4941-7077

Hospital Dr. P. LagleyzeAv. Juan B. Justo 4151. Capital Federal. Tel. 4581-0645 / 2792

* Incendio:

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


guía de trabajos prácticos - dc.uba.ar · pdf fileprograma de la materia guia...

Documents