Programación Orientada

a Objetos
Semana 8
Logro de la sesión

Al finalizar la sesión, el estudiante plantea

un diseño de clases más completo que le
permitirá dar la solución más adecuada al
manejar un conjunto de datos.

2
Agenda
• Composición
• Agregación
• Combinación de composición, agregación y herencia

Datos/Observaciones
Composición

En la mayoría de casos nuestros objetos han sido

01 relativamente simples, por lo que hemos podido describir
cada objeto con una sola clase.

Pero para un objeto que es más complejo, debe considerar

dividir el objeto en sus partes constituyentes y definir una
clase como el todo y otras clases como partes del todo.
02 Cuando la clase del todo es el propietario exclusivo de las
clases de las partes, esa organización de clase se llama
composición
Datos/Observaciones
Composición

El concepto de Cada criatura viviente y Tenga en cuenta la

Cuerpo Humano
composición no es la mayoría de los jerarquía de
nuevo; eso es lo que productos fabricados composición del

Composición
Composición

hacemos para describir están compuestos de cuerpo humano.

objetos complejos en partes. A menudo, Recuerde que con una
el mundo real: cada parte es un relación de
subsistema que se composición, una parte
compone de su propio componente se limita a
conjunto de sub- un solo propietario a la
partes. Juntos, todo el vez. Por ejemplo, un
sistema forman una corazón puede estar en
jerarquía de un solo cuerpo a la vez
composición.

Datos/Observaciones
Composición
Una jerarquía de composición parcial para el cuerpo humano:

Datos/Observaciones
Agregación

En una jerarquía de composición, la relación entre una

clase contenedora y una de sus clases parte se denomina
01 relación “tiene-un”. Por ejemplo, cada cuerpo humano tiene
un cerebro y tiene un corazón.

Hay otra relación “tiene-un” llamada agregación , que es una

forma de composición más débil. Con la agregación, una
02 clase es el todo y otras clases son partes del todo (como
con la composición), pero no existe una restricción adicional
que requiera que las partes sean propiedad exclusiva del
todo.
Datos/Observaciones
Agregación

Un ejemplo de agregación en el que las

partes no son propiedad exclusiva del todo:
Es posible implementar una escuela como una agregación al crear
una clase todo para la escuela y clases parte para los diferentes
tipos de personas que trabajan y estudian en esa escuela.

Las personas no son propiedad exclusiva de la escuela porque una

persona puede formar parte de más de una agregación.

Por ejemplo, una persona puede asistir a clases en dos escuelas

diferentes y ser parte de dos agregaciones escolares. Inclusive
podría quizá formar parte de una tercera agregación, de un tipo
Datos/Observaciones
diferente, como una agregación de inquilinos.
Un programa para un concesionario de automóviles
Suponga que está intentando modelar un concesionario de automóviles con un programa de computadora. Dado
que el concesionario de automóviles está hecho de varias partes distintas no triviales, es un buen candidato para
implementarse con relaciones de composición y agregación.

Las "partes no triviales" del concesionario de automóviles son un grupo de automóviles, un gerente de ventas y
un grupo de vendedores.

Al implementar el programa, defina cuatro clases:

- Las clases Auto, Gerente y Vendedor implementan las partes no triviales del concesionario de automóviles.
- La clase Concesionario contiene las otras tres clases (partes).

Para cada una de las tres relaciones de clase, concesionario-auto, concesionario-vendedor y concesionario-
gerente, ¿es una relación de composición o una relación de agregación?

Datos/Observaciones
Diagrama de clase UML para composición y agregación
Auto
Una línea continua entre dos clases representa
una asociación, una relación entre clases.
En una línea de asociación, un diamante sólido
indica una relación de composición, y un
diamante hueco indica una relación de
agregación. El diamante va al lado de la clase
contenedora
Datos/Observaciones
Concesionario
Gerente Vendedor
Las etiquetas en las líneas de asociación se
denominan valores de multiplicidad usados para
especificar el # de objetos que participan en
asociaciones.
El valor de multiplicidad * representa cualquier
#, de cero a infinito. La combinación de 1 y *
indican asociaciones uno a muchos, “muchos”
implica un número indefinido
Un programa para un concesionario de automóviles
Para implementar un programa que use agregación y composición:
Defina una clase para el conjunto y defina clases separadas para cada una de las partes.

La regla general es que siempre que se tiene una clase que contiene a otra clase, es necesario declarar una variable
de instancia dentro de la clase contenedora, de modo que la variable de instancia tenga una referencia a uno o más
de los objetos de la clase contenida.

Típicamente, si se tiene una clase en un diagrama de clase UML con un valor de multiplicidad *, debe usarse una
ArrayList para implementar la referencia a la clase que está con los asteriscos.

Siempre que dos clases tienen una relación de agregación, es necesario guardar el objeto de la clase contenida en
una variable de referencia en la clase contenedora, y también debe guardarlo en otra variable de referencia fuera de
la clase contenedora. De esa forma, el objeto puede añadirse a otra agregación y tener dos “propietarios” distintos

Siempre que dos clases tienen una relación de composición, el objeto en la clase contenida debe guardarse en una
variable de referencia en la clase contenedora, y no debe guardarse en ninguna otra parte. De esa forma, el objeto
sólo puede tener un “propietario”
Datos/Observaciones
Clase Concesionario para la aplicación
/************************************************************
* Concesionario.java
* Representa una organización de ventas de autos minorista.
************************************************************/
import java.util.ArrayList;
public class Concesionario{
private String company;
private Gerente gerente;
private ArrayList<Vendedor> personas = new ArrayList<Vendedor>();
private ArrayList<Auto> autos = new ArrayList<Auto>();

//*********************************************************
public Concesionario(String company, Gerente gerente) {
this.company = company;
this.gerente = gerente; }
//*********************************************************
public void addAuto(Auto auto){
autos.add(auto); Concesionario
}
public void addPersona(Vendedor persona){
personas.add(persona);
}
//*********************************************************
public void printStatus(){
System.out.println(company + "\t" + gerente.getNombre());
for (Vendedor persona : personas) Auto Gerente Vendedor
System.out.println(persona.getNombre());
for (Auto auto : autos)
System.out.println(auto.getMarca());
}// fin de printStatus
} // fin de clase concesionario
Datos/Observaciones
Clase Auto y Gerente de la aplicación
Concesionario

Auto Gerente Vendedor

/***********************************************************
* Gerente.java
/******************************** * Esta clase implementa un gerente de ventas de un
* Auto.java concesionario
* Esta clase implementa un automóvil. de automóviles.
********************************/ ***********************************************************/
public class Auto { public class Gerente{
private String marca; private String nombre;
//**************************** //********************************************************
public Auto(String marca){ public Gerente(String nombre){
this.marca = marca; this.nombre = nombre;
} }
//**************************** //********************************************************
public String getMarca(){ public String getNombre(){
return marca; return nombre;
} }
Datos/Observaciones
} // fin Clase Auto } // fin clase Gerente
Clase Vendedor de la aplicación
/*************************************************
* Vendedor.java
* Esta clase implementa un vendedor de automóviles.
*************************************************/
public class Vendedor {
private String nombre;
private double ventas = 0.0; // ventas a la fecha
//**********************************************
public Vendedor(String nombre){
this.nombre = nombre; }
//**********************************************
public String getNombre(){ Concesionario

return nombre;
}
} // fin de la clase Vendedor Auto Gerente Vendedor
Datos/Observaciones
Controlador para el programa Concesionario
/*******************************************************
* PruebaConcesionario.java
* Esta clase demuestra la composición de un
* concesionario de automóviles.
*******************************************************/
public class PruebaConcesionario{
public static void main(String[] args){
Gerente ryne = new Gerente("Ryne Mendez");
Vendedor nicole = new Vendedor("Nicole Betz");
Vendedor vince = new Vendedor("Vince Sola");
Concesionario concesionario = new
Concesionario("Automóviles usados que están bien.", ryne);
concesionario.addPersona(nicole);
concesionario.addPersona(vince);
concesionario.addAuto(new Auto("GMC"));
concesionario.addAuto(new Auto("Yugo"));
concesionario.addAuto(new Auto("Dodge"));
concesionario.printStatus();
} // fin metodo main
} // Datos/Observaciones
fin clase main
Comparación de agregación, composición y herencia

Hemos cubierto dos tipos básicos de relaciones de clase:

Las relaciones de agregación y composición ocurren cuando una clase es un todo integrado por
partes constituyentes no triviales definidas en otras clases.

Una relación de herencia es cuando una clase es una versión más detallada de otra clase. La
clase más detallada es una subclase, y la otra clase es una superclase. La subclase hereda los
miembros de la superclase (variables y métodos).

La agregación y la composición se denominan relaciones tiene-un porque una

clase, la clase contenedora, tiene una clase componente en su interior.

La herencia implementa una relación es-un. Una relación de herencia se

denomina relación es-un porque una clase, una subclase, es una versión más
detallada de otra clase.
Datos/Observaciones
Combinación de agregación, composición y herencia
En el mundo real, suele ser común tener relaciones de agregación, composición y herencia
juntas en el mismo programa

Por ejemplo, ¿qué tipo de relación de herencia

podría/debería agregarse al programa de
concesionario cuyo diagrama UML se muestra

En el diagrama de clases UML, se puede observar que las clases Vendedor y Gerente definen el mismo
método de instancia, getNombre. Éste es un ejemplo de duplicación indeseable, de modo que para eliminarla
se usa herencia. El hecho de introducir herencia en ese programa no modifica la estructura original todo-
partes. Simplemente introduce un mecanismo complementario que elimina la duplicación..
Datos/Observaciones
Combinación de agregación, composición y herencia
Definamos una clase mas general, la clase Persona, del cual heredaran Gerente y Vendedor y
evitemos ese código duplicado.
/**
* ****************************************************
* Persona.java Ésta es una clase base para una jerarquía de
la herencia.
****************************************************
*/
public class Persona { La clase Persona simplemente almacena un nombre y permite que el
nombre sea recuperado con un método getNombre. La clase Persona
private String nombre = "";
contiene algo que merece la pena examinar: el constructor de
//****************************************************
parámetro cero. Este es útil para probar el programa con un objeto
public Persona() { Persona, y no se desea liar almacenando un nombre en el objeto
}
Persona. ¿Sabe cuál nombre le será dado a un objeto Persona creado
public Persona(String nombre) { por el constructor de parámetro cero? nombre es una variable de
this.nombre = nombre; instancia String, y el valor por defecto de una variable de instancia
}
//**************************************************** String es null. Para evitar el null por defecto, “nombre” se inicializa con
una cadena vacía.
public String getNombre() {
return this.nombre;
}
} // finDatos/Observaciones
clase Persona
Combinación de agregación, composición y herencia
La herencia reduce las clases Gerente y Vendedor a las clases más simples Gerente2 y
Vendedor2. Estas clases no requieren una declaración explícita de nombre ni de getNombre
porque heredan estos miembros de Persona.

/**
* ******************************************
* Gerente2.java Esto representa al gerente del
concesionario de automóviles.
* ******************************************
*/
public class Gerente2 extends Persona {
public Gerente2(String nombre) {
super(nombre);
} public Vendedor2(String nombre) {
} // fin Clase Gerente2
/**
* *********************************************
* Vendedor2.java Esto representa un vendedor
**********************************************
*/
public class Vendedor2 extends Persona {
private double ventas = 0; // ventas a la fecha
//********************************************
super(nombre);
}
} // fin de Clase Vendedor2

Datos/Observaciones
Combinación de agregación, composición y herencia

En la figura se muestra un diagrama de clase UML mejorado y

expandido para un nuevo programa Concesionario2. El diagrama
incluye la clase Persona. La herencia reduce las clases Gerente y
Vendedor a las clases más simples Gerente2 y Vendedor2. Las
clases previas Gerente y Vendedor ahora heredan una variable, dos
constructores y un método de esta clase Persona. Estas clases más
simples no requieren una declaración explícita de nombre ni de
getNombre porque heredan estos miembros de Persona. La clase
Auto permanece sin cambio respecto al programa Concesionario
original. La clase Concesionario2 prácticamente es la misma excepto
que Gerente ha cambiado a Gerente2 y Vendedor a Vendedor2.

Datos/Observaciones
Resumen
• Los lenguajes orientados a objetos ayudan a organizar las cosas y los conceptos en dos tipos
básicos de jerarquías: una jerarquía tiene-un para componentes en una agregación o en una
composición, y una jerarquía es-un para tipos en una herencia.
• Una jerarquía de agregación o composición existe cuando un objeto grande contiene varios
objetos más pequeños (componentes).
• Para una relación de clase todo-partes, si el contenedor contiene la única referencia a un
componente, entonces el componente asociación es la composición. En caso contrario, se
trata de agregación.
• Los programadores utilizan a menudo combinaciones de agregación, composición y herencia
para tratar diferentes aspectos de un problema de programación global. En un diagrama de
clase UML, ambas relaciones se representan mediante líneas continuas entre clases
relacionadas, y estas líneas se denominan asociaciones. En una asociación de
composición/agregación hay un diamante lleno/ hueco en el extremo del contenedor de cada
línea de asociación. En una asociación jerárquica hay una punta de flecha hueca en el
extremo de la superclase de la línea de asociación.
Resumen
• Cuando se tiene una asociación complicada entre objetos, puede ser de utilidad reunir
referencias a esos objetos en una clase de asociación común.