Category: Programación

Necesitaba aplicar una serie de operaciones en distintos tipos de datos que comparten ciertas características. Hice lo lógico: creé una clase abstracta que implementa las funciones básicas de las características en común e hice que las demás clases fueran subclases de ella.

public abstract class BaseClass {

   // Propiedades y métodos comunes implementados aquí

}

public class SubClass1 extends BaseClass  {

   // Propiedades y métodos exclusivos
}

public class SubClass2 extends BaseClass {

    // Propiedades y métodos exclusivos
}

En los métodos que aplican las operaciones en cuestión declaré como parámetro la super clase (la abstracta) para que pudiera recibir cualquier subclase. El código quedó más o menos así.

public PriorityQueue<BaseClass> operation1 (List<? extends BaseClass> list) {
    // Hacer algo con los elementos en la lista
}

Hasta aquí todo bien.

El problema surgió cuando dentro de una de las operaciones tenía que modificar varias propiedades comunes de los objetos incluidos en la lista. Debido a la forma en la que Java pasa los parámetros (por valor,  aunque los objetos siempre pasan por referencia. Ver aquí), modificar en el método una de las propiedades del objeto no serviría de nada. Lo primero que se me vino a la mente fue crear clones de los objetos de la lista, pero muchos dicen que hay que evitarlos en la medida de lo posible, en especial cuando se tiene una estructura de clases compleja y algunos objetos no implementan la interface Clonable.

Ya he trabajado con clones antes y no hubo mucho problema. Sin embargo, quería ver si podía aplicar la solución de crear copy constructors para cada clase en la estructura y llamarlos dinámicamente. El problema es que necesitaba saber en tiempo real a qué clase pertenecían los objetos en la lista. Cierto: puedo hacer una serie de if con instanceof para probar cada una de las clases, pero se me hacía que había una mejor solución. Un simple:

BaseClass copy = new BaseClass(originalobject)

está fuera de contexto porque la clase base es abstracta (no se puede instanciar directamente).

La solución es relativamente sencilla: después de crear el copy constructor y de llamar en él al copy constructor de la superclase, en las operaciones tomo la clase de los elementos de la lista y creo dinámicamente una instancia de su copy constructor, la cual puedo llamar para crear una nueva instancia de la clase que contendrá los elementos del objeto original más lo que haya necesitado modificar. Al final meto todo en una cola que se ordena solita (basada en el compare de la clase) y es lo que regreso.

Los métodos que se usan:

• Object.getClass() : para obtener en tiempo real la clase del objeto en cuestión.
• Class.getDeclaredConstructor(Class) : para obtener el constructor que reciba los parámetros indicados. Como en este caso se trata de copy constructors, el único parámetro es un objeto de la misma clase, determinado con el getClass().
• Constructor.newInstance(Object): para obtener una nueva instancia de la clase. En este caso, el constructor debe recibir como parámetro un objeto de la clase BaseClass o alguna de sus subclases.

Algo más o menos así:

public abstract class BaseClass {

   protected BaseClass() {
      // Inicialización de propiedades en común
   }

   // Copy Constructor
   protected BaseClass (BaseClass bc) {
       // copiar los datos de bc a esta instancia
   }

}

public class SubClass1 extends BaseClass {

    public SubClass1 {
       super();
       // Inicialización de propiedades exclusivas
    }

    // Copy Constructor
    public SubClass1 (SubClass1 sc1) {
        super(sc1);
        // Copiar los datos exclusivos de sc1 a esta instancia
    }
}

public class SubClass2 extends BaseClass {

    public SubClass2 {
       super();
       // Inicialización de propiedades exclusivas
    }

    // Copy Constructor
    public SubClass2 (SubClass2 sc2) {
        super(sc2);
        // Copiar los datos exclusivos de sc2 a esta instancia
    }
}

Y las operaciones:

public PriorityQueue<BaseClass> operation1 (List<? extends Searchable> list) {

    Class<? extends BaseClass> objclass = null;
    Constructor<? extends BaseClass> theConstructor = null;
    BaseClass newElement = null;

    for (BaseClass bc : list) {
       // Hacer algo con los datos

      objclass = bc.getClass();
      theConstructor = objclass.getDeclaredConstructor(objclass);
      newElement = theConstructor.newInstance(bc);

       // Hacer las operaciones restantes, crear la cola y devolverla
    }
}

Una alternativa más para la referencia dinámica a las clases y sus constructores.

Hace días necesitaba implementar algo en Java que me permitiera emular callbacks. Habiendo usado tanto tiempo Java fue curioso que de primera instancia no se me ocurriera usar interfaces. Un googlazo me enseñó la luz, y de ahí en delante fue nada más crear las clases necesarias.

El escenario es el siguiente: hay una clase que hace las veces de fábrica para crear instancias de otra, pero la forma de extraer la información es diferente dependiendo del documento en cuestión. Cada documento está clasificado en grupos, por lo que sé qué reglas tengo que usar para extraer lo de cada grupo. Ciertamente podría hacer todo con un parámetro y revisar el valor con un if para saber qué rutina ejecutar, pero si existen los callbacks, qué mejor (aunque Java no usa apuntadores).

Lo primero es crear la interface que las clases se van a cargar de implementar. Algo como:

public interface OmniAnalyzer {
    public void analyzeDocument(String document);
}

Después, hay que crear una clase por cada grupo de documentos a analizar, y hacer que cada una implemente la interface arriba mostrada:

public class GroupAAnalyzer implements OmniAnalyzer {
    @Override
    public void analyzeDocument(String document) {
       // Analizar documento de acuerdo a reglas de grupo A
    }
}

public class GroupBAnalyzer implements OmniAnalyzer {
   @Override
   public void analyzeDocument(String document) {
       // Analizar documento de acuerdo a reglas de grupo B
   }
}

Y al momento de analizar un documento, en vez de declarar que usamos una instancia de alguna de las clases anteriores, referenciamos directamente la interface que implementan. Así, independientemente de la clase (y las reglas) que se utilice, simplemente hay que llamar a las funciones que sabemos que están implementadas.

public class General {

  private static void analyzeDocument(OmniAnalyzer analyzer, String document) {
    analyzer.analyzeDocument(document);
  }

  public static void main(String a[]) {
    String doc = a[0];
    int group = Integer.parseInt(a[1]);
    OmniAnalyzer analyzer = null;

    if (group == 0)
     analyzer = new GroupAAnalyzer();
    else if (group == 1)
     analyzer = new GroupBAnalyzer();
    else {
       System.err.println("Only accepting groups 0 or 1");
       System.exit(1);
    }

    analyzeDocument(analyzer, doc);
  }
}

Con esto se deja la puerta abierta para agregar nuevos grupos en caso de ser necesario, y sin necesidad de darle en la torre a lo que ya está hecho.

Ayer que estaba analizando una serie de textos en japonés, estuve intentando hacer una expresión regular que me ayudara a filtrar URL y algunas palabras que comenzaban con arroba y podían terminar con 2 puntos.

Aunque necesitaba implementarlo en Java, primero hice pruebas en Python para evitarme la pena de tener que hacer una clase pequeña.

Por supuesto, la parte de la URL es muy común, así que en vez que reinventar el hilo negro, mejor busqué en internet. Al final, terminé con ésta:

String a = "El texto con arrobas y URL";

System.out.println(a.replaceAll("(^|\\b)?@\\w+:?(\\b)?|(http|ftp|https):\\/\\/[\\w\\-_]+(\\.[\\w\\-_]+)+([\\w\\-\\.,@?^=%&:/~\\+#]*[\\w\\-\\@?^=%&/~\\+#])?","");

Sé que hay más opciones para filtrar la URL, pero ésta cumplió el trabajo.

Por cierto, @mecart comentó que parecía un nuevo smiley 😛

Aunque me gustan muchos lenguajes de programación, he usado Java como lenguaje principal desde que llegué a Japón. En realidad no hay una razón específica para ello, simplemente sentía que necesitaba practicar más en él, puesto que había estado usando mayormente C, y sentía que Java se me estaba olvidando… y aquí me tienen 7 años y medio después usándolo todavía. De vez en cuando también sale algo en Python, y Haskell es primordialmente para XMonad, pero de C lo último que hice fue un minijuego de PSP hace 4 años.

Después de usar un lenguaje de programación por un rato, se vuelve fácil sentarse a desarrollar algo sin la preocupación de estar leyendo cómo implementar algo en él… Sin embargo, siempre se aprende algo nuevo, y cada día lo reafirmo con cada aplicación que desarrollo.

He programado con hilos en Java desde hace mucho, pero nunca me había puesto a leer con detalle las clases del paquete java.util.concurrent. El control de hilos (el principal esperando mientras que otros realizan tareas de forma concurrente) lo implementaba con wait(), notifyAll() y boolean. Primitivo, pero funcionaba. Cuando necesito esperar un sólo hilo uso join(). Pero estaba seguro que debería haber algo ya en las clases de Java que hiciera lo que yo hacía, algo así como cuando aprendes lo que son las listas ligadas, implementas una pila con todos sus métodos y después  te dicen que ya hay una clase Stack que hace todo eso, y muchas veces de forma más eficiente (no siempre, aclaro). Fue entonces cuando descubrí las clases CountDownLatch y ThreadPoolExecutor.

Continue reading “De hilos en Java”

Aunque he trabajado con bases de datos durante mucho tiempo, no me considero un experto, y ésta es la prueba.

Sabemos que en una base de datos relacional lo recomendado es normalizar las tablas para evitar tener datos nulos, vacíos o repetidos en una sola tabla, y usando la primary key creamos relaciones entre las tablas para poder recuperar los datos cuando sea necesario. Pero cuando se tiene una cantidad de datos que comienza a ser grande (hablamos del order de millones de registros), ¿hacer un join para obtener los datos es la mejor opción?

Seguramente habrán escuchado sobre las key-value stores o bases de datos con tablas key-value , en las que se deja todo el control al programador con tal de evitar esos join y así “ganar” velocidad. Yo aprendí a usar siempre bdd relacionales, pero siempre he estado abierto a mejores propuestas, sobre todo cuando se tienen millones de registros y la velocidad del query es primordial. Sé que los join son lentos, pero el mantenimiento de una key-value store también es una tarea que puede ser desgastante. ¿A qué tirarle?

Si alguien tiene experiencia en esto, se aceptan sugerencias 🙂

Por acá un artículo que analiza los pros y contras de las bdd relacionales vs. las key-value stores: Is the Relation Database Doomed?

Leí este artículo hace unos días, y me dio la idea de escribir al respecto la primera entrada de este blog.

Como se menciona en el artículo referido, es fácil decir que un código es malo cuando está hecho de una forma que no es la que uno acostumbra. Entender código ajeno toma tiempo, y hay veces en que mejor optamos por rehacer las cosas a nuestra manera en vez de tratar de comprender qué pensó (o de cuál fumó) el programador para sacar un código así. Claro que si vemos un código complicado, que no entendemos pero que sabemos que funciona, es mejor no reinventar la rueda y dejarlo así. Las 2 caras de la moneda.

Continue reading “Buen código, mal código”