O, bueno, no tanto. Pero es mucho mejor que manejar conexiones con pg_ o mysql_ o mysqli_ o cualquiera sea el prefijo particular del motor de base de datos que usemos.

PDO (PHP Data Objects) es una capa de abstracción sobre las llamadas a bajo nivel de consultas a DB. Se compone de 3 clases: PDO, que se encarga de las conexiones, PDOStatement, que envuelve consultas y resultados y PDOException, su tipo nativo de excepciones.

En su forma más básica, usar PDO puede ser exactamente igual que usar cualquiera de los otros drivers a mano: Simplemente iniciamos una conexion, ejecutamos la consulta y usamos los resultados.

$connection = pg_connect("host=example.com user=tordek password=42");
$result = pg_query($connection, "SELECT * FROM foo");
 
while ($row = pg_fetch_row($result)) {
        echo $row['bar'], ' ', $row['baz'];
}

cf.

$connection = new PDO("pgsql:host=example.com user=tordek password=42");
$result = PDO->query("SELECT * FROM foo");
 
foreach ($result as $row) {
        echo $row['bar'], ' ', $row['baz'];
}

La conexión se crea pasando un “DSN”, Data Source Name ó Nombre de Fuente de Datos, que no es más que un string que indica el tipo de base de datos, su dirección y otros detalles necesarios para su conexión.

query deja de ser una función más, para transformarse en un método de clase, al igual que con mysqli; no hace mucha diferencia, pero limpia un poco el namespace global.

$result es un poco más interesante. Si bien sigue siendo un objeto opaco, ahora es un generador: ya no es necesario llamar a una función para extraer un valor y avanzarlo; eso lo hace foreach, dejando más en claro que estamos haciendo algo con cada elemento.

En fin, cambios principalmente estéticos.

Ahora, cuando empezamos a ver características un poco más avanzadas, empieza a volverse más interesante.

Lo primero es que (omitiendo incompatibilidades entre las consultas SQL) lo único que tenemos que hacer para cambiar el tipo de base de datos que usamos (si antes usábamos una DB Access para pruebas, y lo subimos a un server con MySQL, por ejemplo) es cambiar el string de conexión.

Lo segundo es que agrega soporte global para cosas como consultas preparadas, aunque el motor no las soporte nativamente. Un beneficio de esto es que repetir una misma consulta con diferentes valores se vuelve más simple, y a veces hasta más rápido (si el motor lo soporta, no es necesario mandar (y procesar) la consulta entera, sino sólo los parámetros nuevos):

$query = $conexion->prepare("INSERT INTO foo (bar) VALUES (:bar)");
 
foreach ($array as $val) {
        $query->bindValue(":bar", $val);
        $query->execute()
}

Al hacer prepare, creamos una consulta que tiene un “hueco” para un valor (en este caso, llamado :bar). bindValue hace que el valor de ese hueco sea igual al de $val. Luego, en el foreach se cambia la variable y se ejecuta una consulta en cada ciclo, insertando en la tabla una fila para cada valor de $array.

El otro beneficio, mucho más importante, es que, al usar consultas preparadas, no es necesario preocuparse por inyecciones SQL. El driver se encarga de sanitizar cada parámetro de la manera que vea prudente (mysql_real_escape_string vs pg_escape_string vs SQLite3::escapeString). Por default, asume que todos los parámetros son strings, pero podemos especificar que se trata de otro tipo, de ser necesario.

El beneficio más grande, en mi opinión, es la consistencia: Da igual que el usemos PostgreSQL, MySQL, SQLite o incluso Access; sólo necesitamos conocer una forma de realizar consultas que sirve para casi todos los casos que se nos ocurra. Y todo esto es mencionando tan solo lo más básico que PDO tiene para ofrecer.

Ahora… ¿cuál es la contra?

PDO es una abstracción. Todas las abtracciones tienen dos problemas: el primero es que, por cada capa de abstracción, es necesario recorrer más camino para llegar al «fondo» (en este caso, las llamadas a las DB). Eso implica una pérdida de velocidad, sí, pero una que es casi irrelevante. El otro problema es que las característicás más “hardcore” de las DB se pueden perder, como mysql_server_info. Ambos problemas son casi completamente ignorables, excepto en los casos más extremos.

PDO es parte de PHP desde la versión 5.1. No hay excusa para no usarlo.

Al final, terminamos con una clase Persona, a la que cualquiera le puede decir que se cambie el nombre, el DNI, y cualquier cosa que le corresponda.

Eh, no.

Preguntémosle a Alan Kay, a Barbara Liskov, a Bjarne Stroustrup… y tantos otros, y creo que lo primero que nos van a decir es “Eso no es una clase; es una estructura”, y “¿No se suponía que ibas a encapsular los atributos?”…

A una interfaz siempre se puede agregar más métodos, sin romper nada, pero si borramos el más inútil de nuestros métodos, siempre va a haber alguien que estaba usándolo. Por eso el primer paso a un buen diseño es «No agregar accesores hasta que se demuestre útil. No agregar mutadores hasta que sea totalmente necesario.».

Ah, y, de paso: Las Properties¹ no son más que accesores y mutadores disfrazados.

Tell, Don’t Ask

Traduciendo libremente de The Art of Enbugging, “Supongamos que el diariero viene a la puerta a cobrar lo que le debés de la semana. Te das vuelta, y él saca tu billetera de tu bolsillo, toma dos dólares, y te la devuelve. En vez de eso, el diariero debería pedirle al cliente que le pague los $2,00.”.

Para ponerlo en código (porque sí):

Diariero::Cobrar(Cliente* cliente, int cantidad) throw (EsUnRataException) {
    Billetera* billetera = Cliente->getBilletera();
    if(billetera->contenido() < cantidad) {
        cliente->setBilletera(billetera);
        throw EsUnRataException;
    }
    billetera.remove(cantidad);
    Cliente.setBilletera(billetera);
}

vs.

Diariero::Cobrar(Cliente& cliente, int cantidad) throw (DineroInsuficienteException) {
    Cliente.cobrar(cantidad);
}

Y el primero probablemente necesite revisar si el cliente tiene una billetera, ver si usa monedero o nada, cosa que nos obliga a agregar varios if donde podríamos haber usado polimorfismo.

¿Y mis porotos?

Los Beans (Objetos con accesores y mutadores para cada atributo, más un constructor sin parámetros) parecen ser la necesidad básica del programador de Java moderno (?). Todo tiene que ser un bean, si vamos a usar Hibernate, JPA o <inserte sigla de moda>.

Para muchos, eso es todo lo que se necesita para decidir que todos los mutadores deben ser públicos: ¡Si no no puedo usar Hibernate!… pero no. Hibernate pide que existan, pero no necesariamente que sean públicos: si son protegidos, es más que suficiente.

Of course…

Por supuesto, hay lugares donde los accesores son útiles, y mucho mejores que un constructor repleto de parámetros. Para los que no me crean, revisen la API de Windows:

m_hWindow =
    ::CreateWindow("AppWindow",          /* class name */
                   m_pszTitle,           /* title to window */
                   WS_OVERLAPPEDWINDOW,  /* style */
                   CW_USEDEFAULT,        /* start pos x */
                   CW_USEDEFAULT,        /* start pos y */
                   m_nWidth,             /* width */
                   m_nHeight,            /* height */
                   NULL,                 /* parent HWND */
                   NULL,                 /* menu HANDLE */
                   hInstance,            /* */
                   NULL);                /* creatstruct param */

Todos los NULL y CW_USEDEFAULT podrían haber sido valores por defecto. The Little Manual of API Design, de los creadores de QT, ofrece una alternativa, más similar a la que se usa en QT4:

window = new Window;
window->setClassName("AppWindow");
window->setWindowTitle(winTitle);
window->setStyle(Window::Overlapped);
window->setSize(width, height);
window->setModuleHandle(moduleHandle);

Una opción indiscutiblemente mejor: Ocupa menos líneas, y no involucra memorizar el orden arbitrario de los 11 parámetros del constructor anterior. Podría parecer más larga de escribir, por todos los “window” que se repiten, pero podría reducirse aún más si la API² soporta un estilo más fluido (cada método retorna this), permitiendo algo como:

window = new Window;
window->setClassName("AppWindow")
      ->setWindowTitle(winTitle)
      ->setStyle(Window::Overlapped)
      ->setSize(width, height)
      ->setModuleHandle(moduleHandle);

…de lo cual más de un smalltalker se reirá.

Colecciones

Un lugar donde se nota obviamente la bestialidad de los accesores y mutadores es cuando hay colecciones de por medio. Primero, porque exponer una colección elimina cualquier posibilidad de concurrencia: Si dos métodos quieren modificarla, el único resultado va a ser un bug.

Además, se expone el tipo interno de la colección, removiendo otra de las características de la orientación a objetos: la implementación tiene libertad sobre la interfaz.

Acá hay que aplicar uno de los refactoreos de Fowler (y esto ya debería llegar a volverse regla natural): Encapsulate collection. Es simple: Primero, matamos el setter. No cumple ninguna función útil. Nos aseguramos, además, de que en el constructor se cree la colección. Después procedemos a liberar la responsabilidad de la colección: El getter retorna una copia inmutable. Y, finalmente, agregamos métodos que se encarguen de agregar o remover objetos de la colección.

Voilá: Nuestro objeto está un paso más cerca de ser, bueno, orientado a objetos.

Ley Anti-mutantes

Le debo una a William Stryker.

Una vez, discutiendo sobre OO con un amigo, le dije que todo debería ser inmutable, excepto en raros casos. Me dijo «¡Pero el chiste de la Orientación a Objetos es la mutabilidad del estado!».

Bueno, sí y no.

Más vale no.

Siguiendo con las colecciones, algunas son más críticas que otras. Si sólo tenemos un array de objetos, no importa que cualquiera de sus valores cambie. Ahora, si tenemos una hashtable, más vale que el hash nunca cambie, o van a pasar cosas muy malas.

Cualquier valor del que dependa hashCode (en Java) tiene que ser inmutable. Si no, estaríamos violando el contrato, y sufriremos mil y un bugs sutiles.

¡Bueno, basta, prometo no hacerlo más, pero dejá de escribir!

No todos los atributos de un objeto merecen un getter: Por cada getter exponemos implementación.

Muy pocos atributos merecen un setter: Si tiene que cambiar, que lo haga el objeto sólo.

Las interfaces deben revelar lo menos posible: No digas HashSet donde podés decir Collection.

Encapsulá tus colecciones.

El primer paso a una buena orientación a objetos es la paranoia.

Esta duda surge en Python porque, a primera vista, la única diferencia es que una usa corchetes, y la otra paréntesis: No importa si tengo una lista o una tupla, puedo acceder a sus elementos con [indice], y con cualquiera puedo hacer asignación múltiple (a, b = [1, 2])…

Lentamente las diferencias empiezan a aparecer:

• Las tuplas, como los strings, son inmutables: Una vez que una tupla tiene un valor, no se puede cambiar, sólo crear una nueva.
• Debido a lo anterior, las tuplas son hasheables: Se puede crear un diccionario que use como índice tuplas—pero nunca listas.

Estas diferencias técnicas son las más importantes, y las que justamente las definen.

Ahora, ¿Cuándo es mejor cada una?… En muchos casos realmente no hay diferencia: Si a cualquiera de las dos puedo acceder por índice, o con for… Pero podemos tomar una pista de un lenguaje más estricto: Haskell.

En Haskell, una tupla de 2 elementos es de un tipo diferente al de una de 3 (y no se las puede acceder por índice). Además, las tuplas pueden ser heterogéneas, mientras que las listas son homogéneas. Eso es, puedo tener una tupla (int, String, String), pero una lista puede contener sólo un tipo de datos (Claro, ese tipo puede ser una tupla… pero divago).

Entonces, lo «correcto» (con comillas) es que, si a todos los elementos se los va a tratar de una misma forma (sea con un for, o con map), usamos una lista, pero si cada elemento tiene un significado diferente, lo mejor es una tupla.

void envejecer(struct persona_s *persona) {
    persona->edad++;
}
 
envejecer(tordek);

Edit: Epa. Si no, no compila…

Al omnisciente Google emití una plegaria de ayuda para ver de qué venía tanta alharaca, y me choqué primero con 960 Grid System, que parece ser el más simple de la familia.

Lo usé para armar un diseño que necesitaba rápido, y en seguida vi la mayoría de sus ventajas y desventajas:

Pros:

• Diseñar con “grillas” (grids) da resultados bastante buenos, con una apariencia ordenada.
• Si nos mantenemos dentro de los márgenes que el sistema de grillas propone, armar los diseños es rapidísimo y simplísimo.
• Todos los problemas de compatibilidad de navegadores son cosa del pasado. Claro, sólo en la parte de división en columnas y eso.
• Los templates que traen para Photoshop y demás facilitan el diseño.

Contras:

• ¿División de contenido y presentación? ¿Qué es eso?
• Diseños fijos¹.
• Cambiar una columna implica cambiar las demás para realinear.
• La necesidad de agregar la clase clearfix en un elemento vacío es poco semántico.
• El tamaño no es algo que se pueda decir «minúsculo»².

Los frameworks CSS tienen una utilidad innegable. Ayudan a armar un diseño muy rápidamente, sin tener que preocuparnos por si va a andar o no en “el otro navegador”.

Por otro lado, puristas de la separación³ se van a quejar de que usar un framework CSS vence el propósito de usar CSS: estamos poniendo en el HTML las clases que determinan el tamaño de cada columna, en vez de poner eso en el CSS, como corresponde. Al poner clases sin significado (¿Qué es un «grid_3»?) a los elementos, estamos agregando información que no es nada semántica, y no ayuda en nada a un parser, pero este problema se minimiza si usamos, además de las clases de grid, ids y clases significativos.

En fin, los frameworks pueden dar resultados excelentes si lo que buscamos se presta al diseño en grillas, además de hacerlo rápido y fácil, y sólo los muy extremistas tienen lugar para quejarse —y aún así, tienen una opción de usar los frameworks «correctamete», usándolos primero para «ver cómo va a quedar», y después armar su propia hoja de estilos destilada—.

Acá estoy, probando mi nuevo Window Manager, XMonad. Es un “tiling window manager”, lo que significa que cada ventana ocupa todo el espacio disponible, dividiéndo la pantalla (en realidad, cada escritorio virtual) según lo necesite.

Entre las cosas más grosas que tiene:

(Casi) no necesito usar el mouse.

Hay unos cuantos que se oponen a que abandone a la rata. Algunos infractores son Amarok (el botón de menú de mi teclado no hace nada en la lista de canciones) y las aplicaciones en Java (que, directamente, no puedo usar). Casi todo lo demás, lo hago usando la tecla Windows, acompañada de alguna letra, para navegar las ventanas, o dividirlas, o demás.

Haskell.

Haskell ya es groso de por sí; que XMonad esté programado en Haskell significa el fin de cuelgues y caídas, porque es casi imposible poner un bug.

Las divisiones de ventanas.

Un screenshot habla más que 1k DWORDS¹

Se banca dos monitores. Pero bien.

Lo que siempre quise con KDE era tener un escritorio en cada monitor, y XMonad sí me deja; con Mod-[1-9] cambio la pantalla actual (que elijo con Mod+{w,e}) a uno de los escritorios.

Lo único que no está tan bueno es toda la configuración que requiere para empezar a usarlo; aunque es extremadamente personalizable.

Pruébenlo, si creen en eso de que el mouse es malo y lento, o simplemente tienen ganas de probar algo nuevo. Yo lo uso porque me gusta maximizar mis ventanas tanto como tener varias a la vista :P…

[Comentario humorístico, indirectamente religioso]

Disclaimer: Esto es tan solo una traducción. No representa la opinión del autor de este blog, ni ninguno de sus participantes. Sólo lo estoy haciendo porque quiero visitas en mi blog, y estoy poniendo contenido que, aparentemente, no respeto, en un espacio personal.

—Pero, —algunos se quejarán— ¿y si me equivoqué? ¿Y si después de que lo hice me dí cuenta que no lo quería?

Bien, primero: Si te diste cuenta después, el botón de “estás seguro” no te salva. Obviamente, la opción no es “Ja, lástima, para qué hacés click ahí”. Existe una que sirve de verdad, y que hace mucho nos dimos cuenta que se puede: Deshacer.

Si en Windows se me ocurre borrar un archivo, va a la papelera. Si me equivoqué, lo recupero. Si en Thunderbird borro un mensaje, está en la basura.

Aparte, ¿para qué cambiar el significado de las cosas? Tengo un botón borrar. ¿Qué hace ese botón? ¿Borra? No. Me muestra una ventana que me pregunta “¿Estás seguro?”, y al hacer click en “Sí”, recién borra. ¿Desde cuando “Borrar” significa “Preguntame si quiero borrar”, y “Sí” significa borrar?

Y es imposible quejarse acerca de implementarlo. Si nuestra aplicación usa alguna forma de base de datos, tenemos una marca de “Borrado”. Si usa el sistema de archivos, una carpeta donde almacenamos los archivos ‘Borrados’.

Confirmar es inutil, Deshacer es divino, o como quieras ponerlo, basta de preguntas, y hacé lo que dije.