Programacin Avanzada

1
Programación Avanzada

• Juan Manuel Fernández Peña
• Curso 2005

2
1. Conceptos básicos
3
Enfoque orientado a objetos

• Programación orientada a objetos método de
  implementación en el cual los programas se
  organizan como colecciones de objetos que
  colaboran, donde cada uno representa una
  instancia de alguna clase.

4
Origen de la orientación a objetos

• Complejidad del software tradicional
• Difícil de recordar toda la información necesaria
• Dificultad de entender el dominio del problema
• Lenguajes tradicionales soportan pocos mecanismos
  de abstracción
• Mala organización, alto acoplamiento
• Se requiere flexibilidad
• Se requiere administración del desarrollo

5
Origen de la orientación a objetos

• Atributos de aplicaciones complejas
• Forman jerarquías de subsistemas
• El nivel primitivo de componente se decide de
  manera arbitraria
• Las ligas intracomponente son más fuertes que las
  ligas entre componentes
• Los sistemas jerárquicos, usualmente, consisten
  de pocas categorías de subsistemas en varias
  combinaciones y arreglos
• Un sistema complejo que funciona bien es
  resultado de la evolución de un sistema sencillo

6
Origen de la orientación a objetos

• Estrategia universal de modelado y solución de
  problemas divide y vencerás
• El problema se parte en subproblemas y las
  soluciones de éstos se combinan formando la
  solución global
• En el enfoque orientado a objetos el sistema se
  divide en objetos y se establecen relaciones
  entre ellos.

7
Desarrollo de mecanismos de abstracción

• Tipos de datos básicos Funciones
• Tipos de datos abstractos Módulos
• Objetos
• Clases
• Clases con generalización
• Polimorfismo
• Interfaces
• Clases con reflexión

8
Desarrollo

• Módulo permite manejar espacios de datos,
  separando público de privado, usa ocultamiento de
  información, pero no crea instancias.
• Tipos abstractos define tipos compuestos
  arbitrarios, con su conjunto de valores válidos y
  las funciones que se les puede aplicar.
• Objeto integran concepto de módulo y de tipo
  abstracto de datosdefinidos según su
  responsabilidad el tipo tiene reglas de cómo
  hacer las cosas, pero la implementación es
  privada
• Clase captura conocimiento sobre objetos, define
  tipo abstracto y lo liga con métodos. Define
  características (atributos) y servicios
  (comportamiento), reglas y políticas y relaciones

9
Desarrollo

• Polimorfismo el código compartido vía
  generalización se adapta a circunstancias
  específicas de modo automático
• Interfaces se separa la interfaz (conjunto de
  servicios ofrecidos), la cual se publica, y se
  deja la implemantación aparte
• Reflexión el objeto informa sobre su naturaleza,
  su clase, sus servicios y los parámetros de éstos

10
Definiciones

• Objeto unidad que contiene datos y funciones que
  operan sobre ellos posee nombre, estado y
  comportamiento.
• Los datos se llaman miembros dato o atributos
• Las funciones se llaman miembros función o
  métodos
• Objeto (más formal) es una abstracción de algo
  en el dominio del problema, que refleja las
  capacidaddes de un sistema de almacenar
  información acerca de ello, interactuar con ello
  o ambas.

11
Definiciones

• Clase modelo (abstracción) de un conjunto de
  objetos con un comportamiento y estructura
  similares
• Las clases incluyen los atributos y métodos que
  caracterizan al conjunto de objetos que
  representa. Los atributos y métodos pueden ser
  públicos, protegidos o privados
• Clase abstracta clase donde uno o más métodos no
  se encuentran implementados. Una clase abstracta
  no puede instanciarse, siempre se debe generar
  una subclase que no sea abstracta.

12
Definiciones

• Atributo abstracción de una característica
  simple (de un objeto) que es aplicable al dominio
  del problema y que lo poseen todas las entidades
  consideradas objetos de una misma clase.
• Método especificación de un comportamiento de un
  objeto
• Servicio método que se ofrece de manera pública
• Interfaz Conjunto de servicios que ofrece una
  clase, sin definir su implementación. Una clase
  puede tener una o más interfaces.

13
Principios de la orientación a objetos

• Encapsulación un objeto contiene datos y métodos
  en una unidad.
• Ocultamiento de información el diseñador define
  qué atributos y servicios están disponibles para
  otros objetos y previene el acceso o conocimiento
  de cómo se proveen esos servicios.
• (Esto ayuda a hacer más fácil el mantenmimiento
  de los objetos y a su reutilización, a la vez que
  les da seguridad).

14
Principios de la orientación a objetos

• Paso de mensajes Los objetos se comunican por
  medio de paso de mensajes. Un mensaje consiste
  principalmente del nombre de un servicio y los
  argumentos(parámetros al tiempo de ejecutar)
  además puede incluir el tipo de dato que regresa
  y las excepciones que pueda generar.
• Al nombre del servico y sus argumentos también se
  les llama firma.

15
Principios de la orientación a objetos

• Liga pospuesta (dinámica) El receptor de un
  mensaje se conoce, en general, hasta el momento
  de ejecución, por lo cual la operación de liga
  (linking) se realiza al identificar y ejecutar el
  mensaje.
• En el software tradicional, todas las partes de
  un programa, incluyendo las funciones de
  biblioteca, se identifican y reunen de manera
  estática en la operación de liga (linking),
  posterior a la compilación. La liga estática es
  más rápida, pero no permite cambios dinámicos si
  se modifica un solo elemento del programa, debe
  recompilarse y ligarse todo. Con liga pospuesta
  no es necesario.

16
Principios de la orientación a objetos

• Delegación un objeto cliente pasa trabajo a un
  objeto servidor que ofrece un servicio este a su
  vez puede pasar el trabajo a un tercer objeto. La
  cadena de paso de trabajo se llama delegación. El
  objeto que realiza realmente el trabajo debe
  tener definido ese servicio y debe contar con los
  datos necesarios.
• La delegación permite repartir la responsabilidad
  del proceso a los diversos objetos que
  participan, de modo que las actividades se
  realicen donde residen los datos. No se permite
  que un objeto sea metiche y vaya a cambiar los
  datos o comportamiento de otros.

17
Principios de la orientación a objetos

• Clase/instancia/objeto todo objeto es instancia
  de alguna clase y puede crearse y destruirse al
  tiempo de ejecución.
• Generalización/especialización las clases forman
  jerarquías donde existen clases generales, que
  definen el comportamiento común de una o más
  clases más especializadas. La clase más general
  se llama superclase o clase antecesora y las
  más especializadas se llaman subclase o clase
  derivada. En la raiz de la jerarquía puede
  existir una clase abstracta
• Las subclases pueden agregar atributos.
• También se dice que la subclase HEREDA de la
  superclase

18
Principios de la orientación a objetos

• Generalización/especialización con polimorfismo
  Las subclases pueden sobreescribir (override)
  métodos de la superclase respetando su firma pero
  cambiando su implementación.

19
Principios de la orientación a objetos

• Relaciones los objetos colaboran entre sí para
  realizar funciones completas. Las relaciones
  pueden tener un nombre.
• Interfaz/instancia/objeto un objeto puede ser
  una instancia de una interfaz, pero se crean como
  instancias de la clase a que pertenece la
  interfaz. Por eso la interfaz debe contar con
  alguna implementación.
• Reflexión Cada objeto conoce información
  detallada acerca de la clase a que pertenece, sus
  interfaces (es decir, sus servicios con sus
  parámetros) esta información la puede ofrecer si
  se lo solicitan.

20
Principios de la orientación a objetos

• Multihilo cada objeto puede tener su propio hilo
  de ejecución, es decir, puede manejar eventos
  múltiples de manera concurrente.
• Persistencia algunos objetos poseen
  persistencia, es decir, pueden almacenarse al
  término de una ejecución y recuperarse en otra.
• Lo normal es que los objetos de un programa
  mueren al terminar su ejecución.

21
Principios generales

• Cohesión medida del grado de unidad de las
  funciones que realiza una unidad de un programa
  (función, módulo u objeto). Si realiza una sola
  función, la cohesión es máxima si realiza dos o
  tres muy relacionadas, es un poco menor si
  realiza varias funciones no relacionadas, es muy
  baja. SIEMPRE SE BUSCA QUE SEA ALTA.
• Acoplamiento medida de la interdependencia entre
  unidades de un programa si se comunican por
  medio de llamadas o mensajes con parámetros
  simples, el acoplamiento es pequeño si los
  parámetros cambian el comportamiento del que lo
  recibe, es mayor el mayor acoplamiento es cuando
  una unidad altera los atributos de otra sin su
  permiso o cuando hay variables comunes. SIEMPRE
  SE BUSCA QUE SEA BAJO.
• En el caso de objetos se facilita el lograr alta
  cohesión y bajo acoplamiento, lo cual contribuye
  a aumentar la reusabilidad y facilitar el
  mantenimiento.

22
Otra jerarquía

• Agregación/parte-de los objetos, usualmente,
  forman jerarquias donde unos objetos forman parte
  de otros. Al objeto que es una parte de otro se
  le llama agregado y al que tiene partes se le
  llama contenedor.
• En el mundo real es común que un objeto esté
  formado de partes menores y éstas, a su vez, de
  otras.

23
Diagramas de clases en UML
Abstracción de un conjunto de objetos con
comportamiento común.
Relación de Agregación o Contención la clase D
contiene a la clase E, es decir, la clase E se
agregó a la clase D. También llamada parte-de E
es parte de D
Relación de Generalización A es una
generalización de las clases B y C. Inversamente
B y C heredan de la clase A
24
Diagramas de clases en UML
Abstracción de un conjunto de objetos con
comportamiento común.
Nombre Atributos Métodos
CLASE
Relación de Agregación o Contención la clase D
contiene a la clase E, es decir, la clase E se
agregó a la clase D. También llamada parte-de E
es parte de D
Relación de Generalización A es una
generalización de las clases B y C. Inversamente
B y C heredan de la clase A
25
Diagramas de clases en UML
multiplicidad
Relación o asociación entre clases también se
aplica a generalización y a agregación
Alfa
Beta
1..
requiere
1
Nombre de la relación
La multiplicidad indica cuántas instancias de una
clase pueden relacionarse con otra. En el dibujo,
Una instancia de A puede conectarse con una o más
instancias de Beta, pero cada instancia de Beta
se conecta exactamente a una instancia de A. Los
valores pueden ser 0..1 (puede no haber o haber
una) 0.. (puede no haber o haber cualquier
número 1 (exactamnente una) 1.. (una o
más)
26
Cómo identificar clases y objetosopciones
modernas

• Cosas por modelar cosas, personas, papeles,
  lugares, reportes, formas, organizaciones
• Descomposición de objetos los objetos del mundo
  real se pueden componer en otros y esos también
  se incluyen en el modelado
• Usar generalización se abstrae el comportamiento
  común de varias clases y se crea una superclase
• Usar especialización se puede crear subclases
  con comportamiento más particular
• Reutilizar elementos de aplicaciones semejantes
• Reutilizar jerarquias de clases (bibliotecas)
• Usar la experiencia personal

27
Cómo identificar clases y objetosopciones
tradicionales

• Tomar texto que describe el problema o el negocio
  donde ocurre, identificando los nombres
  (sustantivos, pronombres, frases nominales).
  Luego se revisan para eliminar duplicados.
• Se unifican en singular.
• Revisar la lista eliminando los elementos
  innecesarios (irrelevantes o redundantes) o
  incorrectos (vagos o conceptos fuera del alcance
  del modelo o representan acciones aún cuando
  parezcan sustantivos)
• Volver a revisar textos, leyendo entre líneas

28
Cómo identificar atributos

• Aparecen como adjetivos de objetos o asociados
  con frases como tiene un, mide, se llama.
• Son datos que un objeto debe ser responsable de
  conocer o poseer.
• Se busca la descripción mínima
• Se seleccionan elementos que sean significativos
  en el dominio del problema, que se vayan a
  utilizar.
• Debe haber alguna acción (método) que lo
  requiera. Si nadie lo usa no es necesario.
• Si el valor de una propiedad se puede calcular a
  partir de otras, no se guarda como atributo, a
  menos que el cálculo sea muy complicado.

29
Cómo identificar atributosReglas de Rumbaugh

• Si el atributo existe independientemente, es un
  objeto (por ejemplo una dirección que se maneja
  por separado de la persona que vive ahí)
• Si depende del contexto, se deja como calificador
  de una relación (por ejemplo el número de un
  empleado)
• Los títulos o papeles (jefe, auxiliar, dueño) se
  manejan mejor como calificadores de la relación o
  como subclases (por ejemplo, dueño es subclase de
  persona)
• Los identificadores internos del código no son
  atributos (por ejemplo el número de transacción)
• Si depende de la existencia de una liga con otra
  clase, mejor pasarlo a la liga.

30
Cómo identificar atributosReglas de Shlaer y
Mellor

• Debe ser consistente con la semántica del negocio
• Para cada instancia tiene exactamente un valor
  para cada atributo (los conjuntos o listas no son
  atributos)
• No debe tener estructura interna (es decir, los
  objetos no se valen)
• Debe ser propiedades del objeto y no de sus
  partes
• Si existe una relación con otros objetos, el
  atributo se refiere al primer objeto y no a
  aquellos a los asociados

31
Cómo identificar métodos

• Cada método representa una acción que realiza el
  objeto.
• Pueden identificarse como verbos o frases
  verbales en la descripción del problema o del
  dominio.
• Usualmente, un método debe emplear uno o más de
  los atributos del objeto. Si no usa ninguno, es
  probable que no le corresponda realizar esa
  acción.
• Hay métodos reporteros, que sólo leen valores de
  atributos, pero no los modifican ni hacen
  cálculos
• Hay métodos que modifican los valores de los
  atributos
• Hay métodos que usan los valores de los atributos
  para calcular resultados.

32
Polimorfismo

• Habilidad de que objetos de diferentes clases
  (tipos) respondan a métodos con el mismo nombre
  y parámetros, cada uno de acuerdo a su
  comportamiento específico.
• Habilidad de manipular objetos de diferentes
  clases usando solamente conocimiento de sus
  propiedades comunes, sin preocuparse de su clase
  exacta. La clase no se conoce al tiempo de
  compilar, sino al ejecutar

33
Polimorfismo

• Polimorfismo de método Las subclases de una
  superclase modifican la implementación de uno o
  más métodos, sin cambiar los parámetros ni valor
  de regreso. Si se invoca un objeto, primero busca
  si el método está definido en su clase si no lo
  encuentra, lo busca en la superclase.
• Sobrecarga se pueden tener varios métodos con el
  mismo nombre, pero diferentes parámetros o valor
  de regreso, cada uno con su propia
  implementación. Esto se hace mucho con los
  constructores, para tener uno sencillo y otros
  para diferentes aspectos de la interfaz.
• Polimorfismo de clase se puede definir una
  variable que haga referencia a una superclase y
  luego manipular objetos de superclases cuando se
  invoca un método de la superclase, delega su
  ejecución en el tipo de la subclase.