Strategy

Hoy voy a hablaros del patrón Strategy, un patrón de comportamiento que permite definir un algoritmo pero delegar la implementación de algunas partes de dicho algoritmo a otras clases. De esta forma se consigue mucha portabilidad, ya que permite adaptar el algoritmo al entorno en el que se ejecuta en tiempo de ejecución. Por ejemplo, si el algoritmo muestra información por pantalla, es interesante que esa parte del algoritmo pueda disponer de diferentes implementaciones, para poder imprimir tanto por consola como en un dispositivo Android.

Diagrama UML

El diagrama UML del patrón Strategy es el siguiente:

Como ejemplo podríamos definir en la clase Strategy una interfaz para algoritmos de ordenación, y en las clases concretas se implementaría con distintos métodos como QuickSort o MergeSort. El contexto sería la interfaz del programa principal que contendría una lista a ordenar y la referencia a la clase Strategy.

Ejemplo en Java

Supongamos que estamos diseñando una tienda online y queremos que acepte distintos medios de pago (tarjeta de crédito, Paypal, Bitcoin, etc). Un ejemplo de arquitectura con Strategy sería el siguiente:

En la interfaz se define el método y las subclases que implementan la interfaz definen los distintos métodos de pago. esto permite que en tiempo de ejecución se pueda elegir la clase que se ejecuta. El contexto es la clase ShoppingCart que contiene la referencia al Strategy.

El código completo en Java se encuentra en el siguiente enlace: http://www.journaldev.com/1754/strategy-design-pattern-in-java-example-tutorial

Singleton

Lo prometido es deuda queridos lectores, aquí tenéis el primer artículo de patrones de diseño UML. En el voy a hablar del singleton, un patrón de creación sencillo y muy utilizado, tanto que se llega a abusar de él y eso a menudo acaba generando errores de diseño en la arquitectura del software.

Si es único, es Singleton

Un singleton es una clase que se instancia exactamente una vez y sólo una. Eso no quiere decir que no se pueda usar esa instancia más veces(se puede usar todas las que se quiera como cualquier otra) pero siempre será la misma. Este patrón se suele utilizar para representar objetos que son intrínsecamente únicos, como el sistema de ficheros o el gestor de ventanas.

Una forma de implementación típica es la siguiente: se pone el constructor como privado y final

// Singleton with static factory
public class Elvis {
private static final Elvis INSTANCE = new Elvis();
private Elvis() { ... }
public static Elvis getInstance() { return INSTANCE; }
public void leaveTheBuilding() { ... }
}[

Esta implementación es cómoda y proporciona la funcionalidad que necesitamos, sólo existirá una instancia de la clase. Sin embargo, de esta manera es difícil hacer que el singleton sea serializable, pueden existir problemas de concurrencia y es vulnerable a ataques de reflexión. A partir de la versión 1.5 de Java , existe una implementación todavía mejor, usando los siempre poco valorados tipos enumerados:

// Enum singleton - the preferred approach
public enum Elvis {
INSTANCE;
public void leaveTheBuilding() { ... }
}

Esta implementación es más segura frente a ataques y problemas de concurrencia y es más fácil de serializar, por lo que es la mejor forma de implementar un Singleton.

Singletonitis

Esta peligrosa enfermedad 😛 consiste en el abuso indiscriminado del patrón Singleton, porque como ofrece muchas ventajas y es sencillo de implementar, pues lo utilizamos para todo ¿verdad? y así nos quitamos de problemas. Esto provoca el antipatrón de diseño llamado singletonitis.

El patrón Singleton también tiene sus inconvenientes, aquí expongo algunos:

• Crea problemas con las pruebas y su automatización, especialmente por la alta dependencia del código al tratar de hacer pruebas unitarias.
• Problemas con el threading y concurrencia , aunque se pueden evitar si se implementan usando el tipo enumerado como hemos visto anteriormente.
• Crea una alta dependencia en el código, un alto acoplamiento que es origen de problemas.
• Los factores anteriores pueden llevar a la generación de código ilegible (spaguetti code) y problemas de reusabilidad.

Para prevenir estos problemas es necesario usar el Singleton en su contexto adecuado de representar un objeto único en el modelo de datos, y no usarlo como si fuera la panacea….

Patrones de diseño UML

Queridos lectores, esta semana voy a hablaros de los patrones de diseño UML. Sí, eso de lo que tanto habéis oído hablar pero no tenéis muy claro si merece la pena perder horas en aprender, porque a tu querido jefe sólo le interesa que el código funcione lo antes posible y no si está bien programado, ¿verdad?

Así que antes de poner código para que hagáis copy-paste en vuestro proyecto (que os veo venir) os contaré que son los patrones de diseño, y porque se deben conocer y utilizar.

Conceptos básicos

Según el libro de Erich Gamma, Design Patterns: Elements of Reusable Object-Oriented Software, un Patrón de Diseño es «una solución simple y elegante a un problema específico y común del Diseño Orientado a Objetos (DOO)». El origen de este paradigma es dar solución a los problemas que constantemente se repiten en distintos escenarios de programación, proporcionando una solución común, que resuelva el problema con éxito. Esto no significa que los patrones intenten imponer ciertas formas de diseño frente a otras o reducir la creatividad del proceso de programación, simplemente son un recurso para solucionar problemas comunes del desarrollo de software.

No es obligatorio es uso de patrones a la hora de programar, pero si es muy recomendable, ya que son soluciones contrastadas a problemas conocidos de programación, que evitarán que perdáis tiempo reinventando la rueda en vuestro código.

Los patrones se dividen en tres grupos generales:

1. Patrones de estructura: Se centran en la forma de estructurar las clases
2. Patrones de creación: Resuelven problemas relacionados con la creación de objetos.
3. Patrones de comportamiento: definen soluciones para mejorar el comportamiento de la aplicación, sobre todo en tiempo de ejecución.

Y los patrones que engloban son:

Patrones de estructura

1. Adapter
2. Bridge
3. Composite
4. Decorator
5. Facade
6. Flyweight
7. Proxy

Patrones de creación

1. Abstract factory
2. Factory method
3. Singleton
4. Builder
5. Prototype

Patrones de comportamiento

1. Chain of responsability
2. Command
3. Interpreter
4. Iterator
5. Mediator
6. Memento
7. Observer
8. State
9. Strategy
10. Template method
11. Visitor

En esta imagen podéis ver como se relacionan los distintos patrones entre sí:

¿ Agobiados ? No os preocupéis, en próximas entregas os iré explicando en que consiste cada uno de ellos y expondré ejemplos de implementación.

Antipatrones de diseño

Por último , debéis saber que al igual que existen soluciones contrastadas y buenas prácticas, también existen malas prácticas y métodos que llevan a soluciones incorrectas, conocidas como antipatrones de diseño. La lista de antipatrones es mucho más larga que la de patrones de diseño, y también más divertida.  En éste enlace de la Wikipedia aparecen bastantes muy bien detallados.

Mi experiencia con la OCAJP

Hola  a todos, en mi primer post quería hablaros acerca mi experiencia personal sobre la certificación OCAJP de Oracle que acabo de obtener. Esta certificación es la llave de acceso a cualquier otra certificación de programación Java que oferta Oracle, por lo que podríamos catalogarla como un «must have» para desarrolladores 🙂

Qué es la OCAJP, alias 1Z0-803

Cuando Oracle compró Sun cambió el sistema de certificaciones. Antiguamente la certificación de Java mas conocida era la SCJP (Sun Certified Java Programmer) pero ahora ese examen se ha «partido en dos» . El equivalente al SCJP se llama OCPJP (Oracle Certified Professional Java Programmer), pero es necesario tener el OCAJP (Oracle Certified Associate Java Programmer) para poder examinarse del OCPJP, ya os dije que era un must have xd

Este es el itinerario actual de certificaciones:

y este es el temario de la OCAJP:

1. Java Basics
2. Working With Java Data Types
3. Use Java operators
4. Creating and Using Arrays
5. Using Loop Constructs
6. Working with Methods and Encapsulation
7. Working with Inheritance
8. Handling Exceptions

Podéis encontrar el temario mas detallado en este enlace: http://education.oracle.com/pls/web_prod-plq-dad/db_pages.getpage?page_id=5001&get_params=p_exam_id:1Z0-803&p_org_id=&lang=

Como podéis observar, faltan temas como los genéricos o la concurrencia, que se han dejado para la «segunda parte», el OCPJP. Eso ayuda a que este examen sea mas fácil de aprobar, aunque también tienes que pagar dos exámenes en lugar de uno, Oracle es como la banca del casino, nunca pierde 😛

El código de examen es 1Z0-803, es importante conocerlo para no confundir este examen con otros similares, cada convocatoria cuesta 245$ así que al loro con lo que pedimos xd

El examen consta de 90 preguntas tipo test, y un tiempo de realización de 150 minutos. Algunas preguntas tienen más de una respuesta correcta, pero el enunciado indica el número de opciones a marcar, una ayudita que viene muy bien 🙂 Para aprobar es necesario conseguir un 63% de respuestas correctas, o sea, acertar 58 preguntas de las 90.

Preparación del examen

Para prepararlo existen varios libros en el mercado, en particular yo usé éste:

pero también hay otras alternativas:

Por supuesto, también existen academias que te preparan para este examen, pero suelen ser bastante caras. Lo fundamental es el software de test, que contiene preguntas similares a las del examen, y será nuestra herramienta de prácticas, porque de la teoría del libro a las preguntas reales del test hay una diferencia abismal. Sin ninguna duda recomiendo éste:

http://enthuware.com/index.php/mock-exams/oracle-certified-associate/java-programmer-certification-i

Por un precio de risa (9.95$) este software contiene mas de 1500 preguntas de distinta dificultad, organizadas por temas o en exámenes completos. cada respuesta viene explicada y si te quedan dudas se puede preguntar en el foro esa pregunta en concreto, observarás que hay muchas comentadas con enlaces que ayudan a explicar la respuesta. Sin ninguna duda es el mejor aliado para superar este examen, yo me presenté cuando me sabía casi de memoria casi todas las preguntas 😛

Notaréis que las preguntas son de dificultad alta en general y extrema en algunos casos, muy alejada de la teoría y de los casos cotidianos de programación. La verdad es que este examen te convierte en algo parecido a un compilador Java humano 🙂

El día del examen

Antes que nada, es necesario registrarse en la web de PersonVue y solicitar el lugar, fecha y hora del examen, y pagarlo por adelantado. Si todo ha salido bien Oracle te confirmará la cita y te mandará un recibo de pago muy bonito y un correo con instrucciones para que te registres en la web de CertView:

https://education.oracle.com/pls/eval-eddap-dcd/ocp_interface.ocp_candidate_login?p_include=Y&p_org_id=1001&p_lang=US

En esta web se publicará tu calificación, así que completad el registro bien y comprobadlo para evitar sorpresas desagradables 😛

El dia D a la hora H te presentas en el lugar en cuestión, firmas unos papeles, te sacan una foto… y te cachean como en la aduana del aeropuerto 🙂 ni un triste lápiz te dejan entrar, te lo proporcionan ellos ( que majos ). Una vez dentro te toca darlo todo, si lo has preparado bien te sobrará tiempo para repasar.

Unas horas después te llegará un correo avisándote de que las calificaciones ya están disponibles, así que solo te queda entrar en la web de certView y saborear tu triunfo.