HERENCIA

Una vez que hemos visto el concepto de clase y el de objeto, estamos en condiciones de

introducir otra de las características básicas de la programación orientada a objetos: el

uso de la herencia.

El mecanismo de herencia permite definir nuevas clases partiendo de otras ya

existentes. Las clases que derivan de otras heredan automáticamente todo su

comportamiento, pero además pueden introducir características particulares propias que

las diferencian.

Definición de la clase

“bicicleta”

OBJETOS O INSTANCIAS DE LA CLASE BICICLETAS 11

Como hemos visto, los objetos se definen a partir de clases. Con el mero hecho de

conocer a qué clase pertenece un objeto, ya se sabe bastante sobre él. Puede que no

sepamos lo que es la “Espada”, pero si nos dicen que es una bicicleta, ya sabremos que

tiene dos ruedas, manillar, pedales...

La programación orientada a objetos va más allá, permitiéndonos definir clases a partir

de otras clases ya construidas. Por ejemplo, las bicicletas de montaña, las de carretera y

los tándems son todos, en definitiva, bicicletas. En términos de programación orientada

a objetos, son subclases o clases derivadas de la clase bicicleta. Análogamente, la clase

bicicleta es la clase base o superclase de las bicicletas de montaña, las de carretera y los

tándems. Esta relación se muestra en la siguiente figura.

Cada subclase hereda los estados (en forma de declaración de variables) de la superclase

de la cual deriva. Las bicicletas de montaña, las de carretera y los tándems comparten

algunos estados: cadencia, velocidad... Además, cada subclase hereda los métodos de su

superclase.

LA HERENCIA EN LA PROG. ORIENTADA A OBJETOS12

Las bicicletas de montaña, las de carretera y los tándems comparten algunos

comportamientos: frenar y cambiar la cadencia de pedaleo, por ejemplo.

Sin embargo, las clases derivadas no se encuentran limitadas por los estados y

comportamientos que heredan de su superclase. Muy al contrario, estas subclases

pueden añadir variables y métodos a aquellas que han heredado. Los tándems tienen dos

asientos y dos manillares; algunas bicicletas de montaña tienen una catalina adicional

con un conjunto de marchas con relaciones de transmisión mucho más cortas. Las clases

derivadas pueden incluso sobrescribir los métodos heredados y proporcionar

implementaciones más especializadas para esos métodos. Por ejemplo, si nuestra

bicicleta de montaña tuviera una catalina extra, podríamos sobrescribir el método

“CambiarDeMarcha” para poder usar esas nuevas marchas.

Además, no estamos limitados a un único nivel de herencia. El árbol de herencias o

jerarquía de clases puede ser tan extenso como necesitemos. Los métodos y las variables

miembro se heredarán hacia abajo a través de todos los niveles de la jerarquía.

Normalmente, cuanto más abajo está una clase en la jerarquía de clases, más

especializado es su comportamiento. En nuestro ejemplo, podríamos hacer que la clase

bicicleta derivase de una superclase de vehículos.

La herencia es una herramienta clave para abordar la resolución de un problema de

forma organizada, pues permite definir una relación jerárquica entre todos los conceptos

que se están manejando. Es posible emplear esta técnica para descomponer un problema

de cierta magnitud en un conjunto de problemas subordinados a él. La resolución del

problema original se consigue cuando se han resuelto cada uno de los problemas

subordinados, que a su vez pueden contener otros. Por consiguiente, la capacidad de

descomponer un problema o concepto en un conjunto de objetos relacionados entre sí

cuyo comportamiento es fácilmente identificable puede ser extraordinariamente útil

para el desarrollo de programas informáticos.

La herencia proporciona las siguientes ventajas:

Las clases derivadas o subclases proporcionan comportamientos especializados a

partir de los elementos comunes que hereda de la clase base. A través del 13

mecanismo de herencia los programadores pueden reutilizar el código de la

superclase tantas veces como sea necesario.

Los programadores pueden implementar las llamadas superclases abstractas, que

definen comportamientos genéricos. Las clases abstractas definen e

implementan parcialmente comportamientos, pero gran parte de estos

comportamientos no se definen ni se implementan totalmente. De esta forma,

otros programadores pueden hacer uso de estas superclases detallando esos

comportamientos con subclases especializadas. El propósito de una clase

abstracta es servir de modelo base para la creación de otras clases derivadas,

pero cuya implantación depende de las características particulares de cada una

de ellas. Un ejemplo de clase abstracta podría ser en nuestro caso la clase

vehículos. Esta clase sería una clase base genérica, a partir de la cual podríamos

ir creando todo tipo de clases derivadas.

¿QUÉ ES UNA CLASE?

Normalmente en el mundo real existen varios objetos de un mismo tipo, o como

diremos enseguida, de una misma clase. Por ejemplo, mi bicicleta es una de las muchas

bicicletas que existen en el mundo. Usando la terminología de la programación

orientada a objetos, diremos que mi bicicleta es una instancia de la clase de objetos

conocida como bicicletas. Todas las bicicletas tienen algunos estados o atributos (color,

marcha actual, cadencia actual, dos ruedas) y algunos métodos (cambiar de marcha,

frenar) en común. Sin embargo, el estado particular de cada bicicleta es independiente

del estado de las demás bicicletas. La particularización de estos atributos puede ser

diferente. Es decir, una bicicleta podrá ser azul, y otra roja, pero ambas tienen en común

el hecho de tener una variable “color”. De este modo podemos definir una plantilla de

variables y métodos para todas las bicicletas. Las plantillas para crear objetos son

denominadas clases.

Una clase es una plantilla que define las variables y los métodos que son comunes para

todos los objetos de un cierto tipo.

En nuestro ejemplo, la clase bicicleta definiría variables miembro comunes a todas las

bicicletas, como la marcha actual, la cadencia actual, etc. Esta clase también debe

declarar e implementar los métodos o funciones miembro que permiten al ciclista

cambiar de marcha, frenar, y cambiar la cadencia de pedaleo, como se muestra en la

siguiente figura:

¿QUÉ ES UN OBJETO?

Un objeto no es más que un conjunto de variables (o datos) y métodos (o funciones)
relacionados entre sí. Los objetos en programación se usan para modelar objetos o
entidades del mundo real (el objeto hijo, madre, o farmacéutica, por ejemplo). Un objeto
es, por tanto, la representación en un programa de un concepto, y contiene toda la
información necesaria para abstraerlo: datos que describen sus atributos y operaciones
que pueden realizarse sobre los mismos. La siguiente figura muestra una representación
visual de un objeto.
Representación visual de un objeto 6
Los atributos del objeto (estado) y lo que el objeto puede hacer (comportamiento) están
expresados por las variables y los métodos que componen el objeto respectivamente.
Por ejemplo, un objeto que modelase una bicicleta en el mundo real tendría variables
que indicararían el estado actual de la bicicleta: su velocidad es de 20 km/h, su cadencia
de pedaleo 90 r.p.m. y su marcha actual es la 5ª. Estas variables se conocen
formalmente como variables instancia o variables miembro porque contienen el estado
de un objeto bicicleta particular y, en programación orientada a objetos, un objeto
particular se denomina una instancia.
Además de estas variables, el objeto bicicleta podría tener métodos para frenar, cambiar
la cadencia de pedaleo, y cambiar de marcha (la bicicleta no tendría que tener un
método para cambiar su velocidad pues ésta es función de la cadencia de pedaleo, la
marcha en la que está y de si los frenos están siendo utilizados o no, entre otros muchos
factores). Estos métodos se denominan formalmente métodos instancia o métodos
miembro, ya que cambian el estado de una instancia u objeto bicicleta particular. La
siguiente figura muestra una bicicleta modelada como un objeto:

El diagrama del objeto bicicleta muestra las variables objeto en el núcleo o centro del
objeto y los métodos rodeando el núcleo y protegiéndolo de otros objetos del programa.
Este hecho de empaquetar o proteger las variables miembro con los métodos miembro
se denomina encapsulación. Este dibujo conceptual que muestra el núcleo de variables
miembro del objeto protegido por una membrana protectora de métodos o funciones
miembro es la representación ideal de un objeto y es el ideal que los programadores de
Bicicleta modelada como
un objeto:
Atributos:

Velocidad

Cadencia

Marcha
Métodos:

Cambiar marcha

Frenar

Cambiar cadencia7
objetos suelen buscar. Sin embargo, debemos matizarlo. A menudo, por razones
prácticas, es posible que un objeto desee exponer alguna de sus variables miembro, o
proteger otras de sus propios métodos o funciones miembro. Por ejemplo, Java permite
establecer 4 niveles de protección de las variables y de las funciones miembro para
casos como éste. Los niveles de protección determinan qué objetos y clases pueden
acceder a qué variables o a qué métodos.
De cualquier forma, el hecho de encapsular las variables y las funciones miembro
relacionadas proporciona dos importantes beneficios a los programadores de
aplicaciones:

Capacidad de crear módulos: El código fuente de un objeto puede escribirse y
mantenerse independiente del código fuente del resto de los objetos. De esta
forma, un objeto puede pasarse fácilmente de una parte a otra del programa.
Podemos dejar nuestra bicicleta a un amigo, y ésta seguirá funcionando.

Protección de información: Un objeto tendrá una interfaz pública
perfectamente definida que otros objetos podrán usar para comunicarse con él.
De esta forma, los objetos pueden mantener información privada y pueden
cambiar el modo de operar de sus funciones miembros sin que esto afecte a otros
objetos que usen estas funciones miembro. Es decir, no necesitamos entender
cómo funciona el mecanismo de cambio de marcha para hacer uso de él.

Introducimos para los más profanos las bases sobre las que se asienta la Programación Orientada a Objetos.

La programación Orientada a objetos (POO) es una forma especial de programar, más cercana a como expresaríamos las cosas en la vida real que otros tipos de programación.

Con la POO tenemos que aprender a pensar las cosas de una manera distinta, para escribir nuestros programas en términos de objetos, propiedades, métodos y otras cosas que veremos rápidamente para aclarar conceptos y dar una pequeña base que permita soltarnos un poco con este tipo de programación.

Motivación

Durante años, los programadores se han dedicado a construir aplicaciones muy parecidas que resolvían una y otra vez los mismos problemas. Para conseguir que los esfuerzos de los programadores puedan ser utilizados por otras personas se creó la POO. Que es una serie de normas de realizar las cosas de manera que otras personas puedan utilizarlas y adelantar su trabajo, de manera que consigamos que el código se pueda reutilizar.

La POO no es difícil, pero es una manera especial de pensar, a veces subjetiva de quien la programa, de manera que la forma de hacer las cosas puede ser diferente según el programador. Aunque podamos hacer los programas de formas distintas, no todas ellas son correctas, lo difícil no es programar orientado a objetos sino programar bien. Programar bien es importante porque así nos podemos aprovechar de todas las ventajas de la POO.

Cómo se piensa en objetos

Pensar en términos de objetos es muy parecido a cómo lo haríamos en la vida real. Por ejemplo vamos a pensar en un coche para tratar de modelizarlo en un esquema de POO. Diríamos que el coche es el elemento principal que tiene una serie de características, como podrían ser el color, el modelo o la marca. Además tiene una serie de funcionalidades asociadas, como pueden ser ponerse en marcha, parar o aparcar.

Pues en un esquema POO el coche sería el objeto, las propiedades serían las características como el color o el modelo y los métodos serían las funcionalidades asociadas como ponerse en marcha o parar.

Por poner otro ejemplo vamos a ver cómo modelizaríamos en un esquema POO una fracción, es decir, esa estructura matemática que tiene un numerador y un denominador que divide al numerador, por ejemplo 3/2.

La fracción será el objeto y tendrá dos propiedades, el numerador y el denominador. Luego podría tener varios métodos como simplificarse, sumarse con otra fracción o número, restarse con otra fracción, etc.

Estos objetos se podrán utilizar en los programas, por ejemplo en un programa de matemáticas harás uso de objetos fracción y en un programa que gestione un taller de coches utilizarás objetos coche. Los programas Orientados a objetos utilizan muchos objetos para realizar las acciones que se desean realizar y ellos mismos también son objetos. Es decir, el taller de coches será un objeto que utilizará objetos coche, herramienta, mecánico, recambios, etc.

Clases en POO

Las clases son declaraciones de objetos, también se podrían definir como abstracciones de objetos. Esto quiere decir que la definición de un objeto es la clase. Cuando programamos un objeto y definimos sus características y funcionalidades en realidad lo que estamos haciendo es programar una clase. En los ejemplos anteriores en realidad hablábamos de las clases coche o fracción porque sólo estuvimos definiendo, aunque por encima, sus formas.

Propiedades en clases

Las propiedades o atributos son las características de los objetos. Cuando definimos una propiedad normalmente especificamos su nombre y su tipo. Nos podemos hacer a la idea de que las propiedades son algo así como variables donde almacenamos datos relacionados con los objetos.

Métodos en las clases

Son las funcionalidades asociadas a los objetos. Cuando estamos programando las clases las llamamos métodos. Los métodos son como funciones que están asociadas a un objeto.

Objetos en POO

Los objetos son ejemplares de una clase cualquiera. Cuando creamos un ejemplar tenemos que especificar la clase a partir de la cual se creará. Esta acción de crear un objeto a partir de una clase se llama instanciar (que viene de una mala traducción de la palabra instace que en inglés significa ejemplar). Por ejemplo, un objeto de la clase fracción es por ejemplo 3/5. El concepto o definición de fracción sería la clase, pero cuando ya estamos hablando de una fracción en concreto 4/7, 8/1000 o cualquier otra, la llamamos objeto.

Para crear un objeto se tiene que escribir una instrucción especial que puede ser distinta dependiendo el lenguaje de programación que se emplee, pero será algo parecido a esto.

miCoche = new Coche()

Con la palabra new especificamos que se tiene que crear una instancia de la clase que sigue a continuación. Dentro de los paréntesis podríamos colocar parámetros con los que inicializar el objeto de la clase coche.

Estados en objetos

Cuando tenemos un objeto sus propiedades toman valores. Por ejemplo, cuando tenemos un coche la propiedad color tomará un valor en concreto, como por ejemplo rojo o gris metalizado. El valor concreto de una propiedad de un objeto se llama estado.

Para acceder a un estado de un objeto para ver su valor o cambiarlo se utiliza el operador punto.

miCoche.color = rojo

El objeto es miCoche, luego colocamos el operador punto y por último el nombre e la propiedad a la que deseamos acceder. En este ejemplo estamos cambiando el valor del estado de la propiedad del objeto a rojo con una simple asignación.

Mensajes en objetos

Un mensaje en un objeto es la acción de efectuar una llamada a un método. Por ejemplo, cuando le decimos a un objeto coche que se ponga en marcha estamos pasándole el mensaje “ponte en marcha”.

Para mandar mensajes a los objetos utilizamos el operador punto, seguido del método que deseamos invocar.

miCoche.ponerseEnMarcha()

En este ejemplo pasamos el mensaje ponerseEnMarcha(). Hay que colocar paréntesis igual que cualquier llamada a una función, dentro irían los parámetros.

Otras cosas

Hay mucho todavía que conocer de la POO ya que sólo hemos hecho referencia a las cosas más básicas. También existen mecanismos como la herencia y el polimorfismo que son unas de las posibilidades más potentes de la POO.

La herencia sirve para crear objetos que incorporen propiedades y métodos de otros objetos. Así podremos construir unos objetos a partir de otros sin tener que reescribirlo todo.

El polimorfismo sirve para que no tengamos que preocuparnos sobre lo que estamos trabajando, y abstraernos para definir un código que sea compatible con objetos de varios tipos.

Son conceptos avanzados que cuesta explicar en las líneas de ese informe. No hay que olvidar que existen libros enteros dedicados a la POO y aquí solo pretendemos dar un repaso a algunas cosas para que os suenen cuando tengáis que poneros delante de ellas en los lenguajes de programación que debe conocer un desarrollador del web.

Ejemplo concreto de programación orientada a objetos

Para conseguir un ejemplo concreto de lo que es la programación orientada a objetos, podemos entrar en elManual de PHP 5. Realmente este manual explica las características de orientación a objetos de PHP 5 y ofrece ejemplos concretos de creación de clases con características como herencia, polimorfismo, etc.

ARQUITECTURA 3 CAPAS PROGRAMACIÓN POR CAPAS

Es un estilo de programación, su objetivo primordial es la separación de la capa de presentación, capa de negocio y la capa de datos.

La arquitectura de una aplicación es la vista conceptual de la estructura de esta. Toda aplicación contiene código de presentación, código de procesamiento de datos y código de almacenamiento de datos. La arquitectura de las aplicaciones difieren según como esta distribuido este código.

Windows DNA presenta una arquitectura de aplicaciones de tres-capas, basadas en componentes. La meta de DNA es unificar las aplicaciones para PC, las aplicaciones cliente / servidor y las aplicaciones basadas en la Web, lo cual es posible para aplicaciones de cualquier tamaño.
En nuestros días mucha información importante está almacenada en aplicaciones como sistemas de correo electrónico, y aún más recientemente en servicios de directorio. Microsoft habla sobre Universal Data Access (Acceso Universal a Datos) como una serie de manejadores e interfaces diseñadas para proveer una forma de conseguir acceder a este tipo de almacenamientos y más aún a datos como archivos de formato especiales, datos de posición geoespacial, datos científicos no estándar, etc. Los servicios son puestos en la red y operan de manera cooperativa para dar soporte a uno o más procesos de negocios. En este modelo, una aplicación se convierte en un conjunto de servicios de usuario, negocios y datos que satisface las necesidades de los procesos de negocios o procesa su soporte. Como los servicios están diseñados para el uso general y siguen lineamientos de interfaz publicados, pueden ser reutilizados y compartidos entre múltiples aplicaciones. La arquitectura DNA de tres capas como se muestra en el grafico cuenta con servicios específicos en cada capa que se comunican entre si mediante COM (Component Object Model)

Arquitectura de Capas

Preguntar qué conocen por arquitectura de capas (en Sistemas de Operación, Redes de Computadores...).

Nos limitaremos a manejar la noción de arquitectura como una forma de estructurar los elementos de un software.

En toda arquitectura de capa los elementos agrupados en una misma capa pueden comunicarse entre si; pero existen variantes en cuanto a las comunicaciones permitidas entre elementos de capas diferentes:

1. Arquitectura top-down de capas:

Los elementos de una capa i+1 pueden enviar solicitudes de servicio a elementos de la capa inferior i. Típicamente se produce una cascada de solicitudes, es decir para satisfacer una solicitud a una capa i+2, ésta requiere enviar varias solicitudes a la capa i+1; cada una de estas solicitudes a la capa i+1 genera a su vez un conjunto de solicitudes a la capa i y así sucesivamente. Una arquitectura top-down es laxa (o no estricta) si los elementos de una capa i+1 pueden enviar solicitudes de servicio directamente a un elemento de cualquiera de las i capas inferiores.

2. Arquitectura bottom-up de capas:

Cada elemento de una capa i puede notificar a elementos de la capa superior i+1 de que ha ocurrido algún evento de interés (ej. manejadores de dispositivos). La capa i+1 puede juntar varios eventos antes de notificar a su vez an elemento de la capa i+2. Una arquitectura bottom-up tambien puede ser no estricta si el elemento de la capa i puede notificar a cualquier elemento de cualquier capa superior a la capa i.

3. Arquitectura bidireccional de capas

En su forma más común involucra dos pilas de N capas que se comunican entre si. El ejemplo más conocido es el de los protocolos en Redes de Computadores.

Al implementar una arquitectura top-down de capas, se deben tomar en cuenta los siguientes factores:

1. ¿Cuál es el criterio de abstracción para agrupar servicios/clases en una capa?

Mencionar el criterio Presentación-Dominio de Aplicación-Repositorio de Sistemas de Información.

2. Determinar el número de capas

En términos simplistas, a más capas más flexibilidad pero menor desempeño. [Discutir]

3. Típicamente las capas más internas ofrecen menos servicios.

Esto ayuda la reutilización de capas ("pirámide invertida de reuso").

4. El grado de encapsulamiento de las capas.

A mayor encapsulamiento, menor dependencia externa sobre la estructura de una capa.

5. Estructura interna de cada capa.


6. ¿Cuánta información pasar de una capa a otra?

Tomemos el caso de la arquitectura top-down. Es muy posible que, de acuerdo con el tipo de servicio solicitado, la capa inferior requiera una cantidad de información variable. En un modelo puro "empujado" (push), la capa superior está obligada a enviarle toda la información que pueda llegar a hacerle falta a la capa inferior en la solicitud.

Esto no siempre es posible (piense por ejemplo en una solicitud de servicio a una base de datos que no logra completarse por estar fuera de línea. ¿Qué se hace: reintentar, abandonar, usar una fuente alterna?).

En el modelo contrario, "halado" (pull o por demanda), la capa inferior solicita mayor información sólo si le hace falta --¿pero de quién la pida? El modelo de solicitudes top-down presupone un invocador anónimo y un invocado conocido.

La solución la proporciona el patrón Editorial-Suscriptor (Publish-Subscribe) que encapsula la idea del callback. Este patrón de diseño lo estudiaremos más adelante.


7. Diseñe la estrategia de manejo de errores.

Este es un aspecto que es frecuentemente obviado, aunque tiene impacto fuerte tanto en el tiempo de procesamiento como en el esfuerzo de programación. Típicamente se recomienda manejar el error en el nivel que lo descubrió, si esto no es posible, dejar que lo resuelva la capa más arriba, pero generalmente abstrayendo el tipo de error para que sea comprensible en término de los servicios de la capa superior.

Todo patrón tiene ventajas y desventajas: en el caso de la arquitectura de capas ya las hemos mencionado [dejar que los estudiantes las resuman]:

• Ventajas
• Reutilización de capas;
• Facilita la estandarización
• Dependencias se limitan a intra-capa
• Contención de cambios a una o pocas capas
• Desventajas
• A veces no se logra la contención del cambio y se requiere una cascada de cambios en varias capas;
• Pérdida de eficiencia;
• Trabajo innecesario por parte de capas más internas o redundante entre varias capas;
• Dificultad de diseñar correctamente la granularidad de las capas.

Arquitectura de capas en Sistemas de Información

Existen tres propuestas de arquitecturas de capas para Sistemas de Información, donde las capas a veces reciben el nombre de niveles (en Inglés tiers):

• Arquitectura de dos capas;
• Arquitectura de tres capas;
• Arquitectura de cuatro capas.

Las diferencias entre estas arquitecturas las pospondremos hasta que nos corresponda estudiar el proceso de diseño de un software. Por los momentos, seguiremos RPM en presuponer que apuntamos a una arquitectura de tres capas.