Adapter

Este articulo no posee mayor grado de complejidad ya que el

enfoque del patrn es muy simple as como el ejemplo que vamos
a realizar.
Supongamos que tenemos un sistema que trabaja con diferentes
tipos de motores (Comn, Econmico) que comparten
caractersticas comunes as como su funcionamiento, se desea
vincular al sistema una clase de tipo motor Elctrico con un
funcionamiento diferente al de los dems, se debe adaptar la
nueva clase sin que esto afecte la lgica inicial de la aplicacin...

La Solucin.

Ya que nos plantean vincular un nuevo motor totalmente diferente

al resto de motores definido en el sistema, entonces deducimos
que si bien es un motor no puede tener un tratamiento igual al de
los dems, ya que el modo de encenderlo, ponerlo en
funcionamiento y hasta apagarlo podra ser muy distinto y podra
afectar la lgica establecida, como no podemos modificar
bruscamente nuestro cdigo entonces utilizaremos el
patrn Adapter para dar solucin a nuestra problemtica....

Como vemos nuestro sistema gira en torno a los motores,

utilizamos la herencia para compartir funcionalidades comunes
para los diferentes tipos de motores con los que trabajaremos, sin
embargo evidenciamos que no todos ellos se comportan de la
misma manera como es el caso del Motor Elctrico, por tal razn
no podemos ponerlo a heredar directamente de la clase Motor, ya
que los mtodos que esta nos provee no serian tiles para esta
clase....
En este punto es donde hacemos uso de una clase Adapter que
servira de puente entre la clase Padre y La Clase que debe ser
adaptada, as este adaptador seria el encargado de establecer
comunicacin con el motor Elctrico y ejecutar las solicitudes que
el cliente realice...
Clase Motor.
Esta clase es desde la cual heredaran los diferentes tipos de motores,
provee los mtodos comunes (encender, acelerar, apagar) para el
funcionamiento de los mismos.
Motores Comn y Econmico.

Esta clase representa la estructura de los motores normales con los

que el sistema funciona, bsicamente heredan de la clase Motor y
realizan el funcionamiento bsico que esta provee.
Clase MotorElectricoAdapter.

Aqu se establece el puente por medio del cual la clase incompatible

puede ser utilizada, hereda de la clase Motor y por medio de la
implementacin dada , realiza la comunicacin con la clase a adaptar
usando para esto una instancia de la misma...
Clase MotorElectrico.

Esta es la clase adaptable, como vemos a pesar de ser un motor

posee caractersticas muy diferentes a los dems tipos de motores del
sistema, por lo tanto no puede heredar directamente de la clase
Motor, en vez de esto, es accedida por la clase Adapter...
Clase Aplicacin.

Finalmente esta clase representa el Cliente del

sistema que usa los diferentes tipos de motores, como vemos desde
aqu se hacen los llamados sin importar cual es la lgica detrs de
estos, por medio del patrn Adapter llamamos a los
mismos mtodos encender(), acelerar() o apagar(), siendo
transparente el proceso interno que se realiza...... podemos
evidenciar tambin como se utiliza el polimorfismo para hacer este
tipo de llamados.....

COMPOSITE
El patrn Composite se aleja un poco de la lnea tradicional de los patrones vistos
hasta ahora, ya que rompe uno de los principios de la programacin orientada a
objetos: una clase, una responsabilidad. En realidad, los ms puristas pueden
decidir no hacerlo, pero el precio a pagar es demasiado alto para los ingenieros
mortales: la simplicidad del modelo.

Cuando diseamos debemos tener claro que la idea principal es alcanzar un

equilibrio entre muchos factores como por ejemplo presupuesto, usabilidad y
facilidad para que nuestro cdigo sea reutilizable y pueda ser fcilmente mantenible
en un futuro.

PARA PRODUCTOPESO Y PRODUCTOUNITARIO

Los mtodos add, remove y getElemento no se sobrecargarn, ya que

el nodo hoja no estar compuesto por ms elementos que l mismo.

Por tanto, si se invocan estos mtodos, se llamar el mtodo padre

que lanzar una excepcin de tipo NotSupportedException

Seguramente, a estas alturas ya nos habremos dado cuenta de lo que

comentbamos al principio del artculo respecto a la ruptura del principio de
responsabilidad nica. Las clases productoPeso y productoUnitario implementa un
conjunto de mtodos, pero deja otro conjunto sin implementar (los mtodos add,
remove y getpRODUCTOS), que lanzarn una excepcin si te utilizan. Esos mtodos
sern implementados por la siguiente clase: PRODUCTO COMPUESTO

PARA PRODUCTO COMPUESTO

En esta primera etapa, hemos codificado la parte que se encarga de aadir,

eliminar y consultar otros elementos. El mtodo es sencillo: a travs de un ArrayList
interno, los mtodos add, remove y getElemento realizarn operaciones sobre l.

A continuacin codificaremos los mtodos get que recuperarn el contenido de los

atributos de cada productoPeso y productoUnitario: peso, precioPorPeso, nombre,
categoria. Para ello iteraremos sobre los elementos contenidos dentro de
cada productoCompuesto.

El importeTotal de producto compuesto, sin ir ms lejos, se calcular a partir de

cuanto a sido el precio total de los productos contenidos en cada productoPeso y
productoUnitario, que se sumar al precio del propio componente.

Recorriendo todos los productos contenidos dentro de cada productoCompuesto

podremos obtener la informacin almacenada tanto en un objeto nodo
(productoCompuesto) como en un objeto hoja (productoPeso y productoUnitario).
Ambos se tratarn de la misma manera, aunque la implementacin de los mtodos
sea distinta. Y dado que ambos objetos son intercambiables, estamos consiguiendo
lo que declaramos en primera instancia: componer objetos de forma arborescente
respetando la jerarqua todo-parte permitiendo que ambos elementos se traten de
forma uniforme.

Purismo vs. Transparencia

Nos acabamos de encontrar con el primer patrn que viola deliberadamente uno de
los principios de la programacin orientada a objetos. El motivo ha sido que el
incremento en la transparencia (y usabilidad) es tan importante que merece la pena
el sacrificio de permitir que una clase adquiera ms de una responsabilidad.
Recordemos que los patrones de diseo son soluciones genricas a problemas
concretos, por lo que su objetivo es la de facilitar el desarrollo de software. Hay
ocasiones, por tanto, en las que las que las ventajas de romper las normas
sobrepasan de largo seguirlas a rajatabla.

Recorrido de arboles de forma recursiva

se refiere al proceso de visitar de una manera sistemtica, exactamente una vez, cada
nodo en una estructura de datos de rbol (examinando y/o actualizando los datos en los
nodos). Tales recorridos estn clasificados por el orden en el cual son visitados los nodos.
Los siguientes algoritmos son descritos para un rbol binario.
las estructuras arborescentes pueden ser recorridas de muchas maneras diferentes.
Comenzando en la raz de un rbol binario, hay tres pasos principales que pueden ser
realizados y el orden en la cual son realizados define el tipo de recorrido
Preorden

1. Visite la raz

2. Atraviese el sub-rbol izquierdo

3. Atraviese el sub-rbol derecho

Inorden

1. Atraviese el sub-rbol izquierdo

2. Visite la raz

3. Atraviese el sub-rbol derecho

Postorden

1. Atraviese el sub-rbol izquierdo

2. Atraviese el sub-rbol derecho

3. Visite la raz

As el proceso ms fcilmente descrito a travs de la recursin.