PDO, ó, por qué todos los tutoriales de PHP llevan a las malas prácticas

Thursday 18 de November de 2010

PDO es una panacea. Es mágico. Hace todo lo que queremos, y más. Y lo hace más fácil, rápido, y seguro que lo que podemos hacerlo nosotros.

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.

Eso no es POO. Es CACA.

Friday 16 de October de 2009

Aparentemente, programar usando un diseño orientado a objetos significa hacer un dibujito UML, decirle a nuestro IDE que cree un montón de atributos (obviamente todos privados; no querríamos romper el encapsulamiento), y luego generar todos los accesores y mutadores, no vaya a ser que después no podamos cambiar algo.

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 Properties1 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 API2 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.

  1. que admito amar
  2. O el lenguaje, con un constructo with o similar

Listas vs. Tuplas

Tuesday 28 de April de 2009

En la lista de PyAr hace no mucho alguien preguntó, «¿Cuál es la diferencia entre una tupla y una lista?». Acá hago una síntesis de las respuestas, y agrego mis notas.

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.

Gente Molesta

Sunday 26 de April de 2009

Las personas que más me molestan son las que me agregan al MSN, y la tercera pregunta que me hacen (después de «¿Te puedo hacer una pregunta?» y «¿Por qué me insultás así?») es «Sabés robar una contraseña?».

Chiste pésimo

Friday 27 de March de 2009
  • Tordek: Y a ver cuando aprendes Lisp vos, ¿eh?
  • Baltha: ¡Ya se la mitad de Lisp, ¿sabés? ¡¿Sabés?!
  • Tordek: ¿Qué, sabés ‘(‘?