Programación Estructurada.

Es un paradigma de programación orientado a mejorar la claridad, calidad y

tiempo de desarrollo de un programa de computadora, utilizando
únicamente subrutinas y tres estructuras: secuencia, selección (if y switch)
e iteración (bucles for y while), considerando innecesario y
contraproducente el uso de la instrucción de transferencia incondicional
(GOTO), que podría conducir a "código espagueti", que es mucho más
difícil de seguir y de mantener, y era la causa de muchos errores de
programación. Surgió en la década de 1960 y fue reforzado teóricamente
por el teorema del programa estructurado, y prácticamente por la aparición
de lenguajes como ALGOL con adecuadas y ricas estructuras de control.

El teorema del programa estructurado, propuesto por Böhm-Jacopini,

demuestra que todo programa puede escribirse utilizando únicamente las
tres instrucciones de control siguientes: Secuencia, Instrucción
condicional, Iteración (bucle de instrucciones) con condición al principio.
Solamente con estas tres estructuras se pueden escribir todos los
programas y aplicaciones posibles. Si bien los lenguajes de programación
tienen un mayor repertorio de estructuras de control, éstas pueden ser
construidas mediante las tres básicas citadas.
 Programación Orientada a Objetos.
Es importante aclarar desde un principio la diferencia que existe entre
programación orientada a objetos y un lenguaje orientado a objetos.

La programación orientada a objetos es una “filosofía”, un modelo de

programación, con su teoría y su metodología, que conviene conocer y
estudiar antes que nada. Un lenguaje orientado a objetos es un
lenguaje de programación que permite el diseño de aplicaciones
orientadas a objetos.

Lo normal es que toda persona que vaya a desarrollar aplicaciones

orientadas a objetos aprenda primero la “filosofía” (o adquiera la forma
de pensar) y después el lenguaje, porque “filosofía” sólo hay una y
lenguajes muchos.

La programación orientada a objetos surge en la historia como un

intento para dominar la complejidad que, de forma innata, posee el
software.
 Programación Orientada a Objetos.

Tradicionalmente, la forma de enfrentarse a esta complejidad ha sido

empleando lo que llamamos programación estructurada, que consiste
en descomponer el problema a solucionar, en subproblemas y más
subproblemas hasta llegar a acciones muy simples y fáciles de
codificar. Se trata de descomponer el problema en acciones, en
verbos como hallar, comprobar, calcular (esto es lo que se ha hecho
en lógica y programación).

La programación orientada a objetos es otra forma de descomponer

problemas. Este nuevo método de descomposición es la
descomposición en objetos; la programación orientada a objetos
obliga a fijarse no en lo que hay que hacer en el problema, sino en
cuál es el escenario real del mismo, y luego intentar simular ese
escenario en el software o programa.
 Programación Orientada a Aspectos.
La Programación Orientada a Aspectos (POA) es un paradigma de
programación relativamente reciente cuya intención es permitir una
adecuada modularización de las aplicaciones y posibilitar una mejor
separación de conceptos. Gracias a la POA se pueden capturar los
diferentes conceptos que componen una aplicación en entidades bien
definidas, de manera apropiada en cada uno de los casos y eliminado las
dependencias inherentes entre cada uno de los módulos. De esta forma se
consigue razonar mejor sobre los conceptos, se elimina la dispersión del
código y las implementaciones resultan más comprensibles, adaptables y
reusables.
Los siguientes conceptos son los más importantes de la programación
orientada a aspectos en general: Aspecto (aspect), funcionalidad
transversal (se repetirá a lo largo del sistema) que será implementada de
forma separada. Es el concepto principal de este paradigma puesto que
representa la sección de código que se separó del resto del programa.
Punto de corte (pointcut), es el que se encarga de especificar mediante
expresiones regulares (regex) en qué parte del programa se debe de
insertar un aspecto. Consejo (advice), es el código que ejecutará el aspecto
(cuerpo del algoritmo).
 Programación Orientada a Objetos.

¿Cómo se piensa en objetos?

Pensar en términos de objetos es muy parecido a cómo se haría en la

vida real. Por ejemplo pensar en una casa y tratar de modelarla en un
esquema de POO, diríamos que la casa es el elemento principal que
tiene una serie de características, como podrían ser el color, el
numero de habitaciones, el numero de baños. Además tiene una serie
de funcionalidades asociadas, como rentarla, venderla, hacerle
mantenimiento, etc.

Pues en un esquema POO la casa sería la clase, las propiedades

serían las características como el color, el nombre del propietario y
los métodos serían las funcionalidades asociadas como hacerle
mantenimiento, colocarla en venta o alquiler.
 Programación Orientada a Objetos.
Los objetos son entidades que combinan estado, comportamiento e identidad:
El estado está compuesto de datos, serán uno o varios atributos a los que
se habrán asignado unos valores concretos (datos).
El comportamiento está definido por los procedimientos o métodos con que
puede operar dicho objeto, es decir, qué operaciones se pueden realizar con él.
La identidad es una propiedad de un objeto que lo diferencia del resto, dicho
con otras palabras, es su identificador (concepto análogo al de identificador de una
variable o una constante).

Los métodos (comportamiento) y atributos (estado) están estrechamente

relacionados por la propiedad de conjunto. Esto difiere de la programación
estructurada tradicional, en la que los datos y los procedimientos están separados y
sin relación, ya que lo único que se busca es el procesamiento de unos datos de
entrada para obtener otros de salida. La programación estructurada anima al
programador a pensar sobre todo en términos de procedimientos o funciones, y en
segundo lugar en las estructuras de datos que esos procedimientos manejan. En la
programación estructurada sólo se escriben funciones que procesan datos. Los
programadores que emplean éste nuevo paradigma, en cambio, primero definen
objetos para luego enviarles mensajes solicitándoles que realicen sus métodos por
sí mismos.
 Programación Orientada a Objetos.

La Programación Orientada a Objetos es un paradigma de

programación que usa objetos y sus interacciones para diseñar
aplicaciones y programas de computador.

Es una forma especial de programar, más cercana a como

expresaríamos las cosas en la vida real, con la POO tenemos que
aprender a pensar las cosas de una manera distinta, para escribir
nuestros programas en términos de clases, objetos, propiedades,
métodos y otras cosas.

Está basado en varias técnicas, incluyendo herencia, modularidad,

polimorfismo, y encapsulamiento. Su uso se popularizó a principios
de la década de 1990. Actualmente son muchos los lenguajes de
programación que soportan la orientación a objetos.
 ¿QUE ES UML Y POR QUE ES IMPORTANTE?

Hoy en día, UML ("Unified Modeling Language") esta consolidado

como el lenguaje estándar en el análisis y diseño de sistemas de
computo. Mediante UML es posible establecer la serie de
requerimientos y estructuras necesarias para plasmar un sistema de
software, previo al proceso de codificación. El UML permite generar
diseños que capturen las ideas en una forma convencional y fácil de
comprender y así poder comunicarlas a otras personas.

Aunque UML es un lenguaje, éste posee más características visuales

que programáticas, que facilitan a integrantes de un equipo
multidisciplinario, participar e intercomunicarse fácilmente, estos
integrantes pueden ser los analistas, diseñadores, especialistas de
área y desde luego los programadores.
 Programación Orientada a Objetos.

Como UML es empleado en el análisis para sistemas de mediana y alta

complejidad, su base radica en otro paradigma utilizado en diseños de
sistemas de alto nivel que es la orientación a objetos, por que para
trabajar en UML, se puede considerar como un prerrequisito tener
experiencia en un lenguaje orientado a objetos.

Entre los lenguajes orientados a objetos más utilizados se encuentran

Java y C#, además de otros más antiguos como C++ y SmallTalk,
aunque el programar en todos estos lenguajes requiere experiencia
previa sobre la sintaxis y bloques específicos, el paradigma empleado
en todos ellos es el mismo : Objetos.

Lo anterior permite que un análisis en UML sea realizado

independiente del lenguaje en el que se implemente, es por esta
característica que permite a personal no familiarizado en lenguajes de
programación participar en el análisis y diseño de un sistema.
 UML-POO

DIFERENCIAS DE LA PROGRAMACIÓN ESTRUCTURADA Y LA

PROGRAMACIÓN ORIENTADA A OBJETOS.

Las ventajas de la programación estructurada son:

• Los programas son más fáciles de entender. Un programa estructurado

puede ser leído en secuencia, de arriba hacia abajo, sin necesidad de
estar saltando de un sitio a otro en la lógica, lo cual es típico de otros
estilos de programación.
• Reducción del esfuerzo en las pruebas. El programa se puede tener listo
para producción normal en un tiempo menor del tradicional; por otro
lado, el seguimiento de las fallas se facilita debido a la lógica más
visible, de tal forma que los errores se pueden detectar y corregir mas
fácilmente.
• Programas más sencillos y más rápidos.
• Los programas quedan mejor documentados internamente.
 UML-POO

DIFERENCIAS DE LA PROGRAMACIÓN ESTRUCTURADA Y LA

PROGRAMACIÓN ORIENTADA A OBJETOS.
Las ventajas de la programación orientada a objetos son:

• Fomenta la reutilización y extensión del código.

• Permite crear sistemas más complejos.
• Relacionar el sistema al mundo real.
• Facilita la creación de programas visuales.
• Construcción de prototipos
• Agiliza el desarrollo de software
• Facilita el trabajo en equipo
• Facilita el mantenimiento del software
• Modificabilidad. La facilidad de añadir, suprimir o modificar nuevos
objetos nos permite hacer modificaciones de una forma muy sencilla.
• Fiabilidad. Al dividir el problema en partes más pequeñas podemos
probarlas de manera independiente y aislar mucho más fácilmente los
posibles errores que puedan surgir.
 UML-POO

DIFERENCIAS DE LA PROGRAMACIÓN ESTRUCTURADA Y LA

PROGRAMACIÓN ORIENTADA A OBJETOS.

Las ventajas de la programación orientada a aspectos son:

• Código menos enmarañado, más natural y más reducido.

• Mayor facilidad para razonar sobre los conceptos, ya que están
separados y tienen una dependencia mínima.
• Facilidad en depurar y modificar el código.
• Modificaciones grandes en la definición de una materia tenga un impacto
mínimo en las otras.
• Código más reusable y que se puede acoplar y desacoplar cuando sea
necesario.
• Mayor reutilización de los aspectos, tienen mayores probabilidades de
ser reutilizados en otros sistemas con requerimientos similares.
 DIAGRAMA DE CLASES. UML

Un diagrama de Clases representa las clases que serán utilizadas dentro del
sistema y las relaciones que existen entre ellas.

Nos sirve para visualizar las relaciones entre las clases que involucran el sistema,
las cuales pueden ser asociativas, de herencia, de uso y de convencimiento.

Es el diagrama principal para el análisis y diseño de un sistema. Describe la vista

estática de un sistema en términos de clases y relaciones entre ellas y no el
comportamiento en función del tiempo.

Los objetos interactúan para alcanzar colectivamente los servicios ofrecidos por las
aplicaciones. Los diagramas estáticos describen el sistema desde el punto de vista
de sus componentes. Se utilizan para modelar: Los elementos del Sistema,
Estructura Interna, Colaboraciones entre elementos.

Un diagrama de clases está compuesto por los siguientes elementos:

Clases: atributos, métodos y visibilidad.
Relaciones: Herencia, Composición, Agregación, Asociación y Uso.
 CLASES.
Las clases son declaraciones o abstracciones de objetos, lo que significa, que una
clase es la definición de un objeto. Cuando se programa un objeto y se definen sus
características y funcionalidades, realmente se programa una clase.
Es la unidad básica que encapsula toda la información de un Objeto (un objeto es
una instancia de una clase). A través de ella podemos modelar el entorno en estudio
(una Casa, un Auto, una Cuenta Corriente, etc.). Una clase tiene las características
comunes de un conjunto de objetos.
En UML, una clase es representada por un rectángulo que posee tres divisiones:

En donde:
Superior: Contiene el nombre de la Clase
Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la
Clase (pueden ser private, protected o public).
Inferior: Contiene los métodos u operaciones, los cuales son la forma como
interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected
o public).
 CLASES.

Estructura de una clase:

Identidad: Permite distinguir un objeto de otro (nombre)
Atributos y propiedades (Estado): Características del objeto.
Parámetros que lo definen y lo diferencian de objetos del mismo tipo (Variables
miembro y valores).
Métodos: Comportamiento del objeto.
Acciones que realizan (Métodos o Funciones miembro).
 DIAGRAMA DE CLASES

VISIBILIDAD, Atributos y métodos

Los miembros de un objeto pueden ser accedidos (manipulados) por
otros objetos teniendo en cuenta ciertos niveles de visibilidad:
Atributos:
Los atributos o características de una Clase pueden ser de tres tipos, los
que definen el grado de comunicación y visibilidad de ellos con el entorno,
estos son:
public (+, ):
Indica que el atributo será visible tanto dentro como fuera de la clase, es
decir, es accesible desde todos lados.
private (-, ):
Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus
métodos lo pueden accesar).
protected (#, ):
Indica que el atributo no será accesible desde fuera de la clase, pero si
podrá ser accesado por métodos de la clase además de las subclases que
se deriven (ver herencia).
 DIAGRAMA DE CLASES

VISIBILIDAD, Atributos y métodos

Métodos:
Los métodos u operaciones de una clase son la forma en como ésta
interactúa con su entorno, éstos pueden tener las características:
public (+, ):
Indica que el método será visible tanto dentro como fuera de la clase, es
decir, es accesible desde todos lados.
private (-, ):
Indica que el método sólo será accesible desde dentro de la clase (sólo
otros métodos de la clase lo pueden accesar).
protected (#, ):
Indica que el método no será accesible desde fuera de la clase, pero si
podrá ser accesado por métodos de la clase además de métodos de las
subclases que se deriven (ver herencia).
 DIAGRAMA DE CLASES

Relaciones entre Clases

Ahora ya definido el concepto de Clase, es necesario explicar cómo se

pueden interrelacionar dos o más clases (cada uno con características y
objetivos diferentes).

Antes es necesario explicar el concepto de cardinalidad de relaciones: En

UML, la cardinalidad de las relaciones indica el grado y nivel de
dependencia, se anotan en cada extremo de la relación y éstas pueden
ser:

1 uno y solo uno

0 .. 1 cero o uno
M .. N desde M hasta N
0 .. * ceros o muchos
1 .. * uno o muchos
 DIAGRAMA DE CLASES

Relaciones entre Clases

Herencia (Especialización/Generalización):
Indica que una subclase hereda los métodos y atributos especificados por una
Súper Clase, por ende la Subclase además de poseer sus propios métodos y
atributos, poseerá las características y atributos visibles de la Súper Clase
(public y protected).

Esta permite crear una clase a partir de otra y heredar sus atributos y
funciones miembro.
Una clase comparte la estructura definida en otra clase.
Característica que permite que un objeto sea construido a partir de otros.
 DIAGRAMA DE CLASES

Relaciones entre Clases

En la figura se especifica que Auto y Camión heredan de Vehículo, es decir,

Auto posee las Características de Vehículo (Precio, VelMax, etc.) además
posee algo particular que es Descapotable, en cambio Camión también hereda
las características de Vehículo (Precio, VelMax, etc.) pero posee como
particularidad propia Acoplado, Tara y Carga.

Cabe destacar que fuera de este entorno, lo único "visible" es el método

Características aplicable a instancias de Vehículo, Auto y Camión, pues tiene
definición pública, en cambio atributos como Descapotable no son visibles por
ser privados.
 Las Subclases heredan las características de la Superclase
(Padre-Hijo, Base-Derivada).
Reutilizar código existente Animal

Diversos nombres:
Mamífero Reptil
• Clase Padre - Clase Hija
• Superclase - Subclase
• Clase Base - Clase Perro Gato Serpiente
Derivada

Persona
AVIÓN

Hombre Mujer
Avión de Avión de Avión
carga pasajeros militar
 Herencia Múltiple

Una subclase puede heredar datos y

métodos de mas de una clase.

Persona

Profesor Investigador

Profesor Investigador
 DIAGRAMA DE CLASES

Relaciones entre Clases

Agregación:

Para modelar objetos complejos, no bastan los tipos de datos básicos que
proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando
se requiere componer objetos que son instancias de clases definidas por el
desarrollador de la aplicación, tenemos dos posibilidades:
• Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del
objeto incluido está condicionado por el tiempo de vida del que lo
incluye. Este tipo de relación es comúnmente llamada Composición (el
Objeto base se construye a partir del objeto incluido, es decir, es
"parte/todo").
• Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de
vida del objeto incluido es independiente del que lo incluye. Este tipo de
relación es comúnmente llamada Agregación (el objeto base utiliza al
incluido para su funcionamiento).
 DIAGRAMA DE CLASES

Relaciones entre Clases

Un ejemplo es el siguiente, en donde se destaca que:

Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que
posee las referencias). Cuando se destruye el Objeto Almacén también son
destruidos los objetos Cuenta asociados, en cambio no son afectados los
objetos Cliente asociados.

La composición (por Valor) se destaca por un rombo relleno.

La agregación (por Referencia) se destaca por un rombo transparente.
La flecha en este tipo de relación indica la navegabilidad del objeto
referenciado. Cuando no existe este tipo de particularidad la flecha se
elimina.
 Agregación
• Una o más clases (Clases Componentes) forman parte o son
componentes de otra clase (Clase Agregada).
• Una clase agregada puede potencialmente existir sin sus
partes constituyentes.
• En cualquier momento dado, cualquier objeto constituyente
puede formar parte de más de un objeto agregado.

Universidad

1..* 1..* 1..* 0..*

Profesor Alumno Pregrado Postgrado
 Composición
• El contenedor es completamente responsable de sus
contenidos y cada contenido está asociado a uno y solo un
contenedor.

• Los componentes no pueden existir independientemente.

 Agregación / Composición

•Dependencia existencial: Un objeto componente depende

del objeto agregado del cuál forma parte.
El objeto contenido es parte constitutiva y vital del que lo
contiene.
Los objetos contenidos no son compartidos, esto es, no hacen
parte del estado de otro objeto.
•Independencia existencial: se trata de una relación entre las
dos clases no muy fuerte. El objeto componente no
desaparece al destruirse el que lo contiene. (Agregación)

Casa
Equipo 1..11
1..* 1 de Miembros
Habitación Tejado fútbol

Dependencia -> Composición No Dependencia -> Agregación

 Ejemplo
MaquinaCafe
-valor_recolectado : float = 0
+RecibirMoneda()
Diagrama de clases para el +CancelarOperacion()
+ServirProducto()
ejemplo de la máquina de +EntregarVuelta() : int

café. 1

Producto Ingrediente DepositoMonedas

-nombre : string -nombre : string -numMonedas : float = 0
-costo : float -cantidad : float = 0 +AgregarMoneda()
1 1..* +ElegirIngrediente()

Denominacion es
100,200,500
CafeTinto CafeLeche Cafelate

Cafe Azucar Cacao

-tipo : string -tipo : string
-cantidad : int = 0 -cantidad : int = 0
+EscogerTipo()
+EscogerCantidad()
-tipo : string DepositoMonedaTipo
-cantidad : int = 0
-denominacion : int
+VerificarMoneda() : bool
+DevolverMoneda()
 DIAGRAMA DE CLASES

Relaciones entre Clases

Asociación:

La relación entre clases conocida como Asociación, permite asociar objetos

que colaboran entre sí. Cabe destacar que no es una relación fuerte, es
decir, el tiempo de vida de un objeto no depende del otro.
Una asociación es una relación simple entre dos o más clases. Esta relación
puede ser binaria o N-aria. Aparecen como verbos en la descripción del
problema.
Se indican las restricciones de cardinalidad o Multiplicidad (Número de
instancias de una clase; cuantos objetos de esa clase pueden participar en
la relación dada).

Ejemplo:
Un cliente puede tener asociadas muchas Órdenes de Compra, en cambio
una orden de compra solo puede tener asociado un cliente.
 DIAGRAMA DE CLASES

Relaciones entre Clases

Dependencia o Instanciación (uso):

Representa un tipo de relación muy particular, en la que una clase es

instanciada (su instanciación es dependiente de otro objeto/clase). Se
denota por una flecha punteada.

El uso más particular de este tipo de relación es para denotar la

dependencia que tiene una clase de otra, como por ejemplo una aplicación
grafica que instancia una ventana (la creación del Objeto Ventana está
condicionado a la instanciación proveniente desde el objeto Aplicación):
Cabe destacar que el objeto creado (en este caso la Ventana gráfica) no se
almacena dentro del objeto que lo crea (en este caso la Aplicación).
 CONSTRUCTORES Y OBJETOS

Instanciar: Una vez que se tiene una clase definida, se dispone de una
especie de plantilla o molde a partir de la cual se pueden crear objetos en
memoria.

Para crear esos objetos se utiliza la instrucción “nuevo” (new) que es la

encargada de crear el objeto en la memoria y asignar la dirección del
mismo a la variable usada en la parte izquierda de la asignación.

Declarar primero la variable y después instanciarla.

Lo primero que se debe hacer es declarar una variable del tipo que se
quiere instanciar, esto se hace de la misma forma que con cualquier otro
tipo de datos:

Objcli es Cliente Cliente Objcli;

Con esta instrucción se está indicando que se usará una variable llamada
Objcli para acceder a una clase de tipo Cliente.
 CONSTRUCTORES Y OBJETOS

Esa variable, cuando llegue el momento de usarla, sabrá todo lo que hay
que saber sobre la clase Cliente, pero hasta que no tenga una "referencia" a
un objeto de ese tipo no se podrá usar.

La asignación de una referencia a un objeto Cliente se hace usando la

instrucción “nuevo” seguida del nombre de la clase:

Objcli = nuevo Cliente() Objcli=new Cliente();

A partir de este momento, la variable Objcli tiene acceso a un nuevo objeto

del tipo Cliente, por tanto se puede usar para asignarle valores y usar
cualquiera de los miembros que ese tipo de datos contenga:

Objcli.Nombre = "Antonio"
Objcli.Apellidos = "Ruiz Rodríguez"
Objcli.Ingresar()
 CONSTRUCTORES Y OBJETOS

Declarar e instanciar en un solo paso.

La otra forma de instanciar una clase es haciéndolo al mismo tiempo que

se declara.

ObjCli es Cliente = nuevo Cliente()

Cliente Objcli =new Cliente();

De esta forma se asignará a la variable Objcli una referencia a un nuevo

objeto creado en la memoria, el cual será totalmente independiente del
resto de objetos creados con esa misma clase.

El constructor: El constructor: El punto de inicio de una clase.

Cada vez que se crea un nuevo objeto en memoria se está llamando al

constructor de la clase. El constructor es una especie de método que se
llama de la misma forma que la clase.
 CONSTRUCTORES Y OBJETOS
En el constructor de una clase se puede incluir el código que se crea
conveniente, pero realmente debería incluir el que realice algún tipo de
inicialización, en caso de que no se necesite realizar ningún tipo de
inicialización, no es necesario definir el constructor, ya que el propio
compilador lo hará. Esto es así porque todas las clases deben implementar
un constructor, si no se define, lo hará el compilador.

En los constructores también se puede elaborar las inicializaciones que,

por ejemplo permitan a la clase a conectarse con una base de datos, abrir
un fichero o cargar una imagen gráfica, etc.

El constructor por defecto.

En las clases debe existir un constructor que no tenga argumentos, se le

llamará constructor por defecto o constructor predeterminado.

El constructor por defecto, se ejecuta automáticamente cada vez que se

crean objetos sin pasar argumentos.
 CONSTRUCTORES Y OBJETOS

El constructor es un método especial de una clase. El objetivo fundamental del

constructor es inicializar los atributos del objeto que creamos.

Las ventajas de implementar un constructor son:

1. El constructor es el primer método que se ejecuta cuando se crea un
objeto.
2. El constructor se llama automáticamente. Es decir es imposible de
olvidarse de llamarlo ya que se llamará automáticamente.
3. Quien utiliza POO (Programación Orientada a Objetos) conoce el
objetivo de este método.

Otras características de los constructores son:

• El constructor se ejecuta inmediatamente luego de crear un objeto y no
puede ser llamado nuevamente.
• Un constructor no puede retornar dato.
• Un constructor puede recibir parámetros que se utilizan normalmente
para inicializar atributos.
• El constructor es un método opcional, de todos modos es muy común
definirlo.
 CONSTRUCTORES Y OBJETOS

Métodos constructores.

Los diseñadores del lenguaje decidieron asignar la tarea de inicializar los

objetos a los métodos constructores. La consideraron tan importante que si
el programador no declara ningún método constructor, el compilador se
encarga de definir un constructor de oficio.

Un constructor es una función miembro pública con el mismo nombre de la

clase.

Se ejecuta automáticamente al crearse un objeto de la clase.

Es más adecuado colocar el código de inicialización en un método

constructor que en una función, así podemos estar seguros de que el
código de inicialización se va a ejecutar siempre sobre cualquier objeto que
se cree de esa clase.

Si la inicialización se encuentra en otro método, se nos puede olvidar

enviar el mensaje correspondiente al objeto.
 CONSTRUCTORES Y OBJETOS

Sobrecarga de funciones constructoras.

Al igual que para el resto de los métodos, podemos tener varias

funciones constructoras; esto nos produce varias formas de
inicialización.

Clase Complejo Método Complejo ( a es real )

raiz = a
//atributos propios y private imaginaria = 0
raiz es real Fin del método Complejo
imaginaria es real
Método Complejo(a es real, b es real)
//constructores raiz l = a
Método Complejo( ) imaginaria = b
raiz = 0 Fin del método Complejo
imaginaria = 0
Fin del método Complejo Fin clase Complejo
 CONSTRUCTORES Y OBJETOS

Constructores parametrizados.
De la misma forma que podemos tener métodos sobrecargados, también
podemos tener constructores sobrecargados.

La ventaja de tener constructores que admitan parámetros es que

podemos crear nuevos objetos indicando algún parámetro, por ejemplo un
fichero a abrir o, en el caso de la clase Cliente, podemos indicar el nombre
y apellidos del cliente o cualquier otro dato que creamos conveniente.
Clase Cliente
Nombre, Apellidos, FechaCreacion es caracter
//constructores
Metodo Cliente()
FechaCreacion = 10/10/13
Fin método cliente

Metodo Cliente(elNombre es caracter, losApellidos es caracter)

Nombre = elNombre
Apellidos = losApellidos;
Fin método cliente
 CONSTRUCTORES Y OBJETOS

Teniendo esta declaración de la clase Cliente, podemos crear nuevos clientes

de dos formas:
Objcli es Cliente = nuevo Cliente()
Objcli2 es Cliente = nuevo Cliente(("Jose", "Sánchez")

Como podemos comprobar, en ciertos casos es más intuitiva la segunda forma

de crear objetos del tipo Cliente, además de que así nos ahorramos de tener
que asignar individualmente los campos Nombre y Apellidos. El número y tipo
de dato de los parámetros debe estar indicado en la documentación del método
constructor de la clase. En el momento de hacer la llamada al método
constructor hay que cumplir el número de parámetros que admite así como sus
tipos de datos.

Hay que tener en cuenta que una misma clase puede tener varios métodos
constructores, todos ellos con el mismo nombre que la clase, pero variará el
número y/o tipo de datos de los parámetros. En el momento de llamar al
método constructor se pueden indicar como parámetros tanto valores literales,
como variables o cualquier tipo de expresión siempre que se cumpla con el
requisito de que debe respetarse el tipo de dato.
 UML-POO

PÁGINAS CONSULTADAS
http://luis.izqui.org/resources/ProgOrientadaObjetos.pdf

https://www.youtube.com/watch?v=wmECY8XCe4E

https://www.youtube.com/watch?v=EOKT3p0nuzo

https://www.youtube.com/watch?v=2Oz7Z6Lwf70

http://www.slideshare.net/e1da4/diagramas-uml

http://computacionii.foroes.org/t6-programacion-orientada-a-objetos-vs-
programacion-estructurada

http://www.alegsa.com.ar/Diccionario/C/12117.php

http://elclubdelautodidacta.es/wp/2014/09/python-el-concepto-de-clase/
 UML-POO

PÁGINAS CONSULTADAS

http://javiergarciaescobedo.es/programacion-en-java/2-clases-y-

objetos/218-instanciacion-de-objetos

http://www.jtech.ua.es/j2ee/publico/spring-2012-13/apendice_AOP-

apuntes.html

https://codingornot.com/que-es-la-programacion-orientada-a-aspectos-aop

http://www.angelfire.com/ri2/aspectos/Tesis/tesis.pdf

https://www.youtube.com/watch?v=rLYiJJwx6Ws