Introduccion Poo Algo2

P.O.O.

Programación Orientada a Objetos

Contenidos 1.

Evolución del Software a) Programación No Estructurada b) Programación Estructurada c) Programación Orientada a Objetos

3.

Modularidad

4.

Problemas de la Programación Estructurada

5.

La POO como solución

6.

Modularidad en Java

Referencias


http://www.javaworld.com




http://java.sun.com







http://www.gamelan.com http://www.mindview.net/Books/TIJ/index_html http://ootips.org http://www.objectmentor.com/resources/publishedArt icles.html

Evolución del Software

Programación NO estructurada

Programación estructurada (o Procedimental)

Programación Orientada a Objetos

MODULARIDAD

4

Evolución del software

•

Programación No Estructurada

•

Programación Estructurada (Procedimental)

•

Programación Orientada a Objetos (POO)

Programación no Estructurada •

Un solo bloque principal

•

Típica de los lenguajes de bajo nivel

•

Variables globales a todo el programa

•

Problemas: 

Suelen contener secuencias de código repetidas



Cualquier modificación en el programa  revisar todo el software PROGRAMA

Programa Principal datos

Programación no estructurada

eti2:

eti1:

eti3: eti4:

Función noEstructurada1 escribir(“Teclea dos números: “); leer(a, b); si (b = 0) entonces saltarA(eti3) c2  1 da si (c2 < b) entonces c1  0 sino saltarA(eti4) fd d0 dd+f c1  c1 + 1 si (c1 < a) entonces saltarA(eti1) c2  c2 + 1 saltarA(eti2) d 1 escribir(d)

¿Alguna duda sobre por qué se le llama spaghetti code?

Programación no estructurada

eti2:

eti1:

eti3: eti4:

Función noEstructurada2 escribir(“Teclea dos números: “); leer(base, exp); si (exp = 0) entonces saltarA(eti3) cont2  1 resul  base si (cont2 < exp) entonces cont1  0 sino saltarA(eti4) factor  resul resul  0 resul  resul + factor cont1  cont1 + 1 si (cont1 < base) entonces saltarA(eti1) cont2  cont2 + 1 saltarA(eti2) resul 1 escribir(resul)

Evolución de los lenguajes de programación Función factorial escribir(“Teclea dos números: “); leer(base, exp); si (exp = 0) entonces resul1; sino principio resulbase; cont21; mientras (cont2 < exp) hacer Hay indentación y se principio evitan las etiquetas, factorresul; resul0; cont10; pero me sigue mientras (cont1 < base) hacer pareciendo poco principio legible resulresul + factor; cont1cont1 + 1; fin cont2cont2 + 1; fin escribir(resul); fin

Programación Estructurada •

También llamada procedimental

•

Variables globales, variables locales y parámetros

PROGRAMA

Programa Principal

Programa Principal datos

Procedimiento1 Procedimiento2 Procedimiento1

Procedimiento2

Procedimiento3

Procedimiento3

Programación Estructurada • Parte

del diseño top-down: descomponer los requerimientos del programa paso a paso, hasta llegar aun nivel que permite expresarlos mediante procedimientos y funciones.

M2

M5

M3

M6

TOP-DOW

abstracción

M1

M4

M7

M8

M9

Lo principal es identificar la funcionalidad que se desea programar y los datos necesarios para conseguirla

Programación estructurada Programa principal entero a, b, d; pedir_numero(a); pedir_numero(b); d=potencia(a, b); escribir(d); Función potencia (a: entero, b: entero): entero c: entero; c1 mientras(b>0) hacer principio cmultiplicar(a, c); bb-1; fin devolver(c);

tipo parámetro tipo resultado tipo variable local

¡ Se entiende !

Programación estructurada Función pedir_numero(): entero escribir(“Teclea un número: “); leer(a); devolver(a); Función multiplicar(a: entero, b: entero): entero c: entero; c0 mientras(b>0) hacer principio cc + a; bb-1; fin devolver(c);

Modularidad •

Agrupar en módulos los procedimientos con una funcionalidad común

•

Cada módulo puede contener sus propios datos

•

Ámbito de las variables PROGRAMA

Programa Principal datos

Módulo1 Datos + Datos1 Proced1

Módulo2 Datos + Datos2 Proced2

Proced3

Modularidad  Modulo: unidad elemental para desarrollar aplicaciones Funcionales: subprogramas Declarativos (datos + funcionalidad): TAD

 Modularidad: característica del Sw Una aplicación grande se compone de varios módulos Los módulos deben ser independientes En las aplicaciones se integrarán distintos módulos que se comunican entre sí Buen diseño  Separación de módulos

Modularidad Es conveniente separar la especificación del módulo y su implementación Especificación: declaración del conjunto de operaciones que se exportan (interfaz del módulo) Implementación: parte del módulo que recoge la estructura de los datos y la implementación de las operaciones. Queda oculta

¿Por qué modular las aplicaciones? Descomponer el problema en partes más simples Descomposición Modular Facilitar la comprensión del sistema y de cada una de sus partes Inteligibilidad

El sistema está compuesto de una serie de módulos independientes comunicados entre sí Composición Modular Las modificaciones debidas a cambios en la especificación afectan a un número reducido de módulos Continuidad Modular

Si se produce un error en un módulo, éste sólo afecta a dicho módulo Protección Modular

Programación Orientada a Objetos •

El término de Programación Orientada a Objetos indica más una forma de diseño y una metodología de desarrollo de software que un lenguaje de programación, ya que en realidad se puede aplicar el Diseño Orientado a Objetos a cualquier tipo de lenguaje de programación.

•

Toma en cuenta la programación estructurada, a la que engloba, dotando al programador de nuevos elementos para el análisis y desarrollo de Software.

Programación Orientada a Objetos Paradigma de programación que define los programas en términos de objetos. Objeto Entidad que combina: Estado: datos

Comportamiento: métodos (procedimientos y funciones) Identidad: propiedad que diferencia a cada objeto del resto Clase Generalización de un objeto particular. Una clase representa una familia de objetos concretos. Programa Conjunto de objetos que colaboran entre ellos para realizar tareas

Programación Orientada a Objetos Ejemplo:

OBJETOS

objeto2 color azul tipo policiaco matricula 0000 PM velocidadMax 250 objeto1 color rojo tipo deportivo matricula 1234 ABC velocidadMax 300

objeto3 color amarillo tipo elegante matricula 9876 DEF velocidadMax 150

objeto4 color rojo tipo utilitario matricula 9235 FCB velocidadMax 200

Programación Orientada a Objetos CLASE CLASE Coche

Agrupación de las características (atributos) y funcionalidad (métodos) de todos los coches color String tipo String matricula String velocidadMax real arrancar() parar() real acelerar()

Tipo de retorno real frenar() adelantar(pOtro Coche) …

Programación Orientada a Objetos •

•

Encapsula en “objetos” 

el Qué  Datos



el Cómo  Métodos (funciones)

Los objetos interactúan enviándose mensajes PROGRAMA

Objeto1 Datos1

Objeto2 Datos2 Objeto4 Datos4

Objeto3 Datos3

Características de los Objetos • Identidad del Objeto Aunque dos objetos sean exactamente iguales en sus atributos, son distintos entre si. • Clasificación Abstracción del concepto de objeto llamada clase • Mantenibilidad Un programa o sistema debe ser fácilmente modificable • Reusabilidad Los objetos definidos en un programa pueden ser extraídos e implantados en otro sin tener que realizar modificaciones importantes en su código

Características de los Objetos • Encapsulación y ocultación de datos La información dentro de un objeto puede ser: ٧ privada: información que necesita el objeto para operar. Es innecesaria para el resto de objetos ٧ pública: la necesitan el resto de objetos para interactuar con él La encapsulación es la capacidad de los objetos de construir una capsula a su alrededor ocultando la información que contienen, necesaria para su funcionamiento interno pero innecesaria para los demás objetos. Entrada

OBJETO

Salida

Características de los Objetos • Polimorfismo Posibilidad de definir varias operaciones con el mismo nombre, diferenciándolas en el número o tipo de los parámetros. Los lenguajes Orientados a Objetos permiten definir operadores con los mismos nombres en clases distintas; el programa reconoce a qué clase se aplica durante la ejecución. • Herencia Propagación de los atributos y operaciones a través de distintas sub-clases definidas a partir de una clase común. Esta característica se estudia en profundidad en un capítulo posterior.

Construcción de Clases Una clase describe un grupo de objetos con similares: • Propiedades (atributos) • Comportamientos (operaciones o métodos) • Relaciones con otros objetos Cada objeto «conoce» cuál es su clase. La mayoría de los lenguajes Orientados a Objetos pueden determinar a qué clase pertenece un objeto durante la ejecución del programa

Construcción de Clases Pasos para definir una clase: 1. Identificar los objetos  Los objetos deben imitar el mundo real  Cualquier propiedad de un objeto se identifica a través de atributos  Además de objetos físicos pueden ser entidades que se utilizan dentro de la construcción de un programa

2. Definir los atributos Un atributo recoge un valor que se almacenará en los objetos de la clase

3. Definir las operaciones.  Examinar las distintas operaciones asociadas a un conjunto de datos  Añadir la operación de construcción de objetos de la clase

Construcción de Clases (ejemplo) Ejemplo: Describir las clases de objetos necesarias para operar con fracciones CLASE Fraccion Atributos numerador: entero entero denominador: entero Métodos -constructorescribir() multiplicarPorEntero(pNum: entero): Fraccion sumar(pFracc: Fraccion): Fraccion 2

Comparación de la versión estructurada con la Orientada a Objetos para resolver un problema 1. Utilizando una Programación Estructurada 2. Utilizando una Programación Orientada a Objetos

Programación Estructurada vs. Orientada a Objetos

Especificación Tendremos varias formas en una ventana gráfica: un cuadrado, un círculo y un triángulo. Cuando el usuario pinche en una de las formas, ésta rotará 360º en el sentido de las agujas del reloj (es decir, hará una rotación completa) y tocará un sonido en formato AIF, específico para esa forma.

Programación Estructurada vs. Orientada a Objetos

Aitor Jon rotar (numForma) { // rotar la forma 360º } tocarSonido(numForma) { // usar numForma para // buscar el fichero AIF // a tocar y hacerlo sonar }

Cuadrado Círculo rotar(){ Triángulo // código para rotar C rotar(){ } // código para rotar C rotar(){ } tocarSonido(){ // código para // código para tocar tocarSonido(){// rotar el triángulo // sonido del Cuadr } tocar // código para } // sonido del Circulo tocarSonido(){ } // código para tocar // sonido del Triáng }

Programación Estructurada vs. Orientada a Objetos Añadido a la especificación original Habrá una nueva forma en pantalla, junto a las demás: una amoeba. Cuando el usuario pulse sobre la amoeba, ésta rotará como las otras, pero tocará un archivo .hif

Programación Estructurada vs. Orientada a Objetos

Aitor Jon Amoeba rotar (numForma) { // rotar la forma 360º } tocarSonido(numForma) { // si la forma no es amoeba // usar numForma para // buscar el fichero AIF // a tocar y hacerlo sonar // si no // tocar .hif de la amoeba }

rotar(){ // código para // rotar amoeba } tocarSonido(){ // código para // tocar sonido //.hif en amoeba }

Programación Estructurada vs. Orientada a Objetos

Punto de rotación de la amoeba en las versiones de Jon y Aitor:

Punto de rotación correcto para la amoeba

lo que al cliente se le olvidó citar...

Programación Estructurada vs. Orientada a Objetos Jon rotar (numForma, xPt, yPt) { // si la forma no es una amoeba // calcular punto de gravedad // rotar la forma 360º // si no // usar xPt,yPt como el punto // base de rotación } tocarSonido(numForma) { // si la forma no es amoeba // usar numForma para // buscar el fichero AIF // a tocar y hacerlo sonar // si no // tocar .hif de la amoeba }

Aitor Amoeba int puntoX int puntoY rotar(){ // código para rotar amoeba // usando puntoX,puntoY

} tocarSonido(){ // código para tocar // sonido .hif en amoeba

}

¿qué tienen las 4 clases en común?

Cómo diseña Aitor... 1 Cuadrado rotar()

Círculo

Triángulo

rotar()

tocarSonido() tocarSonido()

Amoeba

rotar()

rotar()

tocarSonido()

tocarSonido()

Forma rotar() tocarSonido()

2

abstracción y generalización

Cómo diseña Aitor... superclase

3

Forma rotar()

Unimos las 4 clases a la nueva clase Forma, formando una relación de HERENCIA

tocarSonido()

subclases Cuadrado

Círculo

Triángulo

rotar()

rotar()

rotar()

tocarSonido()

tocarSonido() tocarSonido()

Amoeba rotar() tocarSonido()

Conclusiones  Programación estructurada:

• Los datos y los procedimientos están separados y sin relación. • Presta atención al conjunto de acciones que manipulan el flujo de datos desde la situación inicial a la final. • Anima al programador a pensar sobre todo en términos de procedimientos y funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan.  Programación Orientada a Objetos

• Presta atención a la interrelación que existe entre los datos y las acciones a realizar con ellos.

Problemas de la Programación Estructurada • Modelo mental anómalo. Nuestra imagen del mundo se apoya en los seres, a los que designamos con nombres sustantivos, mientras que la programación clásica se basa en el comportamiento, representado usualmente por verbos. • Resulta difícil modificar y extender los programas, puesto que suele haber datos compartidos por varios subprogramas • Los programas son difíciles de mantener. Suelen tener errores ocultos que no surgen hasta después de muchas horas de funcionamiento • Es difícil reutilizar programas. Es prácticamente imposible aprovechar en una aplicación nueva las subrutinas que se diseñaron para otra • La coordinación y organización entre programadores para la creación de aplicaciones de envergadura es compleja

La POO como solución La Programación Orientada a Objetos constituye un nuevo paradigma de programación que trata de encontrar solución a los problemas mencionados. • Representación mucho más cercana a la realidad  Sistemas de software muy complejos se vuelven mucho más simples de comprender • En un sistema correctamente diseñado con OO es posible realizar cambios al nivel de la clases, sin tener que realizar cambios en ningún otro punto del sistema  Reduce el costo total de mantenimiento • El polimorfismo y la herencia  Favorecen la reutilización de componentes individuales • Muchos problemas pueden ser detectados y corregidos en la fase de diseño  Reducción del trabajo de revisión y mantenimiento del sistema

Aplicación OO: Gestión de un restaurante Buenas noches! Una mesa por favor

entero consultarOcupación RECEPCIONISTA

CLIENTE entero asignarMesa() Iñaki

Bautista

(1)

Tomaré crema de verduras y besugo (2)

anotarPedido(listaPlatos)

(3)

atenderCliente(Iñaki)

Antonio, acompaña al caballero a la mesa 2

cocinar (plato) Una crema de verduras y besugo

CAMARERO

cocinarPedido(listaPlatos)

COCINERO

(4)

Arzak

Antonio servir(unPlato) (5)

Marchando una crema de verduras

Tipos de Módulos a) Módulos de definición b) Módulos de servicio c)

Tipos Abstractos de Datos

d) Máquinas Abstractas de Estado

Tipos de Módulos a) Módulos de Definición • • • •

Declaración de constantes y variables Se declaran sobre clases abstractas Se declaran como estáticas Definiciones de constantes

b) Módulos de Servicio • Ofrecen un servicio • Agrupan un conjunto de operaciones • Las operaciones de la interfaz se declaran sobre clases no instanciables • Las operaciones son declaradas estáticas

Tipos de Módulos c)

Módulos de Abstracción de Datos • Representan TADs • Se definen el tipo de datos y sus operaciones • La implementación se realiza como una clase

d) Máquinas Abstractas de Estado (MAEs) • A diferencia de los TADs, las operaciones de una MAE se efectúan sobre un único objeto (la clase), no se pueden generar diferentes objetos del mismo tipo