Introducci?n a la Programaci?n Orientada a...
Transcript of Introducci?n a la Programaci?n Orientada a...
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
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -2-
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. .
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -3-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -4-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -5-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -6-
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).
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -7-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -8-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -9-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -10-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -11-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -12-
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).
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -13-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -14-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -15-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -16-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -17-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -18-
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;
. . .
}
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -19-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -22-
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 .
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -25-
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).
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -26-
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).
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -27-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -29-
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 ).
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -30-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -31-
¿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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -32-
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
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -33-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -34-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -35-
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?
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -36-
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).
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -37-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -39-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -41-
¿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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -42-
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?
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -43-
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);
}
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -44-
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;
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -45-
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;
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -46-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -47-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -48-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -49-
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.
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -50-
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
75-08 Sistemas OperativosLic. Prof. Osvaldo ClúaFIUBA -51-
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