Iagp 4

Programacin Orientada a Objetos
Desarrollo de software orientado a objetos

Definicin
Mtodo de desarrollo de software que basa la arquitectura del sistema en mdulos deducidos de los tipos de objetos que se manipulan, en lugar de basarse en la funcin o funciones a las que el sistema est destinado a asegurar. No preguntes primero qu hace el sistema, pregunta A QUIN LO HACE!!
IAGP 1

2.1 Orgenes
El tiempo transcurrido entre el desarrollo convencional del software y el desarrollo orientado a objetos, no se solapa. Hay ms de 25 aos, surgi con el lenguaje Simula, en Noruega, aunque comercialmente se ha difundido recientemente. Simula es acrnimo de simulacin lenguaje y fue creado para soportar simulaciones, por O. J. Dahl yKristen Nygaard. Su propsito fue la simulacin de sistemas fsicos complejos con muchos cientos de componentes. En Simula los mdulos no se basan en procedimientos como en la programacin convencional, sino en los objetos fsicos que se modelan en la simulacin.
IAGP 2

Los objetos del mundo real pueden exhibir una variedad infinita de efectos sobre otros, creando, destruyendo, levantando, uniendo, comprando, doblndose, enviando, etc.
Esta gran variedad suscita un problema: Cmo se pueden representar en software las diversas clases de interacciones ? Los autores de Simula lograron una solucin elegante a este problema: el mensaje. Los objetos interaccionan el uno con el otro con mensajes que piden que los objetos realicen sus mtodos. Un mensaje es simplemente el nombre de un objeto seguido por el nombre de un mtodo que el objeto sabe ejecutar. Si un mtodo requiere alguna informacin adicional para saber qu hacer, el mensaje incluye la informacin como parmetros.
IAGP 3

El objeto que inicia un mensaje se llama el remitente de ese mensaje, y el objeto que recibe el mensaje se llama el receptor.
El hecho de que los mtodos estn asociados siempre a objetos especficos tiene un efecto secundario interesante que resulta ser ventajoso. Diversos objetos pueden responder al mismo mensaje genrico, pero cada objeto puede interpretar el mensaje de una manera distinta. Por ejemplo, un objeto camin podra poner en ejecucin su propia versin del mensaje mueve_A, al igual que una nave, un tren, un avin, una persona, o cualquier cosa que se mueva. En el mundo real la manera en que estos objetos determinan sus rutas, planean sus movimientos, y realizan estos desplazamientos se diferencia radicalmente, pero todos entenderan una peticin comn de ir a un IAGP 4 destino especificado.

La capacidad de diversos objetos para responder al mismo mensaje de diversas maneras se llama polimorfismo, que en griego significa "muchas formas."
El trmino puede intimidar, y el polimorfismo a menudo se considera un concepto avanzado en tecnologa de objetos. Pero la idea bsica no poda ser ms simple: cada objeto puede tener una respuesta nica al mismo mensaje. A veces, una simulacin implica solamente un ejemplo de una clase particular de objeto. Sin embargo es mucho ms comn, necesitar ms de un objeto de cada tipo. Esta posibilidad levanta otra preocupacin: sera extremadamente ineficaz redefinir los mismos mtodos en cada ocurrencia de ese objeto.
IAGP 5

Aqu, otra vez, los autores de Simula aportaron una solucin elegante: la clase.
Una clase es una plantilla de software que define los mtodos y las variables que se incluirn en un tipo particular de objeto. Los mtodos y las variables que hacen el objeto se definen solamente una vez, en la definicin de la clase. Los objetos que pertenecen a una clase se llaman generalmente instancias de la clase y contienen solamente sus propios valores particulares para las variables. Un programa orientado a objetos (poo), se define de la forma: Objetos + Mensajes = Programa
IAGP 6
IAGP

La programacin orientada a objetos, se dice a menudo que es ms natural que la programacin tradicional, y es verdad en dos niveles.
En un nivel, la POO es ms natural porque permite que organicemos la informacin de la forma que nos es familiar, segn lo ilustrado en las jerarquas de las clases. En otro nivel ms profundo, es ms natural porque refleja tcnicas propias de la naturaleza para manejar complejidad.
Es interesante fijarse en la estructura de organismos vivos para establecer un marco para entender la naturaleza adaptativa de los objetos.
IAGP
Programa OO
Clase Objeto
Coleccin estructurada de clases Implementacin de un TAD
Una instancia de una clase
Los objetos se comunican mediante mensajes

IAGP 9

2.2 Comparacin con los seres vivos
El bloque de edificio bsico a partir del cual se componen los seres vivos es la clula. Las clulas son "paquetes orgnicos", como objetos, combinan la informacin relacionada y comportamiento.
La mayora de la informacin est contenida en molculas de protena, dentro del ncleo de la clula. El comportamiento, que puede extenderse desde conversin de energa al movimiento, es realizado por estructuras fuera del ncleo.
Las clulas estn rodeadas por una membrana que permite solamente ciertas clases de intercambios qumicos con otras. Esta membrana protege el funcionamiento interno de la clula contra la intrusin exterior, y tambin oculta la complejidad, presentando un interfaz relativamente simple al resto del organismo.
IAGP 10

Todas las interacciones entre las clulas ocurren a travs de los mensajes qumicos, reconocidos por la membrana de la clula y pasados a su travs al interior de la clula.
IAGP
11

Los objetos que contienen a otros, se llaman objetos compuestos, son importantes porque pueden representar estructuras ms sofisticadas que los objetos simples. Un avin consiste en alas, motores, y otros componentes que son demasiado complejos para representarlos de forma simple. Colecciones de objetos Hay una clase especial de clases, a menudo llamada la coleccin de clases, que se puede encontrar en la biblioteca de clases en la mayora de los lenguajes comerciales. Como el nombre sugiere, la funcin bsica de una coleccin es recolectar juntos los objetos que se deben manejar como grupo.
IAGP
12

En un avin, por ejemplo, no crearamos una variable separada para cada objeto del asiento, agruparamos todos los objetos del asiento en una coleccin y pondramos una referencia a esa coleccin en un solo conjunto llamado variable.
IAGP
13

Aunque los mecanismos reales de clulas y de objetos apenas podran ser ms diferentes, sus funciones son similares. Las clulas y los objetos encapsulan datos y comportamientos asociados; ambos tienen interfaces que definen qu seales respondern a su ambiente; ambos utilizan la comunicacin basada en mensajes para ocultar complejidad; ambos se pueden organizar en una jerarqua de tipos especializados; y ambos proporcionan los bloques de edificio fundamentales para construir una variedad infinita de sistemas complejos. Esta semejanza, considerando la gran variedad de organismos vivos, demuestra claramente la flexibilidad de este acercamiento bsico a a la construccin de sistemas complejos.
IAGP 14

La naturaleza, despus de todo, ha estado utilizando el acercamiento algunos miles de millones de aos ms que los diseadores del software! Anatoma de los componentes de un mensaje
Un mensaje consiste de tres partes:

Un objeto receptor Un mtodo que el receptor sabe ejecutar Un conjunto de parmetros que el mtodo requiere para realizar su funcin
IAGP
15

Respuestas a los mensajes En la mayora de los sistemas, los mensajes requieren una cierta clase de respuesta del receptor. Esta respuesta es generalmente llamada valor de retorno, puede ser datos simples, valores u objetos.
IAGP
16

La potencia de los polimorfismos, simplificacin de programas Supnganos que estamos desarrollando un sistema que incluya instrumentos financieros tales como bonos y acciones. El sistema debe permitir que realicemos una variedad de operaciones tales como aadir una nueva accin, seguir el funcionamiento de varias clases de instrumentos, y supervisin del valor actual de la cartera en su totalidad. Nuestra primera clase es cartera, un objeto compuesto que contiene un objeto de la coleccin de objetos llamada instrumentos_financieros. Nuestro primer mtodo es agregar, que toma un objeto instrumento financiero como su parmetro.
IAGP 17
IAGP
18

2.3 Modularidad
Modularidad
Extensibilidad + Reutilizacin necesidad de arquitecturas flexibles hechas con componentes autnomos Programa modular: formado por un conjunto de mdulos Mdulo: unidad bsica de descomposicin de un sistema software Un mtodo de construccin de software es modular si ayuda a producir sistemas software a partir de elementos autnomos interconectados por una estructura simple y coherente.
IAGP 19
Modularidad: 5 criterios
Cinco criterios, cinco reglas, cinco principios.
Requisitos que debe satisfacer un mtodo de construccin de software para merecer el nombre de modular:
Permitir una descomposicin modular
Permitir una composicin modular

Producir mdulos fciles de comprender Favorecer la continuidad del software Proteccin modular
IAGP 20
Descomposicin modular
Un mtodo de construccin de software satisface la descomposicin modular si permite la descomposicin de un problema en un pequeo nmero de subproblemas menos complejos, conectados por una estructura simple, y que se pueden abordar por separado.
Importante que las dependencias sean mnimas y que se conozcan. Ejemplo: Diseo Descendente Contra-ejemplo: Mdulos de Inicializacin
IAGP 21
Composicin modular
Un mtodo satisface la composicin modular si favorece la produccin de elementos software que pueden ser combinados para crear nuevos sistemas, posiblemente en un entorno diferente a aquel en el que se idearon.
Relacionada con el objetivo de reutilizacin
Independiente de la descomposicin modular

Ejemplos: Libreras de rutinas, Filtros de Unix Contra-ejemplo: Preprocesadores de lenguajes
IAGP 22
Comprensin Modular
Se satisface si facilita que quin lea un mdulo pueda comprenderlo sin necesidad de acudir a otros mdulos (en el peor de los casos a unos pocos mdulos). Relacionado con el mantenimiento Contra-ejemplo: Dependencias secuenciales
IAGP
23
Continuidad Modular
Un mtodo satisface la Continuidad Modular si se favorecen arquitecturas software en las que un cambio pequeo en la especificacin origina un cambio en un solo mdulo, o en un pequeo nmero de mdulos.
Relacionado con la extensibilidad Ejemplos:

Constantes simblicas y Principio de Acceso Uniforme
Contra- ejemplos:
Diseo de programas basado en la representacin fsica de los datos y el uso de vectores estticos
IAGP 24
Proteccin Modular
Un mtodo satisface la Continuidad Modular si se originan arquitecturas en las que el efecto de una condicin excepcional acaecida en tiempo de ejecucin slo afecta al mdulo dnde se produce, o slo se propaga a los mdulos vecinos.
Relacionado con la robustez Ejemplo: Mdulos de entrada de datos comprueben su validez. Contra-ejemplo: Excepciones no disciplinadas.
IAGP
25
Modularidad: 5 reglas
De los criterios anteriores se derivan cinco reglas que se deben seguir para asegurar la modularidad
Correspondencia directa Pocas conexiones entre mdulos Intercambio de informacin intermodular mnimo Conexiones explcitas Ocultamiento de Informacin
Las cuatro ltimas se refieren a la comunicacin entre mdulos: uso o comparticin de datos
IAGP 26

2.4 Otras consideraciones
Impacto de la POO
Desarrollo ms rpido. Mantenimiento barato Proceso de modelado ms simple Diseos ms claros y manejables Incremento productividad de programadores Inconveniente: Curva de aprendizaje
Diseo con objetos diseo procedural
IAGP Libreras bien diseadas y fciles de usar 27
Abstraccin y modelado
Modelado del problema: Proceso de abstraccin Lenguajes O.O.: Representa elementos del marco del problema a resolver Cdigo (solucin): descripcin del problema Objetos: Tienen su estado y pueden realizar operaciones
IAGP 28
Caractersticas de la O.O.
Todo es un objeto (alumno, factura, polgono) Programa: Conjunto de objetos. Se envan mensajes para decirse qu deben hacer Objetos pueden estar compuestos por otros Cada objeto es de un tipo (instancia de clase) Objetos de un mismo tipo pueden recibir los mismos mensajes
IAGP 29
Interface de un objeto
Elementos del problema: Entidad (Objeto) Objeto: Pertenece a una clase.
Define sus caractersticas y comportamiento
POO crea nuevos tipos e instancia los objetos necesarios de esos tipos modelado: Mapeo 1 a 1 Problema Solucin Tipo: Interface. Informa de las peticiones que se pueden hacer a objetos de ese tipo
IAGP 30
Encapsulacin
Programador: Dos puntos de vista
Crear clases Crear clientes de esas clases
Slo muestra lo necesario para quien programa clientes. Oculta el resto Interface Qu solicitudes puedo hacer? Implementacin: Realizacin de las tareas de la interface Envo de mensajes (ejecucin de un mtodo) IAGP 31
Tipos Abstractos de Datos

Conjunto de objetos que ofrecen una serie de operaciones Abstracciones matemticas:
No se menciona cmo se implementan las operaciones
Java permite la construccin de TAD's Mecanismos para la ocultacin de detalles de implementacin

IAGP 32
Si se modifica la implementacin:
El programa que usa el TAD no se modifica Slo cambian los mtodos del TAD Cambios transparentes al resto del programa
Operaciones soportadas por el TAD:

Decisin de diseo (Programador del TAD)
Ejemplos: Listas, conjuntos, grafos, ...
IAGP
33
Control de acceso
Disponibilidad de mtodos. Razones:
El cliente no necesita ver lo que no le afecta (simplicidad) Modificaciones en la implementacin sin afectar a la interface Cliente no afectado
Niveles de acceso a miembros:

public, private, protected: Quin puede hacer uso
IAGP 34
C l a s e S u b c l a s eP a q u e t e T o d o s
p r i v a t e p r o t e c t e d p u b l i c
S I S I S I S I S I * S I S I S I S I S I
p a c k a g e
IAGP
35
Reutilizacin
Uso habitual: Instanciar un objeto de una clase Composicin: Relacin "tiene un" (has-a)
Clases que contienen objetos de otras clases (member object) Objetos miembro: Privados si no son necesarios en la interface
Herencia: Relacin "es un" (is-a)

Modificacin (especializacin) de una clase ya IAGP 36 existente
Herencia
Evita crear tipos (clases) nuevos por necesidad de similar funcionalidad El nuevo tipo es un duplicado del otro con aadidos y/o modificaciones Modificaciones en la clase original afectan a la clase hija Herencia: Es realmente necesaria?
Composicin mucho ms habitual
IAGP 37
Herencia: Subclases
Nuevo tipo. Contiene todos los miembros del anterior Los miembros privados son inaccesibles Duplica el interface de la original. Es del mismo tipo que la clase base Formas de modificar la nueva clase:
Aadir nuevos mtodos Cambiar el comportamiento de un mtodo (override)
IAGP 38
Herencia: Polimorfismo
Objetos de clases derivadas se pueden tratar como de la clase base Permite cdigo independiente del tipo.
Fcil de escribir y entender
Al aadir nuevos tipos:

No hay que reescribir cdigo Programas extensibles
IAGP
39
Ejemplos:
Polimorfismo:
Mensaje a un objeto de tipo desconocido. Se ejecuta el mtodo correcto No hay que especificarlo (en C++ virtual)
Upcasting (Conversin a superclase)

Ej. Figuras geomtricas
Enlace dinmico.
Ej. Trabajadores y nminas
IAGP 40
Clases abstractas
Subclases diferentes con un interface nico Slo se permiten objetos de subclases Mtodos abstractos (sin implementacin)
Slo en clases abstractas
Interfaces:
Impiden implementar cualquier funcin Slo declaraciones Herencia diferente a clases (herencia mltiple) Las subclases "implementan" interfaces IAGP 41
Declaracin de clases
<acceso> class <nombre> { <miembros> // "members" }
Miembros:
Atributos:
Variables de instancia, globales a la clase. Atributos de clase (informacin esttica, compartida)
Constructores. Cdigo de inicializacin Mtodos. Comportamiento.

IAGP 42
Constructores
Se garantiza la inicializacin de cada objeto (sus atributos) con un constructor Java invoca al constructor al crear el objeto La instanciacin (new) reserva el lugar de almacenamiento e invoca al constructor Nombre del constructor = nombre de la clase Se encargan de todas las operaciones de inicializacin necesarias.
IAGP 43
Constructor: No tiene valor de retorno Una clase puede tener mltiples constructores
Sobrecarga de constructores
public class Coordenada { double x, y; public Coordenada(){ x = 0.0; y = 0.0; } public Coordenada (double v1, double v2){ x = v1; y = v2; } }
IAGP 44
Constructor "por defecto". Sin parmetros. Clase sin constructor: El compilador crea un constructor "por defecto". Si hay constructores con argumentos, no se crea el "constructor por defecto". Ejemplo.
Error si se invoca el constr. sin parmetros
Constructores que invocan a otros constructores:

llamada a this(...). Ejemplo.
IAGP 45
La referencia this
Referencia al objeto actual. Permite invocar mtodos del objeto actual.
No es necesario this para hacer eso
Permite referenciar atributos del objeto actual

Necesario si estan ocultos por parmetros / variables de mbito ms local. Ejemplo.
Permite devolver una ref. al objeto actual Permite invocaciones entre constructores IAGP
46
La llamada a super
Referencia a la superclase de la que desciende la clase actual Reutilizacin de cdigo por medio de herencia
super invoca al comportamiento anterior.
Adems se puede aadir comportamiento adicional
Implcita en constructores como 1 instruccin IAGP 47 en mtodos: super.nombre_metodo()
Miembros de tipo static

Miembros (mtodos o atributos) implementados a nivel de clase Desde mtodos static la referencia this no tiene sentido No se puede acceder a miembros no estticos desde mtodos estticos static: Semntica de "mbito global"
Permite desarrollo de cdigo sin usar POO

IAGP 48

2.5 Lenguaje Smalltalk
Surge
en los aos 1970, en el Centro de Investigacin de Xerox en Palo Alto (PARC) en EE.UU.
Creado por Alan Kay, Adele Goldberg y Daniel Ingalls Influenciado por Simula y Lisp El objetivo del proyecto de Smalltalk es proporcionar soporte
informatizado para el espritu creativo
Lenguaje de descripcin (lenguaje de programacin) que

sirva como una interface entre los modelos mentales y los modelos en el ordenador, y adems un lenguaje de interaccin (interfaz de usuario) que traslade los sistemas de comunicacin humana a los ordenadores
IAGP 49

El sistema debera construirse con el mnimo n de partes
fijas y todas las partes deberan encontrarse en un marco uniforme.
Un lenguaje para ordenadores debera:

soportar el concepto de Objeto y proporcionar un medio uniforme para identificarlos. proporcionar un medio de clasificar los objetos y de crear nuevas clases con la misma base que las del ncleo. ser Independiente de la representacin (polimorfismo) factorizar comportamiento comn (herencia)
La ejecucin debera verse como una capacidad intrnseca de

los objetos que pueden ser invocados de manera uniforme mediante el envo de mensajes . IAGP 50
Para
que un lenguaje de desarrollo llegue a ser ampliamente aceptado deber ser estandarizado.
A finales de 1993 se cre el Comit para la estandarizacin de

Smalltalk X3J20.
El primer borrador aparece a finales de 1995

50% sintaxis/semntica y 50% Libreras de clases Fcil debido a la simplicidad del lenguaje Cdigo de aplicaciones muy portable
En 1995 se forma el STIC (SmallTalk Industry Council)

una voz unificada para la comunidad Smalltalk
IAGP 51

Los objetivos del STIC son:
Lograr que Smalltalk sea el LOO elegido para el desarrollo de

aplicaciones en la empresa
Responder a las necesidades de la industria Smalltalk Favorecer la aparicin de estndares Crear un punto de encuentro para la comunidad Smalltalk
http://www.stic.org Apuntes sobre Smalltalk:
http://www.um.es/informatica/alumnos/apuntes/tercero/poo/smalltalk.ppt
IAGP 52

2.6 Ejemplo
Polgonos y Rectngulos
Tenemos la clase Poligono y necesitamos representar rectngulos.
Debemos crear la clase Rectangulo partiendo de cero?
Podemos aprovechar la existencia de similitudes y particularidades entre ambas clases

IAGP 53

Un rectngulo tiene muchas de las caractersticas de un polgono (rotar, trasladar, vrtices,..) Pero tiene caractersticas especiales (diagonal) y propiedades especiales (4 lados, ngulos rectos) Algunas caractersticas de polgono pueden implementarse ms eficientemente
class Rectangulo inherit Poligono feature ...Caractersticas especficas para rectngulos end
IAGP 54

Iagp 4

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Iagp 4

Cargado por

Copyright:

Formatos disponibles

Programacin Orientada a Objetos

Desarrollo de software orientado a objetos

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Coleccin estructurada de clases Implementacin de un TAD

Una instancia de una clase

Los objetos se comunican mediante mensajes

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Un mensaje consiste de tres partes:

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Permitir una composicin modular

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Relacionada con el objetivo de reutilizacin

Independiente de la descomposicin modular

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Relacionado con la extensibilidad Ejemplos:

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Tipos Abstractos de Datos

Java permite la construccin de TAD's Mecanismos para la ocultacin de detalles de implementacin

Programacin Orientada a Objetos

Operaciones soportadas por el TAD:

Ejemplos: Listas, conjuntos, grafos, ...

Programacin Orientada a Objetos

Niveles de acceso a miembros:

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Herencia: Relacin "es un" (is-a)

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Al aadir nuevos tipos:

Programacin Orientada a Objetos

Upcasting (Conversin a superclase)

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Constructores. Cdigo de inicializacin Mtodos. Comportamiento.

Programacin Orientada a Objetos

Programacin Orientada a Objetos

Programacin Orientada a Objetos