Características: -Abstracción -Herencia -Encapsulamiento -Polimorfismo -Relaciones •
• •
Asociaciones ○ Composición ○ Agregación Herencia Multiplicidad
Elementos -Clases • • •
Métodos Atributos Propiedades(Solo .Net)
-Interfaces
El proceso de abstracción permite seleccionar las características relevantes dentro de un conjunto e identificar comportamientos
comunes para definir nuevos tipos de entidades en el mundo real. La abstracción es clave en el proceso de análisis y diseño orientado a objetos, ya que mediante ella podemos llegar a armar un conjunto de clases que permitan modelar la realidad o el problema que se quiere atacar. Ignorancia Selectiva La abstracción nos ayuda a trabajar con cosas complejas Se enfoca en lo importante Ignora lo que no es importante (simplifica) Una clase es una abstracción en la que: Se enfatizan las características relevantes Se suprimen otras características Una clase debe capturar una y solo una abstracción clave
El propósito principal de la herencia es el de organizar mejor las clases que componen una determinada realidad, y poder agruparlas en función de atributos y comportamientos comunes a la vez que cada una se especializa según sus particularidades. Cabe aclarar además que hay dos tipos de herencias: –
Herencia Simple: una clase derivada puede heredar sólo de una clase base (los lenguajes .NET soportan este tipo de herencia)
–
Herencia Múltiple: una clase derivada puede heredar de una o más clases base (C++ es un ejemplo de lenguaje que soporta este tipo de herencia).
Es una relación entre clases en la cual una clase comparte la estructura y comportamiento definido en otra clase (Grady Booch) Cada clase que hereda de otra posee: Los atributos de la clase base además de los propios
Soporta todos o algunos de los métodos de la clase base Una subclase hereda de una clase base
Principio que establece que los atributos propios de un objeto no deben ser visibles desde otros objetos Deben ser declarados como privados Permite abstraer al resto del mundo de la complejidad de la implementación interna Permite exponer el estado del objeto sólo a través del comportamiento que le hayamos definido mediante miembros públicos ¿Por qué es útil? Punto de Control/Validación Mejor respuesta ante los Cambios -Otro de los pilares de la orientación a objetos es el encapsulamiento. Para entender este principio veamos un ejemplo práctico: Como todos ustedes se imaginarán, no es necesario ser mecánico de automóviles para poder manejar uno. Si el comprender cómo es el funcionamiento interno del motor, la dirección, los frenos, los cilindros, etc. fuera requisito para poder manejar un automóvil, serían muchos menos los conductores certificados y sería mucho más difícil aprender a manejar. Es más, si a cualquier automotriz se le ocurriera cambiar el funcionamiento interno de alguna de estas cosas, probablemente todos los conductores tendrían que volver a aprender como funciona el nuevo componente interno para poder seguir manejando sin problemas. Por suerte esto no es así, ya que la complejidad interna del funcionamiento de un automóvil está escondida de los conductores (usuarios). Para poder interactuar con el automóvil, éste nos expone una interfaz sencilla y definida, que no cambia nunca por más que cambien internamente el funcionamiento de sus componentes. Esta interfaz está compuesta por el volante, los pedales, la palanca de cambios, el asiento, etc. De esta forma decimos que el automóvil ha encapsulado su complejidad interna.
Es la propiedad que tienen los objetos de permitir invocar genéricamente un comportamiento (método) cuya implementación será delegada al objeto correspondiente recién en tiempo de ejecución El polimorfismo tiende a existir en las relaciones de herencia, pero no siempre es así
Aquí tenemos un ejemplo práctico de la implementación de polimorfismo en un diseño orientado a objetos. Por un lado tenemos la clase base “Transporte”, que posee los métodos “Avanzar” y “Frenar”. Por otro lado tenemos tres clases distintas derivadas de la clase “Transporte”, cada una de las cuales podrá sobrescribir la implementación de los métodos Avanzar y Frenar para que su comportamiento sea más específico. Ahora bien, como todas heredan de la misma clase base, las clases derivadas pueden ser tratadas genéricamente. Esto quiere decir que podríamos tener un array que almacene objetos de tipo Transporte, y recorrerlo luego para llamar al método “Avanzar” de cada uno. De esta forma, en tiempo de codificación es imposible saber a qué método “Avanzar” se está llamando en realidad (al del Auto? Al del caballo? Al del transbordador?), sino que esta decisión es tomada en tiempo de ejecución en base al tipo particular de objeto que esté instanciado. En pseudocódigo, esto se escribiría de la siguiente manera: Definir arrayTransportes (3) de tipo Transporte ArrayTransportes (1) = nuevo Automóvil () //Un automóvil ES UN TIPO DE transporte ArrayTransportes (2) = nuevo Transbordador () //Un Transbordador ES UN TIPO DE transporte ArrayTransportes (3) = nuevo Caballo () //Un Caballo ES UN TIPO DE transporte Por Cada (Transporte t en arrayTransportes) t.Avanzar () t.Frenar () Fin
Todo sistema abarca muchas clases y objetos Los objetos contribuyen en el comportamiento de un sistema colaborando entre si La colaboración se logra a través de las relaciones Existen dos tipos principales de relaciones Asociación Agregación
•
Relaciones Asociadas Una asociación es una conexión entre dos clases que representa una comunicación Una asociación puede tener nombre La comunicación puede ser tanto uni como bi-direccional (por defecto) La multiplicidad es el número de instancias que participan en una asociación Ejemplo: Una Persona es Dueña de un Vehículo Un Vehículo Pertenece a una Persona Persona
-dueño
Vehiculo
Relaciones de Agregación
La agregación es una forma especial de asociación donde un todo se relaciona con sus partes También se conoce como “una parte de” o una relación de contención Ejemplo: Una Puerta es una parte de un Vehículo El Vehículo es azul, la Puerta es Azul
Mover el Vehículo implica mover la Puerta
Vehiculo
Puerta
-color +Mover()
Relaciones de Composición La composición (también conocida como relación asociativa) es un tipo de relación que se establece entre dos objetos que tienen comunicación persistente. Se utiliza para expresar que un par de objetos tienen una relación de dependencia para llevar a cabo su función, de modo que uno de los objetos involucrados está compuesto por el otro. De manera práctica, es posible reconocer asociatividad entre dos objetos A y B si la proposición "A tiene un B" (o viceversa) es verdadera. Por ejemplo: "una computador tiene un disco duro" es verdadero, por tanto un objeto computador tiene una relación de composición con al menos un objeto disco duro.
•
•
• •
Herencia [1] http://msdn.microsoft.com/es-es/library/bb738479.aspx
La herencia permite derivar un tipo de entidad de otro tipo de entidad en Entity Data Model (EDM). Por ejemplo, los tipos Employee y Customer pueden heredar del tipo Contact. En este caso, Contact se conoce como tipo base. Employee y Customer se conocen como tipos derivados. Una relación de herencia se representa en la superficie de diseño como una línea que conecta el tipo base y el tipo derivado. El conector tiene una flecha hueca en el extremo que señala al tipo base. •
Multiplicidad
•
Las asociaciones representan relaciones estructurales entre las clases, ellas se representan en UML con una línea. Las asociaciones pueden ser binarias, terciarias o de mayor aridad. Las asociaciones n-arias generalmente se representan promoviendo la asociación al rango de clase y agregando una restricción que expresa que las múltiples ramas se instancian todas simultáneamente, Las asociaciones pueden llevar un nombre, en itálicas y que normalmente se expresa en forma activa, i.e. trabaja para, o en forma pasiva, i.e. es empleado por. En ambos casos se puede indicar el sentido de lectura con < ó >. Así también, se pueden expresar los roles al extremo de las asociaciones y la multiplicidad de las mismas expresadas como: 1: sólo uno; 0..1: cero o uno; 0..*: de cero a muchos; 1..*: de uno a muchos. Ellas también pueden llevar
restricciones entre paréntesis: {ordenado}, {subconjunto}, {exclusivo}, etc. como lo muestra la figura 8 . También pueden existir su asociaciones o asociación reflexiva, de una clase con ella misma; y pueden calificarse las asociaciones para seleccionar un subconjunto de objetos que participan en la asociación por medio de una clave, simple o compuesta, que pertenece a la asociación y no a la clase.
-Clases La forma más sencilla de entender el concepto de clase es si la vemos como una agrupación de objetos con características similares. Por ejemplo, un auto ES UN tipo particular de vehículo motorizado, con lo cual dentro de su comportamiento podemos encontrar “arrancar” y “frenar”, entre otros. Ahora bien, una motocicleta también ES UN vehículo motorizado, y tiene dentro de su comportamiento “arrancar” y “frenar”. El conjunto de atributos también es compartido entre una motocicleta y un automóvil, aunque sus valores no coincidan necesariamente. Por ejemplo, ambos tienen el atributo “cantidad de ruedas”, sólo que el auto tiene 4 y la motocicleta 2. Que es: Una clase es una descripción de un grupo de objetos con: Propiedades en común (atributos) Comportamiento similar (operaciones) La misma forma de relacionarse con otros objetos
(relaciones) Una semántica en común (significan lo mismo) Una clase es una abstracción que: Enfatiza las características relevantes Suprime otras características (simplificación) Un objeto es una instancia de una clase
○ Métodos: ○ [2] http://gencervel.wordpress.com/2008/04/29/programacion -orientada-a-objetos-metodos/
• •
conjunto de instrucciones a las que se les asocia un nombre de modo que si se desea ejecutarlas, sólo basta o referenciarlas a través de dicho nombre en vez de tener que escribirlas. Dentro de estas instrucciones es posible acceder con total libertad a la información almacenada en los campos, pertenecientes a la clase dentro de la que el método se ha definido. Por lo que los métodos permiten manipular los datos almacenados en los objetos Sobre Escritura: [3] http://www.ciberia.ya.com/alexjimenez/PrograI /Programacion_orientada_a_objetos_parte_II.p df La clase derivada puede alterar el comportamiento de uno o más métodos y Propiedades de la clase base. _ Se requiere que se modifique ligeramente el código tanto en la clase base como en la clase derivada para poder hacer esto. Por ejemplo: Supongamos que tenemos un método imprimir() en la clase base ‘DocFiscales’ que contiene código genérico para cualquier documento fiscal, pero Que en la clase derivada ‘CreditoFiscal’ se encuentra un método imprimir() que Se encarga de imprimir un formato que es específico para un Crédito Fiscal. • •
• • •
• • • • •
•
•
•
•
Sobre Carga: • [4] http://www.elguille.info/NET/dotnet/POO_VB_N ET_tp6.htm Una de las características que también nos ofrece los lenguajes orientados a objetos es la posibilidad de definir varias funciones de las clases con un mismo nombre, de esta forma, podremos crear versiones diferentes, por ejemplo para que reciban argumentos de distintos tipos sin necesidad de cambiarle el nombre. Supongamos que queremos hacer una función que realice cualquier tipo de operación sobre dos valores numéricos, sería lógico pensar que si esos valores son de tipo entero, el resultado que devuelva la función también debería ser de tipo entero, en caso de que los valores a usar en la operación son de tipo flotante, el resultado podría devolverlo de ese mismo tipo. En los lenguajes no orientado a objetos, tendríamos que crear dos funciones con nombres diferentes, por ejemplo: sumaInt y sumaFloat. Pero la sobrecarga nos permite crear dos funciones que se llamen suma y el compilador utilizará la adecuada según el tipo de datos que pasemos como argumentos.
•
El único requisito para poder crear sobrecargas de métodos es que las diferentes versiones se diferencien en los argumentos, ya sea porque sean de diferentes tipos de datos o porque el número de argumentos usados sea diferente, de esa forma el compilador no tendrá ningún problema en saber cual debe usar en cada ocasión. La sobrecarga la podemos aplicar tanto a los constructores como a cualquier otro método de la clase. ○ Atributos: ○ [5]http://es.wikipedia.org/wiki/Programaci%C3%B3n_orien tada_a_objetos
Contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método. ○ Propiedades ○ Objetos ○ [7]http://es.wikipedia.org/wiki/Objetos_(programaci%C3 %B3n_orientada_a_objetos) En el paradigma de programación orientada a objetos (POO, o bien OOP en inglés), un objeto se define como la unidad que en tiempo de ejecución realiza las tareas de un programa. También a un nivel más básico se define como la instancia de una clase. Estos objetos interactúan unos con otros, en contraposición a la visión tradicional en la cual un programa es una colección de subrutinas (funciones o procedimientos), o simplemente una lista de instrucciones para el computador. Cada objeto es capaz de recibir mensajes, procesar datos y enviar mensajes a otros objetos de manera similar a un servicio. En el mundo de la programación orientada a objetos (POO), un objeto es el resultado de la instanciación de una clase. Una clase es el anteproyecto que ofrece la funcionalidad en ella definida, pero ésta queda implementada sólo al crear una instancia de la clase, en la forma de un objeto. Por ejemplo: dado un plano para construir sillas (una clase de nombre clase silla), entonces una silla concreta, en la que podemos sentarnos, construida a partir de este plano, sería un objeto de clase silla. Es posible crear (construir) múltiples objetos (sillas) utilizando la definición de la clase (plano) anterior. Los conceptos de clase y objetos son análogos a los de tipo de datos y variable, es decir, definida una clase podemos crear objetos de esa clase, igual que disponiendo de un determinado tipo de dato (por ejemplo el tipo entero), podemos definir variables de dicho tipo ○ Mensaje ○ [8]http://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos Una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó ○
Interfaz
[9] http://www.elguille.info/NET/dotnet/POO_VB_NET_tp6.htm Cuando hablamos de polimorfismo, ineludiblemente tenemos que hablar de las interfaces, ya que, principalmente, nos posibilita utilizar esta característica de la POO. La pregunta es: ¿qué es una interfaz? Aquí no hablamos de "interfaces de usuario", es decir, lo que se mostrará al usuario de nuestra aplicación, sino a una clase especial en la que solamente se definen los métodos y propiedades que una clase que la implemente debe codificar. Las interfaces representan un contrato, de forma que cualquier clase que la implemente debe utilizar los miembros de la interfaz usando la misma forma en que ésta la ha descrito: mismo número de argumentos, mismo tipo de datos devuelto, etc. Gracias a la implementación de interfaces podemos crear relaciones entre clases que no estén derivadas de la misma clase base, pero que tengan métodos comunes, al menos en la forma, aunque no necesariamente en el fondo. Anteriormente usamos el ejemplo del método Guardar, este método se puede definir en una interfaz, las clases que quieran implementar un método Guardar "estandarizado" firmarán un contrato con la interfaz que lo especifica, aunque la forma interna de funcionamiento solo atañe al programador de la clase, lo importante es saber que cualquier clase que haya firmado ese contrato tendrá que seguir las condiciones impuestas por la interfaz, de esta forma todas las clases tendrán un método Guardar "compatible", aunque, tal como mostramos antes, cómo se realice esa acción de guardar no debe preocuparnos, simplemente nos fiaremos de que se ha implementado adecuadamente para almacenar los datos que la clase manipula.