Introducci?n a la Programaci?n Orientada a Objetosmaterias.fi.uba.ar/7508/Teoria-2006-1c/OOIntro-2x.pdf · 75-08 Sistemas Operativos FIUBA Lic. Prof. Osvaldo Clúa -3-El paradigma

75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -1-

Facultad de Ingeniería

Universidad de Buenos

Aires

75-08 Sistemas OperativosLic. Ing. Osvaldo Clúa


Programa

� 1) Introducción. Tipos Abstractos de Datos. Ventajas de la orientación a objetos.

� 2) Clases y Objetos. Conceptos generales. Visibilidad Herencia. Modelado de la herencia.

� 3) Herencia múltiple e Interfaces. Polimorfismo. .


El paradigma de la Orientación a Objetos

� Las metodologías estructuradas no resolvieron el cuello de botella del mantenimiento.� Las técnicas clásicas son orientadas a operaciones o

a datos, pero no a ambos.� Esto se ve en los menús clásicos de los sistemas de

esa época.� La orientación a objetos da igual importancia a los

datos que a las operaciones.


Definición de las operaciones

� Ingeniería de código� Pre y Post condición con sus formalismos ( Hoare o Floyd).� Variantes e invariantes de algoritmos.� Cifras de mérito (acople y cohesión).

� Para el usuario de la operación solo es necesario conocer los estados anterior y posterior de la operación.

� Los algoritmos deben permanecer ocultos al usuario de la operación.


Definición de los Datos� Encapsulado de datos

� Se conoce su diagrama de estados.� Se conoce el efecto de cada operación en función de su

diagrama de estados.� Ingeniería de Código

� Estructuras estáticas, dinámicas y genéricas.� Persistencia, seguridad, coherencia.

� El usuario no precisa conocer los detalles de la implementación de los datos.


Tipo Abstracto de Datos (TAD)

� Estructura y operaciones en la misma construcción de programación.� Una parte expuesta: operaciones y cambios de

estados producidos.� Una parte oculta: la implementación de datos y

operaciones.� Este principio se conoce como Ocultamiento

de la Información (Information hiding - Parnas).


Operaciones sobre los TAD

� Las operaciones sobre un TAD pueden clasificarse como:� Construcción de una nueva instancia del TAD� Producción de un TAD a partir de otro u otros.� Mutación del estado de un TAD.� Observación del estado de un TAD.

� Es buena ingeniería de código que las operaciones sean de un solo tipo.


Invariantes de Representación

� El comportamiento de un TAD es independiente de su representación (Invariante de representación).

� Su desarrollo histórico abarca:� Built-in types (integer, boolean ...) El compilador

controla las operaciones que se pueden hacer sobre ellos.

� User defined types (Wirth). Permiten al programador definir tipos en función de tipos ya existentes.

� Abstract Data Types. Juntan la definición del tipo con sus operaciones en una misma construcción del lenguaje.


Función de Abstracción� El conjunto de valores que debe soportar un tipo

de datos se conoce como valores abstractos. � Sigue un desarrollo histórico paralelo al del

invariante de representación. (Built-in, User defined, TAD).

� La función de abstracción relaciona los valores abstractos con los reales de TAD.


Especificación de un TAD

� Invariante de Representación: Indica si un TAD está bien formado.� Permite un razonamiento modular acerca del TAD.

� Conviene escribirlo, aunque sea informalmente. De los contrario deben leerse todas las operaciones para entender un TAD.

� Función de representación: indica como un determinado valor del TAD se corresponde con un valor abstracto.� A veces el esfuerzo de escribirla no ayuda demasiado al diseño.


Orientación a Objetos� Hay Orientación a Objetos cuando hay:

� Tipos Abstractos de Datos.� Herencia.� Polimorfismo.

� Se llaman Basados en Objetos los lenguajes que solo soportan los TAD.

� Los TAD se llaman Clases.� Las Instancias de las Clases se llaman Objetos.� Las operaciones se llaman Métodos.


Relaciones entre las Clases

� Uso de un objeto de una clase (servidor) por parte de un objeto de otra clase (cliente).

� Composición (agregación) de clases para crear una nueva. (has_a).

� Generalización o especialización de las clases. (is_a).


Relación de Uso� El diagrama de la Relación de Uso puede tener una

forma de:� Árbol.� Capas.� Ciclos.

� Conocer un diagrama de uso permite:� Hacer un análisis de Impacto de un cambio.� Identificar oportunidades de reuso de código.� Determinar un orden de construcción.


Reuso

� Se pensó que la cohesión funcional permitiría el reuso. Sin embargo los módulos del modelo clásico no eran autocontenidos.

� La cohesión de un TAD u Objeto bien diseñado se conoce como Informacional.

� Si el TAD modela correctamente todos los aspectos de una entidad (real o abstracta) y oculta los detalles de su implementación, hace mas fácil su reuso.


Casos de Reuso

� Puede haber Reuso del Diseño, Reuso de la Implementación o situaciones intermedias. � Design patterns: Los patrones son soluciones generales a

problemas recurrentes. Dan una guía para el desarrollo de las relaciones entre objetos.

� Architecture: describe la estructura de la estructura de una aplicación. Da una guía para el desarrollo global de la aplicación.

� Framework: Se reusa la lógica de control de un diseño. El desarrollador solo se ocupa de las operaciones específicas del producto a construir (hot spots).

� Component: se basa en desarrollar clases que luego se integren a una Arquitectura por medio de un Framework.


Atributos y métodos

Atributos, Variables de Instancia, Miembros de datos, campos.

Class Fraccion {private int numerador;private int denominador;public Fraccion (int num, int den){…}public int getNum(){…}public int getDen(){…}

}

Métodos, Miembros funcionales, Mensajes.


Atributos

� Conservan el estado de un objeto.� Variables de instancia (cambian con cada

objeto).� Variables de clase (tienen el mismo valor para

todos los objetos).� Convención Java: se escriben con la primer

letra en minúscula.� Constantes.

� Convención Java: se escriben todo en mayúscula.


Atributos

• static� Es la forma de

indicar que se mantiene su valor para toda la clase.

• final� Es la forma de

indicar que es inmutable.

Public class Ejemplo{

private int variable_de_instancia;

private static int variable_de_clase;

public static final int CONSTANTE=360;

. . .

}


Métodos

� Son los que hacen las operaciones.� Construcción de un Objeto.� Mutación del estado de un objeto.� Producción de un Objeto a partir de otro.� Observación del estado de un objeto.

� Pueden ser de instancia o de clase.� Se invocan en el ambiente de un objeto o de

una clase.


Ambiente de miembros(Scope)

� Los miembros deben denotar el ambiente de un objeto.

� Si se trata de un elemento estático deben incluir el ambiente de la clase.

…

Fraccion f1=new Fraccion (6,8);

Fraccion f2=new Fraccion (7,5);

int i1= f1.getNum();

Fraccion f2= Fraccion.max(f1,f2);

getNum no es estático, se invoca en ambiente de f1.

max es estático, se invoca en ambiente de Fraccion .


Herencia

� Es una forma de obtener nuevas clases a partir de clases existentes.� Super Clase y Sub Clase.

� Una SubClase adquiere todos los métodos de la SuperClase (herencia).

� Puede cambiar alguno de los métodos heredados (especialización).

� Puede agregar nuevos campos o métodos (extensión).


Herencia en UML

� UML es un lenguaje de modelado.� La herencia es una

característica de la Programación OO.

� UML no modela la herencia sino la relación que le da origen.SubClase.

SuperClase.

Relación is_a (generalización).


Herencia en Javapublic class Fraccion{

private int num;private int den;Fraccion (int n, int d){..} . . .}

public class FraccionOper extends Fraccion {

FraccionOper(){super();}

public FraccionOper mas(Fraccion f){. . .}

}

�SuperClase.

�La SubClase extiende a la SuperClase.

�Se llama al constructor de la SuperClase.

�Toda FraccionOper es una Fraccion.


Visibilidad de los miembros

• protected indica que el miembro es accesible solo a los de su clase y a sus descendientes.

� Las clases se agrupan en paquetes (package )� Si no se pone modificador de visibilidad, los

miembros son accesibles a todas las clases del mismo paquete.

� Los paquetes se definen durante el Design

Workflow del USDP (Unified Software Development Process ).


Sobre la noción de herencia

� Es un ejemplo de programación incremental.� R=P+�R.� �R puede extender, heredar, cancelar o

especializar propiedades de P.� Es una forma de reusar código.� Modela una relación entre clases.


¿Qué relaciones se modelan usando la herencia?

� Especialización/generalización.� Relación is_a.

� Ejemplificación/clasificación.� Relación is_a pero abstracta.

� Descomposición/Agregación.� Relación has_a.

� Agrupamiento/individualización.� Relación is_a arbitraria.


Relaciones modeladas por Herencia

Vehículo

Bicicleta Automóvil

Autos vendidos

Auto de María

Auto de Luis

Auto

Motor Chasis

Generalización/

Especialización

Clasificación/

Ejemplificación

Agregación/

Descomposición

Auto

Auto de María

Autos azules

Autos blancos

Auto de Luis

Auto de Alberto

Agrupamiento/

Individualización


Clases y el USDP

� El USDP se compone de un conjunto de Actividades (Workflow).

� Las clases se �extraen� durante el Analysis

Workflow.� Essential classes.� Boundary classes.� Control classes.

� El Analysis Workflow produce un diagrama de clases que realizan los casos de uso.


Herencia y paquetes en el USDP

� El diagrama se refina durante el Design Workflow.

� Se introducen las restricciones del lenguaje de programación.� Se decide que relaciones se modelan con la

herencia.� Se asignan formatos y métodos a las clases.� Se definen la visibilidad y la partición en

paquetes.


Herencia múltiple.

Class Fraccion {private int numerador;private int denominador;public Fraccion (int num, int den){…}public int getNum(){…}public int getDen(){…}

}

Class Ordenable {public boolean esMayor(Ordenable a){…}public boolean esIgual(Ordenable a){…}

}

Class Operable {public Operable mas(Operable a){…}public Operable menos (Operable a){…}

}

�¿De que clase conviene hacer descender a la clase Fraccion?� Ambas candidatas son útiles (sirven de base para algoritmos).� Java no admite herencia múltiple.� ¿Cómo definir un método si aún no se conoce su implementación?� ¿Cómo usar solo una parte de una clase?


Herencia y Contratos

� El diseño indica que relación debe modelar la herencia.

� La SuperClase puede usarse para obligar a las subclases a implementar un método (Contrato).� Pero aun no se conoce como implementar el

método.� Se pueden hacer entonces clases abstractas

(Java).


Clases Abstractas (Java)

� Se diseñan únicamente para ser SuperClases.� Pueden tener métodos enunciados y sin programar

(métodos abstractos).� Pueden tener variables de instancia y métodos

programados.� No pueden instanciarse (no existen objetos

derivados de clases abstractas).� Pueden usarse como parámetros.� Las SubClases deben programar los métodos

abstractos.


Interface (Java- Ada 2005)

� Es un contrato para programar ciertos métodos.

� Las clases pueden implementar una o varias interfaces.

� No pueden tener datos ni métodos programados ni static.

� Es una solución al problema de la falta herencia múltiple en Java.


¿Interfaces o Clases Abstractas?(Java – Ada 2005)

� Una interface:� Define el borde de comunicación entre dos clases.� Se refiere a una abstracción que una entidad provee de sí

misma al exterior.� Las distintas clases que implementan una interface

comparten un protocolo.� Las clases abstractas:

� Permiten implementaciones parciales.� Permiten poner la funcionalidad en el nivel

correspondiente.� Se decide en el Design Workflow del USDP.


Polimorfismo (Java)

class PoliA extends Poli{

String uno(){

return “uno() de PoliA “;}

}

Class Poli{

String uno(){

return “uno() de Poli “;}

class PoliB extends Poli{

String uno(){

return “uno() de PoliB “;}

}

class Util{

. . .

static String uso (Poli p){

return p.uno();}

}

. . .

System.out.println(

Util.uso(new PoliA() );

¿Cuál es el usado?


Polimorfismo (C++)#include <iostream>using namespace std;

class Poli{

public:

virtual void a(){cout<<"Metodo a(), Poli"<<endl;}

};

class Uno :public Poli {

public: void a(){cout<<"Metodo a(), Uno"<<endl;}

};

class Dos: public Poli{

public: void a(){cout<<"Metodo a() de Dos"<<endl;}

};

class Uso {

public:

void usa(Poli &x){x.a();}

};

int main(){

Poli p;

Uno u; Dos d;

Uso s;

cout<<"s.usa(p) "; s.usa(p); cout<<"s.usa(u) "; s.usa(u);

cout<<"s.usa(d) "; s.usa(d);

}


Polimorfismo (Ada 95) apackage polis is

type Poli is tagged recordnull;end record;

procedure a(p:Poli);

type Uno is new Poli withrecord null;end record;

procedure a (u:Uno);

type Dos is new Poli withrecord null;end record;

procedure a (d:Dos);end polis;

with Ada.Text_IO, Ada.Integer_Text_IO;use Ada.Text_IO, Ada.Integer_Text_IO;

package body polis isprocedure a(p:Poli) isbegin

put_line("Metodo a(p) de Poli");end;procedure a(u:Uno) isbegin

put_line("Metodo a(u) de Uno");end;procedure a(d:Dos) isbegin

put_line("Metodo a(d) de Dos");end;

end polis;


Polimorfismo (Ada 95) bwith Ada.Text_IO, Ada.Integer_Text_IO,polis;use Ada.Text_IO, Ada.Integer_Text_IO,polis;

procedure prueba is procedure usa(p: Poli'class) is -- ~~~~~ esto implica polimo rfismobegin

a(p);-- en ada 2005 p.a;end usa;

p:Poli;u:Uno;d:Dos;begin

put ("usa(p:Poli) ");usa(p);put ("usa(u:Uno) ");usa(u);put ("usa(d:Dos) ");usa(d);

end prueba;


Polimorfismo

� Principio de sustitución de Liskov.� Una clase puede reemplazarse por sus

SubClases sin alterar su corrección.� La habilidad de objetos de diferente clase

de responder a métodos del mismo nombre de acuerdo a su clase.

� El programador no tiene porque conocer el tipo de objeto por anticipado.� Run-time binding.


Polimorfismo en los Lenguajes

� En Java todo método es polimórfico.� En C++ los métodos polimórficos deben

declararse como virtual.� En Ada los parámetros polimórficos deben

marcarse como de ámbito de clase.� Estas diferencias se deben a la

implementación de estos lenguajes.


Polimorfismo vs Programación Genérica

� Polimorfismo� Uso algorítmico de

sub-clases intercambiables

� Conocido como polimorfismo de subtipos.

� Programación Genérica� Acepta argumentos de

diversos tipos no relacionados.

� Conocida como polimorfismo paramétrico.


Orientación a Objetos

� TAD+Herencia+Polimorfismo.� Con estos elementos pueden diseñarse:

� Programas extensibles brindando �clases bases� que el programador extiende (hereda), reusando código y datos.

� Algoritmos con �hot spots� donde el programador pone sus clases, reusando la lógica.

� Clases pre-diseñadas con protocolos de comunicación ya establecidos que el programador integra a su código.

� �Documentos� donde el programador puede desplegar sus objetos e interactuar con otros.


Bibliografía

� Una cartilla de referencia rápida a UML se encuentra en http://www.holub.com/goodies/uml/

� El libro mas sucinto de Java es �Java Precisely� de Peter Sestoft, MIT Press, 2005. Hay edición anterior en la web.

� El Unified Developing Process, USDP o Unified Process está detallado en �Software Engineering, an Object-oriented Perspective� de Eric Braude, Wiley, 2001.

� El principio de sustitución de Liskov está en http://reports-archive.adm.cs.cmu.edu/anon/1999/CMU-CS-99-156.ps

� Una introducción a Ada puede encontrarse en http://www.adaic.org/learn/index.html


Bibliografía

� El tratamiento semi-formal es del curso 6-170 del MIT �Laboratory in Software Engineering, Fall 2005� online en el OCW del MIT http://ocw.mit.edu/

� La introducción al reuso y la orientación a objetos es del libro de Stephen Schach �Object Oriented & Classical Software Engineering� 6TH Edition, Mc Graw Hill

Introducci?n a la Programaci?n Orientada a Objetosmaterias.fi.uba.ar/7508/Teoria-2006-1c/OOIntro-2x.pdf · 75-08 Sistemas Operativos FIUBA Lic. Prof. Osvaldo Clúa -3-El paradigma

Documents