Las interfaces funcionales es un nuevo concepto que fue agregado a partir de la versión 8 de Java y cobran su importancia al utilizar expresiones lambda (λ).

Ejemplo de interfaces funcionales:

A continuación, veremos ejemplos de dos interfaces funcionales válidas:

package com.osb.functionalinterface;

/**
 * @author Oscar Blancarte 
 */
public interface IStrategy {
    public String sayHelloTo(String name);
}

En esta interface, definimos un método que manda un saludo a la persona que le pasamos como parámetro, pero todavía no está definido el cuerpo del método.

package com.osb.functionalinterface;

/**
 * @author Oscar Blancarte 
 */
public interface IStrategy {
    
    public String sayHelloTo(String name);
    
    public default String sayHelloWord(){
        return "Hello word";
    }
}

Esta segunda interface, también es una interface funcional, ya que solo tiene un método abstracto.

Otra forma de asegurarnos de que estamos definiendo correctamente una interface funcional, es anotarla con @FunctionalInterface , ya que al anotarla el IDE automáticamente nos arrojara un error si no cumplimos con las reglas de una interface funcional. Sin embargo, es importante resaltar que en tiempo de ejecución no nos dará un comportamiento diferente, puesto que es utilizada para prevenir errores al momento de definir las interfaces. Veamos cómo quedaría la clase anterior con esta anotación:

package com.osb.functionalinterface;

/**
 * @author Oscar Blancarte 
 */
@FunctionalInterface
public interface IStrategy {
    
    public String sayHelloTo(String name);
    
    public default String sayHelloWord(){
        return "Hello word";
    }
}

Interfaces funcionales con expresiones lambda:

Ya con la teoría, veamos cómo podría utilizar la clase IStrategy  mediante expresiones lambda:

package com.osb.functionalinterface;

/**
 * @author Oscar Blancarte
 */
public class Main {
    public static void main(String[] args) {
        IStrategy strategy = (name) -> "Hello " + name;
        
        System.out.println(strategy.sayHelloTo("Oscar Blancarte"));
        System.out.println(strategy.sayHelloWord());
    }
}

Veamos como en la línea 8 definimos una expresión lamba en donde concatena Hello con el nombre de la persona que es pasada como parámetro, luego esta expresión es asignada a la variable a la variable strategy , la cual es de tipo IStrategy . Luego de esto mandamos llamar al método sayHelloTo  el cual nos regresa el saludo para Oscar Blancarte, seguido en la línea 11 llamamos al método sayHelloWord , el cual manda un Hello Word.

Como vemos la expresión lambda siempre se asigna al método abstracto, por este motivo el método sayHelloTo  es implementado con el cuerpo de la expresión lamba, mientras que el método sayHelloWord  continua con la misma implementación que viene desde la interface.

Observemos la imagen anterior, cuando una expresión lambda es asignada a una interface, está siempre implementará el método abstracto, es por esta razón por la que solo puede existir un método abstracto y muchos defaults.

Finalmente, el resultado de la ejecución es el siguiente:

Hello Oscar Blancarte

Hello word

The post Java 8 – Interfaces funcionales appeared first on Oscar Blancarte - Software Architecture.

Para agregar un método default solo será necesario marcar un método con el operador default , veamos un ejemplo de cómo se implementan:

public default double getTotal(){
  return getQuantity() * getPrice();
}

Los métodos default se utilizan cuando es necesario implementar un cuerpo sin la necesidad de tener que implementar por separado una clase abstracta, además los métodos por default se pueden sobrescribir en caso de que la implementación por default no cumpla con lo que requerimos. Tenemos que resaltar que los métodos default no remplazan a las clases abstractas, pues estas últimas son mucho más potentes, debido a que nos permiten definir propiedades a nivel de clase, constructores y métodos privados. Veamos una limitante de los métodos default:

public default double getTotal(){
  return quantity * price;
}

Esta interface nos va a marcar error en tiempo de compilación, debido a que no es posible declarar propiedades de clase y mucho menos interactuar con ellas, por lo que estamos limitados a trabajar con los parámetros o con los métodos definidos en la misma interface o que extiende de otra.

Un ejemplo práctico:

Imaginemos que estamos programando un sistema que procesa ordenes de varios tipos, cómo el caso de un ERP, este sistema, podría crear varios tipos de órdenes, como una orden de compra, venta, embarque, etc. todas estas órdenes podrían tener algo en común, cómo, por ejemplo, un total, una lista de ítems asociados a la orden y los ítems pueden tener una cantidad de productos y un precio, así mismo los detalles tendrían un total.

El código completo de este articulo lo puedes encontrar en GitHub: https://github.com/oscarjb1/DefaultMethod.git

Lo interesante aquí es que si todas las ordenes tiene un total, ¿no sería bueno tener una definición del método por default que nos calcule el total y a la vez los ítems también implementen su método para obtener el total? De la misma forma, si una orden tiene ítems, no sería bueno definir un método que permite agregar los ítems.

Veamos cómo quedaría si implementáramos los métodos por default, implementaremos dos interfaces, una que representa una order (IOrder ) y otra que representa los ítems (IOrderItem ):

package com.osb.defaultmethod;

import java.util.List;

/**
 * @author Oscar Blancarte
 */
public interface IOrder {
    
    public List<IOrderItem> getOrderItem();
    
    public default double getTotal(){
        double total = 0;
        for (IOrderItem item : getOrderItem()) {
            total += item.getTotal();
        }
        return total;
    }
    
    public default void addOrderItem(IOrderItem orderItem){
        getOrderItem().add(orderItem);
    }
}

Analicemos los métodos de la clase IOrder:

• getOrderItem: método que nos regresará los ítems que tiene la orden, no lo podemos implementar porque no es posible definir propiedades a nivel de clase, salvo constantes. Por lo que la clase que la implemente deberá de regresar una lista de ítems.
• getTotal: este método nos regresará el total de la orden, es decir la sumatoria de todos los ítems de la orden. Cuanta con el operador default lo que nos permite implementarlo recorriendo todos los ítems de la orden y sumando su total.
• addOrderItem: método default que nos permite agregar fácilmente nuevos ítems a la orden.

package com.osb.defaultmethod;

/**
 * @author Oscar Blancarte
 */
public interface IOrderItem {
    
    public double getQuantity();
    public double getPrice();
    
    public default double getTotal(){
        return getQuantity() * getPrice();
    }
}

Esta segunda interface representa los ítems de la orden, cuanta con los métodos:

• getQuantity: deberá retornar la cantidad de productos que tiene la línea.
• getPrice: deberá de retornar el precio por producto.
• getTotal: método default que calcula el total de la línea, multiplicando la cantidad por el precio.

Hasta este punto ya hemos implementado todos los métodos default y continuaremos creando un par de clases concretas que implementen estas dos interfaces para ver cómo funcionaría en tiempo de ejecución. Para esto crearemos las siguientes clases:

package com.osb.defaultmethod;

import java.util.ArrayList;
import java.util.List;

/**
 * @author Oscar Blancarte
 */
public class SalesOrder implements IOrder{
    
    private List<IOrderItem> orderItems;

    @Override
    public List<IOrderItem> getOrderItem() {
        if(orderItems==null){
            orderItems = new ArrayList<>();
        }
        return orderItems;
    }
}

En esta clase representará una orden de venta, por lo cual deberá de implementar la interface IOrder , pero como podemos ver, solo nos pedirá que implementemos el método getOrderItem  el cual es el único que no es default, los métodos getTotal  y addOrderItem  ya estarán implementados por default y se podrán utilizar sin necesidad de declararlos en la clase.

El método getOrderItem  solo regresa la lista de ítems, en caso de que la lista sea nula la crea y la retorna.

La siguiente clase representa los ítems de la orden de venta:

package com.osb.defaultmethod;

/**
 * @author Oscar Blancarte
 */
public class SalesOrderItem implements IOrderItem {
    
    private double quantity;
    private double price;

    public SalesOrderItem(double quantity, double price) {
        this.quantity = quantity;
        this.price = price;
    }
    
    @Override
    public double getQuantity() {
        return quantity;
    }

    @Override
    public double getPrice() {
        return price;
    }
    
}

Podemos observar que implementan la interface IOrderItem  la cual nos pedirá que implementemos los métodos getQuantity  y getPrice  los cuales ya hemos explicado. El método getTotal  ya está implementado por default desde la interface, por lo que ya no será necesario implementarlo en la clase.

Finalmente, la clase Main , en donde pondremos a prueba lo que hemos aprendido para ver cómo se comportan los métodos por default en tiempo de ejecución:

package com.osb.defaultmethod;

/**
 * @author Oscar Blancarte
 */
public class Main {
    public static void main(String[] args) {
        SalesOrder salesOrder = new SalesOrder();
        salesOrder.addOrderItem(new SalesOrderItem(10, 100));
        salesOrder.addOrderItem(new SalesOrderItem(1, 20));
        System.out.println("total ==> " +salesOrder.getTotal() );
    }
}

Lo primero que hacemos es crear una instancia de la Orden de venta (línea 8), luego en las líneas 9 y 10 agregamos dos nuevos ítems. Notemos que el método addOrderItem  esta implementado como default en la clase IOrde . Cada ítem define un precio y la cantidad.

Finalmente, en la línea 11 imprimimos el total de la orden, el total de la orden es calculado desde el método default de la clase IOrder  sumando el total de los ítems y el total de cada ítem también es calculado mediante el método default implementado desde la interface IOrderItem .

Como resultado de la ejecución tendremos:

total ==> 1020.0

Conclusiones:

Los métodos default son sin duda una gran utilidad, sobre todo porque nos evita tener que tener que implementar clases abstractas, pero como ya lo mencionamos no las sustituyen.

The post Java 8 – Default Method appeared first on Oscar Blancarte - Software Architecture.

Para explicar correctamente este Patrón de diseño le comparto esta imagen:

Imaginemos un escenario de la vida real para comprender mejor esta patrón para lo cual nos ubicamos en el Aeropuerto y estamos esperando a que nos indiquen que podemos abordar el avión por medio de las bocinas que hay en el aeropuerto.

Bien, de seguro no eres el único que esta esperando el vuelo, de seguro existen muchas personas que esperan el abordaje, En este escenario nosotros junto con todas las demas personas que esperan el vuelo son Observers y la bocina es el Tajet Ya que todos estamos atento a que nos indique que ya podemos abordar lo cual es un evento que realiza la bocina y que nosotros estamos esperando(Observando) para realizar una acción(Abordar).

Entonces el mecanismo por el cual el observer trabaja es el siguiente:

1. Existe un componente u Objecto al cual queremos observar(Tarjet)
2. Tenemos algún modulo u otro Objeto(Observer) el cual queremos que sea notificado cuando Tarjet realice una acción.
3. Los Observers deben implementar una Interfaz común que tanto el Target como el Observer conozcan.
4. Los Observers deberán ser registrados en el Tarjet el cual los almacenara en una lista.
5. Cuando el Tarjet realice una acción notificara a todos los Observers los cuales se registraron en el paso anterior.
6. Los Observers recibirán la notificación como un Evento el cual el Observer procesara para hacer una acción.

Si nos damos cuenta es mucho mas simple de lo que parece y muchos de las aplicaciones utilizan este patrón y ni siquiera nos damos cuenta.

En tu experiencia, ¿donde crees que se mas conveniente utilizar esta patrón o como lo implementarías?

Ya está a la venta mi nuevo libro “Introducción a los patrones de diseño“, en donde expongo los 25 patrones de diseño más utilizados y explicados desde un enfoque del mundo real, con ejemplos que pueden ser aplicados en tus proyectos. Sin duda es unos de los libros más completos de patrones de diseño en español.

The post Patrón de diseño Observer appeared first on Oscar Blancarte - Software Architecture.

El patrón MVC se ha convertido en un estándar para el desarrollo de aplicaciones que permite separar la aplicación entres capas que aunque estén relacionadas no siempre tiene por que estar juntas. Estas capas son la Vista, el Controlador y el Modelo y a continuación explico que es cada uno.

Modelo: El modelo representa la información como tal, representan los datos con los que la aplicación esta trabajando, ya sea los datos de una tabla, un formulario, etc. Podríamos decir que el modelo es la información la cual el usuario puede visualizar en pantalla.

Por ejemplo este texto que estas leyendo en este momento es el modelo.

Vista: Esta es la representación gráfica o pantalla que estas viendo en este momento, La vista requiere del Modelo para mostrar la información en la pantalla.

Controlador: El controlador es el puente entre la vista y el modelo, ya que desde el controlador podemos hacer operaciones que cambien el modelo lo cual representa un cambio en los datos de la vista.

El patrón MVC lo podrías ver de la siguiente manera:

Fig.1: Patrón MVC – Las lineas continuas son asociaciones directas y las punteadas don indirectas.

Como podemos ver en la fig1 el controlador tiene una asociación con la vista y el modelo, ademas la vista tiene una asociación con el modelo.

Por lo cual cuando el usuario realiza una operación lo hace a través del controlador el cual realiza operaciones sobre el modelo y luego notifica a la vista para que actualice la información que vemos en pantalla, Cuando el modelo es actualizado este puede arrojar eventos que notifican a la vista para que se actualice es por eso que existe la linea punteada entre ambos.

La vista tiene una relación indirecta con el controlador debido a que existen implementaciones de MVC en las cuales la vista no tiene acceso al Modelo por lo cual toda la información la obtiene a través del controlador.

La siguiente figura muestra como los componentes interactúan

Pasos

1. El usuario realiza un operación en la pantalla como presionar un botón.
2. El controlador recibe la petición de realizar una acción
3. El modelo es actualiza por medio del controlador el cual puede agregar,actualizar o borrar información.
4. La vista es actualizada con los cambios realizados al modelo.
5. El usuario recibe las actualizaciones en pantalla.
6. FIN.

Espero que esta breve explicación de lo que es MVC les sea de utilidad.

Ya está a la venta mi nuevo libro “Introducción a los patrones de diseño“, en donde expongo los 25 patrones de diseño más utilizados y explicados desde un enfoque del mundo real, con ejemplos que pueden ser aplicados en tus proyectos. Sin duda es unos de los libros más completos de patrones de diseño en español.

The post Patrón de diseño Modelo Vista Controlador (MVC) appeared first on Oscar Blancarte - Software Architecture.

El patrón de diseño Factory Method nos permite la creación de un subtipo determinado por medio de una clase de Factoría, la cual oculta los detalles de creación del objeto.

El objeto real creados es enmascarado detrás de una interface común entre todos los objetos que pueden ser creado, con la finalidad de que estos pueden variar sin afectar la forma en que el cliente interactúa con ellos. 

Es normal que un Factory pueda crear varios subtipos de una determinada interface y que todos los objetos concretos fabricados hagan una tarea similar pero con detalles de implementación diferentes. 

La intención del Factory Method es tener una clase a la cual delegar la responsabilidad de la creación de los objetos, para que no sea el mismo programador el que decida que clase instanciará, si no que delegará esta responsabilidad al Factory confiando en que este le regresará la clase adecuada para trabajar.

Lo anterior puede resultado un poco absurdo, pues para que necesitaría el programador ayuda de una clase para crear un objeto, en su lugar puede hacer simplemente un new y listo, tiene la instancia creada, sin embargo, el patrón Factory method se utiliza para casos en los que no se sabe en tiempo de diseño que subtipo vamos a necesitar, y en su lugar, definimos eso en la base de datos, en un archivo de configuración, o simplemente por medio de alguna condición en tiempo de ejecución podemos determinar que clase se utilizará.

Estructura del patrón Factory Method

El siguiente diagrama muestra los componentes que conforman el patrón de diseño:

• IProduct: Representa de forma abstracta el objeto que queremos crear, mediante esta interface se definen la estructura que tendrá el objeto creado.
• ConcreteProduct: Representa una implementación concreta de la interface IProduct, la cual es creada a través del ConcreteFactory.
• AbstractFactory: Este componente puede ser opcional, sin embargo, se recomienda la creación de un AbstractFactory que define el comportamiento por default de los ConcreteFactory.
• Concrete Factory: Representa una fábrica concreta la cual es utilizada para la creación de los ConcreteProduct, esta clase hereda el comportamiento básico del AbstractFactory.

Secuencia de ejecución

La siguiente sección describe la secuencia de ejecución del patrón

El diagrama se interpreta de la siguiente manera:

1. El cliente le solicita al ConcreteFactory la creación del ProductA .
2. El ConcreteFactory localiza la implementación concreta de ProductA y crea una nueva instancia.
3. El ConcreteFactory regresa el ConcreteProductA creado.
4. El cliente le solicita al ConcreteFactory la creación del ProductB.
5. El ConcreteFactory localiza la implementación concreta del ProductB y crea una nueva instancia.
6. El ConcreteFactory regresa el ConcreteProductB creado.

Ejemplo práctico

Para comprender mejor como funciona el patrón Factory Method analizaremos un ejemplo prácticos con el cual podemos presentarnos alguno de nuestros proyectos, el cual corresponde a una aplicación que se puede conectar a más de una base de datos, sin embargo, la base de datos a utilizar no se sabrá de antemano, si no que por medio de la configuración es como podremos determinar que base de datos estaremos utilizando.

Como vemos, en este caso, no está clara la base de datos que vamos a utilizar, por lo tanto no podemos crear una aplicación que se conecta a una base de datos determinada, si no que tenemos que esperar hasta conocer la configuración para poder establecer la conexión. Una posible solución es crear una serie de IF…ELSE IF para crear la conexión al momento de leer la configuración, sin embargo, esto no es para nada recomendable, pues crearemos una aplicación difícil de mantener y que además revuelva la lógica para determinar la base de datos junto con la lógica propia del sistema.

En su lugar, lo recomendable es crear un Factory Method que nos cree un objeto que nos permita conectarnos a la base de datos, y que este objeto oculte los detalles de implementación, por otro lado, el Factory Method ocultara los detalles de implementación para leer la configuración y crear el objeto adecuado según la configuración, de esta forma, todos los detalles son ocultados al cliente y este solo se preocupa por implementar la lógica.

Antes de comenzar, puedes ver todo el código fuente en GitHub: https://github.com/oscarjb1/blog-patterns-factorymethod

Lo primero será definir la interface que implementarán las clases que se conectarán a la base de datos:

package com.oscarblancarteblog;

import java.sql.Connection;

public interface IDBAdapter {
    public Connection getConnection();
}

Esta interface solo define el método getConnection, la cual deberá regresar una conexión abierta a la base de datos.

El siguiente paso es crear las clases concretas que se conectarán a las bases de datos Oracle, MySQL y SQLServer:

package com.oscarblancarteblog;

import java.sql.Connection;
import java.sql.DriverManager;

public class OracleDBAdapter implements IDBAdapter {
    
    static{
        try {
            //new oracle.jdbc.OracleDriver();
        } catch (Exception e) {
            throw new RuntimeException("Unexpected error on load Oracle Driver");
        }
    }

    @Override
    public Connection getConnection() {
        try {
            String user = ConfigLoader.getPropery("Oracle.user");
            String password = ConfigLoader.getPropery("Oracle.password");
            String host = ConfigLoader.getPropery("Oracle.host");
            String port = ConfigLoader.getPropery("Oracle.port");
            String db = ConfigLoader.getPropery("Oracle.db");

            String url = "jdbc:oracle:thin:@${host}:${port}:${db}"
                    .replace("${host}", host).replace("${port}", port).replace("${db}", db);

            Connection connection = DriverManager.getConnection(url, user, password); //connection to MySQL
            return connection;
        } catch (Exception e) {
            throw new RuntimeException("Oracle connection error " + e.getMessage());
        }
    }
    
}

package com.oscarblancarteblog;

import java.sql.Connection;
import java.sql.DriverManager;

public class MySQLDBAdapter implements IDBAdapter {

    static {
        try {
            new com.mysql.jdbc.Driver();
        } catch (Exception e) {
            throw new RuntimeException("Unexpected error on load MySQL Driver");
        }
    }

    @Override
    public Connection getConnection() {
        try {
            String user = ConfigLoader.getPropery("MySQL.user");
            String password = ConfigLoader.getPropery("MySQL.password");
            String host = ConfigLoader.getPropery("MySQL.host");
            String port = ConfigLoader.getPropery("MySQL.port");
            String db = ConfigLoader.getPropery("MySQL.db");

            String url = "jdbc:mysql://${host}:${port}/${db}?zeroDateTimeBehavior=convertToNull&serverTimezone=UTC&useSSL=false;"
                    .replace("${host}", host).replace("${port}", port).replace("${db}", db);

            Connection connection = DriverManager.getConnection(url, user, password); //connection to MySQL
            return connection;
        } catch (Exception e) {
            throw new RuntimeException("MySQL connection error " + e.getMessage());
        }
    }

}

package com.oscarblancarteblog;

import java.sql.Connection;
import java.sql.DriverManager;

public class SQLServerAdapter implements IDBAdapter {
    
    static{
        try {
            //new com.microsoft.jdbc.sqlserver.SQLServerDriver();
        } catch (Exception e) {
            throw new RuntimeException("Unexpected error on load SQLServer Driver");
        }
    }

    @Override
    public Connection getConnection() {
        try {
            String user = ConfigLoader.getPropery("SQLServer.user");
            String password = ConfigLoader.getPropery("SQLServer.password");
            String host = ConfigLoader.getPropery("SQLServer.host");
            String port = ConfigLoader.getPropery("SQLServer.port");
            String db = ConfigLoader.getPropery("SQLServer.db");

            String url = "jdbc:sqlserver://${host}:${port};databaseName=${db};"
                    .replace("${host}", host).replace("${port}", port).replace("${db}", db);

            Connection connection = DriverManager.getConnection(url, user, password); //connection to MySQL
            return connection;
        } catch (Exception e) {
            throw new RuntimeException("SQLServer connection error " + e.getMessage());
        }
    }
    
}

Como acabamos de ver, estas clases tiene como única responsabilidad de crear la conexiones a las base de datos y registrar el driver JDBC correspondiente. Adicional, utilizan un archivo de configuración para recuperar los datos de conexión, el cual analizáramos más adelante.

Para recuperar la configuración se utiliza una clase de utilidad llamada ConfigLoader, la cual lee y carga en memoria el archivo dbconfig.properties:

package com.oscarblancarteblog;

import java.io.InputStream;
import java.util.Map;
import java.util.Properties;

public class ConfigLoader {

    private static Properties props;

    static {
        try {
            InputStream stream = ClassLoader.getSystemResourceAsStream("META-INF/dbconfig.properties");
            ConfigLoader.props = new Properties();
            props.load(stream);
        } catch (Exception e) {
            throw new RuntimeException("Faild to load configuration");
        }
    }
    
    public static String getDBType(){
        return props.getProperty("dbtype");
    }
    
    public static String getPropery(String propName){
        return props.getProperty(propName);
    }
    
    
}

El archivos de propiedades se ve de la siguiente manera:

dbtype MySQL
#Values -> MySQL | Oracle | SQLServer


MySQL.user root
MySQL.password 1234
MySQL.host localhost
MySQL.port 3306
MySQL.db factory

Oracle.user sys
Oracle.password 1234
Oracle.host localhost
Oracle.port 1521
Oracle.db factory

SQLServer.user sa
SQLServer.password 1234
SQLServer.host localhost
SQLServer.port 1433
SQLServer.db factory

Finalmente, tenemos la clase DBFactory, la cual se encarga de crear la instancia correcta de la interface IDBAdapter basado en el valor de la propiedad dbtype del archivo dbconfig.properties:

package com.oscarblancarteblog;

public class DBFactory {
    public static IDBAdapter getDBAdapter(){
        String dbType = ConfigLoader.getDBType();
        System.out.println("DBType => " + dbType);
        switch(dbType){
            case "MySQL":
                return new MySQLDBAdapter();
            case "Oracle":
                return new OracleDBAdapter();
            case "SQLServer":
                return new SQLServerAdapter();
            default:
                throw new RuntimeException("Unsupported db type");
        }
    }
}

Como podemos apreciar, esta clase tiene una lógica para determina la clase que deberá de regresar, por su parte, el cliente no tiene por que saber cual es la implementación concreta que creará el Factory, lo que permitiría que en el futuro cambiáramos de implementación sin afectar al cliente.

Probando la solución

Finalmente, ejecutaremos una prueba para comprobar que todo funciona según lo explicado, para eso, creamos la clase Main, la cual se ve de la siguiente manera:

package com.oscarblancarteblog;

import java.sql.Connection;

public class Main {

    public static void main(String[] args) {
        try {
            IDBAdapter adapter = DBFactory.getDBAdapter();
            Connection connection = adapter.getConnection();
            System.out.println("Is Open => " + (!connection.isClosed()));
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

Al ejecutar este prueba tenemos como resultado la siguiente salida:

DBType => MySQL
Is Open => true

Como vemos, DBType indica que estamos utilizando la conexión a MySQL y al propiedad Is Open nos indica que la conexión se realizo correctamente. Si cambiamos la propiedad dbtype del archivo dbconfig.properties veremos como nos podemos conectar a las demás base de datos.

Conclusiones

Como hemos pido observar, implementar el patrón de diseño Factory Method es muy simple y otorga grandes ventajas que son fáciles de apreciar, como separar la lógica de creación de objetos en una clase de factoria o la facilidad de variar dinamicamnte la implementación del objeto fabricado sin afectar al cliente.

The post Patrón de Diseño Factory appeared first on Oscar Blancarte - Software Architecture.

Bien la solución que considero mucho mas rápida es con ayuda de una HashMap ya que al no permitir elementos repetidos como llave nos ayuda a descartar de forma muy rápida los elementos que ya tenemos en nuestra colección.

Imagines un escenario donde tenemos una lista de clase Cliente la cual tiene un campo de ID que nos ayude a identificarlo como único, Con esto lo único que tendríamos que hacer es meter como llave el ID y como Valor el Objecto Cliente completo. Al terminar de introducir todos los elementos los elementos repetidos serán automáticamente descartados y solo faltaría iterar las Entradas del HashMap para recuperar los valores únicos.

Veamos el siguiente Código:

Para los que no les quedo muy claro como el Map elimina los repetidos les explico:

Los Map tiene la característica de tener por cada entrada dos elementos el Key y el Value, El Key representa un elemento único y no puedo contener repetidos por lo que si se intenta meter un elemento repetido lo que hará es sustituir este ultimo por que estaba antes y el Value representa un valor cualquiera asociado a la llave o Key.

The post Java – Como eliminar rápidamente elementos repetidos de una colección appeared first on Oscar Blancarte - Software Architecture.

Java ofrece la clase WeakReference la cual se define de la siguiente manera

WeakReference<T> reference = new WeakReferente<T>(new T());

En este ejemplo T es de tipo Genérico y deberemos sustituirlo por la clase que queramos administrar, por ejemplo si tenemos una clase Persona tendríamos que crear el WeakReference de la siguiente manera

WeakReference<Persona> reference = new WeakReference<Persona>(new Persona());

En este momento tendremos una referencia blanda hacia el objeto que creado y para obtener al objeto Persona tendremos que hacerlo mediante el metodo get de WeakReference de la siguiente manera:

Persona persona = reference.get();

Pero hay que tener cuidad siempre que obtengamos la referencia pues esta podría ser Null en cualquier momento ya que si ninguna otra variable tiene una referencia fuerte o Strong Reference a este objeto el Garbage Colector la eliminara.

Al igual que existen las referencias blandas o WeakReference también existe un HashMap de WeakReference la cual es  WeakHashMap<T,D> la cual tiene la misma mecánica pero implementado como un Map.

Estas son algunas de las cosas extrañas que existen en Java pero que nos interesante saberlas.

The post Java – Weakreference appeared first on Oscar Blancarte - Software Architecture.

Por otro lado tenemos a JDBC que nos brinda total libertad de hacer lo que queramos sin ningún tipo de limitación explotando al máximo las características de la base datos. JDBC nos permite realizar consultas nativas para cada base de datos lo que ayuda mucho a la velocidad de respuesta y los resultados son devueltos en un ResultSet los cuales podemos extraer solamente los datos que requerimos y no toda la Entity como en el caso de JPA o Hibernate.

JPA,Hibernate

Ventajas

1. Nos permite desarrollar mucho mas rápido.
2. Permite trabajar con la base de datos por medio de entidades en vez de Querys.
3. Nos ofrece un paradigma 100% orientado a objetos.
4. Elimina errores en tiempo de ejecución.
5. Mejora el mantenimiento del software.

Desventajas

1. No ofrece toda la funcionalidad que ofrecería tirar consultas nativas.
2. El performance es mucho mas bajo que realizar las consultas por JBDC.
3. Puede representar una curva de aprendizaje mas grande.

JDBC

Ventajas

• Ofrece un performance superior ya que es la forma mas directa de mandar instrucciones la base de datos.
• Permite explotar al máximo las funcionalidades de la base de datos.

Desventajas

• El mantenimiento es mucho mas costoso.
• Introduce muchos errores en tiempo de ejecución.
• El desarrollo es mucho mas lento.

Probablemente pensaras que JPA o Hibernate son mejores ya que ofrece mayor ventajas que desventajas sin embargo las desventajas que tiene son muy serias y pueden ser cruciales a la hora de decidir que tecnología utilizar ya que si tenemos una aplicación muy buena y fácil de mantener pero que tarda demasiado para consultar datos puede llegar a ser algo muy malo.

Como conclusión yo diría que si requieres una aplicación donde el rendimiento sea el factor mas importante utilices JDBC, pero por otra parte si el rendimiento es algo que no están importante puedes utilizar JPA o Hibernate.

Tutorial de JPA Gratis!!

Si estás leyendo esto en este momento es por seguramente estas interesado en aprender Hibernate o JPA, pues te tengo buenas noticias, ya que he iniciado un tutorial muy completo de JPA para que aprendas desde cero y sin conocimientos previos como utilizar JPA. No te sientas mal si lo que tu buscas es aprender Hibernate, ya que actualmente existe una implementación de JPA desarrollada por Hibernate. Además, JPA es el ORM Estándar de Java y que se integra a la perfección con el resto de especificaciones de Java, como lo es EJB 3.X, CDI, Bean Validator, entre otras más. Pues bien, si estas interesado en tomar este tutorial puedes entrar aquí.

The post JPA, Hibernate VS JDBC appeared first on Oscar Blancarte - Software Architecture.

El polimorfismo permite que nuestro programa realice tareas que se definirán hasta el tiempo de ejecución.

Si escribimos un código que sume dos números nuestra programación sera muy simple ya que podemos determinar el comportamiento del programa con solo ver el código, por ejemplo

public class Main{

public static void main(String[] args){

Operacion op= new Operacion();

double suma = op.operacion(5,10);

System.out.println(“Suma ==> ” + suma);

}

}

public class Operacion{

public double operacion(double a, double b){

return a +b;

}

}

Con solo ver el siguiente código podemos determinar que el programa sumara dos numero y finalizara ya que código a ejecutar esta definido de esta forma y nada puede hacer que cambie en tiempo de ejecución. Sin embargo con el polimorfismos esto cambia ya la funcionalidad que se ejecuta dependerá de la implantación que se le de aun método determinado.

Una vez comprendido el código anterior veremos como trabajaría con polimorfismo.

Imaginemos que ya tenemos definidas las clases anteriores pero hora definimos una nueva clase llamada Resta la cual extiende de “Operacion” pero en vez de sumar los números los resta:

public class Resta extends Operacion{

public double operacion(double a, double b){

return a – b;

}

}

Podemos apreciar que el método “operacion” esta definido igual que en la clase “Operacion” lo que provoca algo llamada Override o sobre escribir el método.

Con esto en mente modificaremos el método main de la clase anterior y veremos lo que sucede:

public class Main{

public static void main(String[] args){

Operacion opSum= new Operacion();

double suma = opSum.operacion(5,10);

System.out.println(“Suma ==> ” + suma);

Operacion opRest = new Resta(5,10);

double resta = opRest.operacion();

System.out.println(“Resta ==> ” + resta);

}

}

Como resultado tendremos la suma de 5 + 10 = 15 seguido de la resta de 5-10 = -5.

La clave aquí es que opRest a pesar de tipo “Operacion” tiene asignada una referencia a una instancia de la clase Resta la cual al extender de “Operacion” nos permite asignarla a una variable de tipo “Operacion” esto hace que en tiempo de ejecución el metodo “operacion” de la variable opRest ejecute el código de la clase Resta en vez de la clase “Operacion”

Bien a esto se le llama Polimorfismo…

The post Que es el Polimorfismo? appeared first on Oscar Blancarte - Software Architecture.