Tareas en Segundo Plano (Swing)

Algunas ocasiones necesitas poner una tarea en especial a ajecutarse cuando halla tiempo, es decir, no en este momento o simplemente que espere a que los recursos esten disponibles para poder dar a otra tarea más importante algo de tiempo. Realizar esto en entornos Swing es bastante simple con la clase SwingUtils. El código es sencillo:

public void ejecutaDespues() {
    SwingUtilities.invokeLater(new Runnable() {
        public void run() {
            //Hacer algo.
        }
    });
}

Data Driven Test (II)

En una de mis ultimos posts había tocado el tema de los JUnit parametrizados, y había presentado una solución simple; ahora, experimentando un poco, me he encontrado con una solución un poco mas sencilla y como en lo personal prefiero las cosas sencillas aquí la presento.

La solución es sencilla, consiste en crear un constructor parametrizado y un método que ejecute la lógica de la prueba. Pongamoslo en código:

public class TestParametrizado {
    private int parametro = 0;

    public TestParametrizado(int parametro) {
        //Es necesario que el nombre del método este en la llamada a super
        super("metodoParametrizado");
        this.parametro = parametro;
    }

    public void metodoParametrizado() {
        ; //Lógica de metodos parametrizados
    }
}

Ahora viene la pregunta del millon, no podemos correr este test con los métodos regulares, por la simple y sencilla razón de que JUnit intentara crear una instancia nueva con un constructor sin parametros, en resumen, no funcionará.

Para solucionar este pequeño inconveniente vamos a transformar nuestro TestCase en un test suite.

//Este método debe estar en la misma clase que lo anterior
public static Test suite() {
    TestSuite suite = new TestSuite();

    suite.addTest(new TestParametrizado(4));
    suite.addTest(new TestParametrizado(5));
    suite.addTest(new TestParametrizado(7));

    return ts;
}

Diseño de Software Java Guiado por Pruebas

Un artículo que recien escribi y puede encontrarse en Scribd

JUnit

JUnit es una libreria Java que permite realizar pruebas de unidad sobre las clases que han sido desarrolladas dentro de un proyecto orientado a objetos. Por medio de JUnit podemos probar parte de la calidad del software que desarrollamos.

Las pruebas que se pueden desarrollar sobre JUnit parten de un sencillo concepto: assert, un assert en una condición que debe cumplirse para considerar que nuestra clase probada funciona de la manera esperada.

Además, los JUnits permiten realizar operaciones complejas dentro de una clase utilizando código Java para las pruebas.

Un UnitTest tiene la siguiente estructura:

1. 1 método protegido setUp( ) que configura el entorno antes de realizar cualquier prueba.
2. 1 método protegido tearDown( ) que destruye el entorno de pruebas.
3. Varios métodos con el nombre test* que son cada una de las pruebas que se van a realizar.

Dentro de cualquiera de estos métodos pueden utilizarse los métodos siguientes:

1. assertTrue(mensaje, condicion), assertTrue(condicion). Que comprueba que la condicion booleana que se le pasa como parametro sea forzosamente correcta.
2. assertFalse. Lo mismo pero al reves.
3. assertEquals(valor, valor), assertEquals(mensaje, valor, valor). Se asegura que los valores pasados como parametro sean iguales.
4. assertNotEquals( );
5. assertSame(Objeto, Objeto). Los objetos deben hacer referencia al mismo objeto, es decir, la misma direccion de memoria.
6. assertNotSame( ).

Patrones. Pocos y de pasadita

Los patrones son soluciones a problemas comunes que podemos encontrar de manera documentada, son las mejores practicas y soluciones a varios problemas que te puedes encontrar en el día a día del desarrollo. Generalmente estos patrones favorecen los objetivos de orientación a objetos y facilitan el trabajo. Existen cientos de ellos, aquí solamente vamos a exponer una introducción a algunos de ellos.

• Singleton. El singleton es una clase de la que solamente queremos crear una sola instancia, podemos pensar por ejemplo en una clase Presidente de Empresa, de estos solamente debería haber uno por Empresa.
  
• Listener. Un listener es una clase que esta atenta a los cambios en alguna instancia de otra clase, podemos pensar en que la clase que reporta los cambios envia avisos a todas las clases interesadas, y estas hacen alguna acción en base a estas notificaciones, de manera similar a alertas sobre eventos.
• Decorator. Una clase de determinado tipo "envuelve" a otra clase del mismo tipo para poder hacer nuevas funcionalidades que pueden ser eco de las de la clase decorada. Los decoradores sirven en muchos casos para crear objetos "con"por ejemplo Cafe con Leche o Leche con Chocolate, o quizas Cafe con Leche con Chocolate.
• Delegate. Es una clase de dependencia en la que una clase expone cierta funcionalidad que es realizada por alguna otra clase o instancia, de manera que el usuario final solo accede a una clase de salida.
• Façade. Los objetos de varias clases se agrupan dentro de una nueva que expone la funcionalidad de todas las clases del grupo dentro de si mismo. Podemos compararlo de manera directa con un control remoto universal, que incluye las funciones de varios controles.
• Factory. Una clase de objetos que son dificiles de configurar se mantienen con constructores de paquete, mientras que una clase de ese mismo paquete permite crear las instancias de los mismos sin pasar por todos los problemas de configuración.
• Interceptor. Una clase funciona como un envoltorio de otra, cada que la claseenvuelta va a realizar una operación le notifica a la primera para que esta pueda cambiar partes del proceso que realiza.
  
• Iterator. Una clase permite recorrer los elementos de una colección.
  
• Abstract Factory. Similar a Factory, pero en este caso se define una clase abstracta que creara los objetos, y es en la implementación concreta donde dichos objetos se crean.
• Strategy. Una clase abstracta define los pasos de un proceso, y el orden que seguiran, pero son las clases concretas quienes determinan la forma exacta en que el proceso se realiza, generalmente implementando partes del proceso.
  

Principios de Diseño Orientado a Objetos

Para realizar modelos orientados a objetos no esta de mas conocer algunos principios para poder verificar la fortaleza de los mismos. Ya hay una serie de principios que se recomiendan para un diseño orientado a objetos. Entre estos podemos encontrar los siguientes:

Responsabilidad Única

Cada clase debe ser responsable de realizar solo una actividad del sistema

Clase Abierta y Cerrada

Una clase debe ser abierta a la extensión y cerrada a la modificación

Principio de Substitución de Liskov

Cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas

Principio de Inversión de Dependencia

Los modulos de nivel superior no deben depender sino de las abstracciones. Los detalles deben depender a su vez de las abstracciones, no al contrario

Principio de Segregación de Interfaces

La implementación de las abstracciones (que contradictorio) debe estar en la medida de lo posible en interfaces y no en clases

Principio de Equivalencia de Reuso y Distribución

Solo los componentes que se distribuyen de manera final pueden ser reutilizados, el elemento mas importante es entonces el paquete.

Principio de Cierre Común

Los componentes que comparten funciones entre ellos o que dependen uno del otro deberían ser colocados juntos

Principio de Reuso Común

Si se reutiliza una clase de un paquete entonces se reutilizan todas

Principio de Dependencías Aciclicas

Los paquetes y sus dependencias no deben formar ciclos entre si

Principio de Dependencías Estables

Los paquetes menos estables han de depender de los paquetes mas estables

Principio de Abstracción Estable

Los paquetes deben ser más abstractos mientras mas estables son

Los 5 primeros principios son los que no deberían olvidarse mientras se escriben clases, aunque todos los principios son importantes.