En algunos paradigmas de programación (como la programación orientada a objetos) se nos dice que desde fuera de una clase sólo necesitamos saber qué se hace, no el cómo. Si la clase se encarga de interaccionar con una base de datos no necesita saber cuál es la base de datos ya que de eso se encargaría el driver (lo cual sería cierto si el estándar SQL fuera más… estándar… pero eso es otro tema). Y al resto de clases del proyecto no les importa tampoco cómo realiza esa interacción, sino que sólo deben preocuparse de que tal método devuelve los datos de la tabla cual.

¿Cómo se hace esto? Definiendo muy bien la visibilidad de la clase. Esto es, qué métodos se van a llamar desde el resto de clases (métodos públicos), cuáles están restringidos a clases “amigas” (del mismo paquete o que hereden de la nuestra, son los métodos protegidos) y cuáles no son accesibles en absoluto fuera de nuestra clase (métodos privados).

Por definición, es recomendable que todas las variables sean definidas como privadas, de forma que la única manera de manipularlas sea a través de los métodos públicos definidos por la clase y que sean éstos los que se encarguen de hacer todas las comprobaciones que sean necesarias.

Imaginemos la siguiente clase muy básica:

public class Persona {

  private String nombre;
  private int edad;

  public Persona () {
    inicializar ();
  }

  public void setNombre (String nombre2) {
    nombre = nombre2;
  }

  public void setEdad (int edad2) {
    if (edad2 > 0) {
      edad = edad2;
    }
  }

  public boolean validaVariables () {
    return edad > 0 && ! "".equals(nombre);
  }

  private void inicializar () {
    nombre = "";
    edad = 0;
  }
}

En este caso, lo que vemos desde fuera es que para la clase Persona podemos asignar una variable nombre y una variable edad. Podría haber más, pero no nos interesan puesto que no podemos interaccionar con ellas.

Además disponemos de una función para validar que los datos son correctos, pero nunca sabremos desde otra clase que existe un método inicializar.

Era de noche, los bandidos se refugiaron en el bosque. El capitán se levanta y dice:
- Pedro, cuéntanos esa historia que tan bien sabes y tan mal dices
Pedro se levanta y dice:

Era de noche, los bandidos se refugiaron en el bosque. El capitán se levanta y dice:
- Pedro, cuéntanos esa historia que tan bien sabes y tan mal dices
Pedro se levanta y dice:

Era de noche, los bandidos se refugiaron en el bosque. El capitán se levanta y dice:
- Pedro, cuéntanos esa historia que tan bien sabes y tan mal dices
Pedro se levanta y dice:
…

La recursividad es la propiedad por la cual una función o trozo de código se llama a sí mismo. Para mí es una práctica bastante útil para ciertas tareas (la más socorrida podría ser sin lugar a dudas la de recorrer un árbol de directorios), pero desde luego no se trata de una práctica que acostumbre a pasar inadvertida. Hay defensores de ella, que la ven como una forma de evitar repeticiones de código o interminables bucles anidados; y también tiene firmes detractores, pues el código recursivo requiere más memoria y requiere más atención del programador (esto lo digo por mi experiencia).

Tenéis más información en este post de Picando Código.

Para las empresas es una práctica útil para complicar a la competencia el entendimiento del código decompilado (aunque sea ilegal decompilarlo). Pero como es complicado hacer grandes programas de esta forma, existen multitud de herramientas que lo hacen por nosotros. Para Java he encontrado este listado en la página del ProGuard.

Sin embargo, en ocasiones uno se encuentra con un programa doblemente ofuscado… porque está ofuscado por pura ilegibilidad. Imaginad el siguiente trozo de código y comprenderéis…

FileOutputSream ff = new FileOutputStream (
  String.valueOf (
    String.valueOf (
      (
        new StringBuffer (
          String.valueOf (
            String.valueOf (
              new File (
                String.valueOf (
                  String.valueOf (
                    (
                      new StringBuffer (
                        String.valueOf (
                          String.valueOf (
                            System.getProperty (
                              "java.home"
                            )
                          )
                        )
                      )
                    ).append (
                      System.getProperty (
                        "file.separator"
                      )
                    ).append (
                      "empresa"
                    )
                  )
                )
              )
            )
          )
        )
      ).append (
        System.getProperty (
          "file.separator"
        )
      ).append (
        "adm.conf"
      )
    )
  )
);

Es un trozo de código de un programa real y tenéis la suerte de que os lo he ordenado un poco, porque estaba en 4 líneas tan solo…

La definición de un parámetro por referencia nos dice que es aquel parámetro cuyo valor se puede modificar dentro de la función y se propagará a la variable que se paso como parámetro fuera de la función, es decir, nuestra variable podrá cambiar de valor una vez ejecutada la función.

En cambio, la definición de un parámetro por valor nos dice que es aquel parámetro cuyo valor cuyo valor se puede modificar dentro de la función, pero que no se propagará a la variable que se paso como parámetro fuera de la función, es decir, nuestra variable nunca podrá cambiar de valor una vez ejecutada la función.

Normalmente (por lo menos con los lenguajes de programación que yo he tratado) lo que se hace es que en los parámetros por referencia se pasa la dirección de la variable usándose ésta dentro de la función, y en los parámetros por valor se crea una copia de la variable que se usará dentro de la función.

Hay que darse cuenta de que en el caso de los parámetros por referencia pasamos la dirección, lo cual se traduce en un puntero a una zona de memoria, y aquí es donde entra en conflicto Java (y por lo que se produjo la discusión), ya que Java sólo permite parámetros por valor, pero los objetos son referencias a direcciones de memoria, es decir, punteros a una zona de memoria con una estructura un tanto especial, y por lo tanto aunque Java cree una copia de nuestra referencia (o puntero) nosotros podremos seguir modificando los datos de dentro de esta zona y al salir de la función tener un objeto modificado, aún cuando Java sólo permite parámetros por valor y nosotros pensábamos que no se propagaría el cambio realizado dentro de la función hacia fuera de ésta.

En C ocurre algo semejante (y que ya comenté con un pequeño ejemplo en la discusión), ya que en C existen parámetros por valor y por referencia, lo que tiende a hacernos creer que los parámetros por referencia no crean una copia auxiliar, lo cual (creo, por mi poca experiencia) es falso, ya que en cualquier parámetro por referencia en C trabaja con una copia de la dirección que le pasamos, lo cual induce a errores muy graves y tontos como el siguiente:

void
funcion (char *referencia, int n)
{
    referencia = (char *) realloc (referencia, n * sizeof (char));
}

int
main (int argc, char *argv[])
{
    char *ref = (char *) malloc (sizeof (char));
    funcion (ref, 100);
    free (ref);
}

En este ejemplo se puede comprobar que el paso por referencia en C, crea una copia de la dirección que le pasamos, ya que realloc puede cambiar la dirección de nuestro puntero si no tiene suficiente espacio en la actual, por lo tanto deberíamos obtener una nueva dirección en ref y santas pascuas, pero no es así, ya que se trabaja con una copia de la dirección y por tanto si se modifica, al salir de la función no tendremos la nueva dirección y provocaremos un acceso a una zona de memoria que no queríamos, lo que es un error muy grave y a veces difícil de encontrar.

Para hacerlo bien tendríamos que realizar lo siguiente:

char *
funcion (char *referencia, int n)
{
    char *ptr;
    ptr = (char *) realloc (referencia, n * sizeof (char));
    if (ptr == NULL) {
        free (referencia);
        return NULL;
    }

    return ptr;
}

int
main (int argc, char *argv[])
{
  char *ref = (char *) malloc (sizeof (char));
  ref = funcion (ref, 100);
  free (ref);
}

Que es la solución que más me gusta, o la otra solución un poco más difícil de entender:

void
funcion (char **referencia, int n)
{
    char *ptr;
    ptr = (char *) realloc (*referencia, n * sizeof (char));
    if (ptr == NULL)
        free (*referencia);

    *referencia = ptr;
}

int
main (int argc, char *argv[])
{
    char *ref = (char *) malloc (sizeof (char));
    funcion (&ref, 100);
    free (ref);
}

Se puede ver que en C sólo habrá errores si al pasar un parámetro por referencia modificamos la dirección de éste y queremos seguir usándola fuera de la función, mientras no toquemos nada de la dirección será un parámetro por referencia normal y corriente.

Espero que esto aclare un poco las cosas, porque estos temas son los más liosos en programación.

Juanito fue contratado para pintar una carretera. El primer día pintó 100 km, el segundo 70 y el tercero 30. Su jefe, preocupado por esta alarmante bajada en su rendimiento le preguntó qué le pasaba, a lo que Juanito le contestó: “Es que el cubo de pintura cada vez me queda más lejos”

El rendimiento de un programa es, a grosso modo, lo que tarda en realizar su cometido. Es, de todas las métricas de calidad, una de las más difíciles de evaluar para mí. No solemos disponer de ejemplos lo suficientemente grandes, en ocasiones el problema aparece en una librería de terceros o, simplemente, se escapa de nuestro control (hasta que aparece). Lo que suele ser común en todos los casos es el mal uso de los tipos String (o similar), y es que en todos los lenguajes que conozco el tratamiento de los String es una mierda (bueno, en realidad suele estar entre una puta mierda y una putísima mierda).

Os expongo como ejemplo lo que me ha pasado con un proyecto recientemente. Consistía en generar unos ficherucos y enviarlos a un servidor vía HTTP. No problem. Los ficheros con los que probamos funcionaban a las mil maravillas y el proyecto pasó a pilotaje dividido en 2 partes: la generación y el envío. Cuando quisieron hacer una prueba enviando datos de un mes (en lugar de un día), aquello explotó. Revisando toda la parte de generación solventamos el problema y pasó de tardar 8 horas a 15 segundos, ¡¡cambiando sólo 3 líneas de código!!. La cosa siguió funcionando hasta la semana pasada, en que empezaron a fallar ficheros de 75 y 40 megas respectivamente, ahora en la parte de envío (solventado el jueves :)).

Éste es un tema para hablar largo y tendido, porque ejemplos hay miles y creo que todos los que hayamos programado habremos sufrido estas pérdidas, en principio inexplicables. Y, además, está relacionado con algo de lo que hablaré dentro de poco (espero): trampear los límites.

La abstracción nos permite simplificar el análisis y resolución de un problema separando las características que son relevantes de aquéllas que no lo son. La relevancia dependerá fuertemente del contexto. Un ejemplo típico de abstracción es una jerarquía de objetos determinada por sus características comunes (mamíferos -> primates -> humanos) (…)
Aunque la abstracción es un concepto general aplicable a cualquier campo, nosotros estamos interesados en la abstracción que proporciona un lenguaje de programación. En este sentido, la aportación más importante ha sido el desarrollo de los lenguajes de alto nivel, que nos permiten utilizar ciertas construcciones de alto nivel en lugar de una secuencia de instrucciones máquina.

Personalmente, siempre he definido la abstracción como la capacidad de, viendo un jarrón, ver también todo el proceso de creación del jarrón; y viceversa. Cambiad “jarrón” por programa y “proceso” por código y tenéis el concepto.