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.

—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.

Se lo pueden bajar de la página de su autor, y, como todo plugin de vim, lo único que tienen que hacer es descomprimirlo en su .vim/plugins.

No tiene muchos comandos, pero tampoco los necesita:

• :BlogList para ver la lista de todos los posts;
• :BlogNew para crear uno nuevo;
• :BlogOpen id para editar uno; y
• :BlogSend para, finalmente, publicar…

Veamos qué tal….

Edit:

Hasta ahora, me gusta; en particular porque me molestan los WYSIWYG porque lo que ves no se parece en nada a lo que sale (Y no te dan la mitad de los tags… a menos que uses el editor HTML, sacándole todo el chiste.)

Ah, y se banca categorías, tags, y varias otras cosas (aunque no me deja editar el texto del permalink).

Ceceo ya es un poquito más lindo; sólo estás a una bajada y un make de distancia de poder hacer, simplemente '(a b c) => (a b c).

No es la gran cosa, pero es un Lisp…

Y mi problema con bison eran los malditos strings de C; estaba guardadando el puntero al string, en vez de una copia. Ahora sí.

Bueno, sigue sin tener un recolector de basura, pero qué se le va a hacer.

Implementa sólo las raíces de lisp; las 7 primitivas básicas y las 6 funciones derivadas de estas —aunque, la verdad, no las uso…—, según detalla The Roots of Lisp.

En el proceso aprendí varias cosas:

1. Bison me odia¹.
2. Las unions sirven para algo.
3. LISP es todavía más groso que lo que imaginaba.
4. ([a-z]|micro|pico|femto|atto)lisp ya existe.

Bien, le falta mucho para estar completo; en particular, le falta la parte interactiva; por ahora es sólo un lisp-en-c; si se quiere hacer, digamos, (quote a) (y evaluarlo, claro), hay que hacer eval(cons(symbol("quote"),cons(symbol("a"),symbol("nil"))))…

Por esto, tampoco probé si lambda hace lo que debe y demás.

No tiene ningún tipo de números, porque tenía planeados ponerlos cuando haga funcionar el REPL.

Y finalmente, no hay recolector de basura…

Si alguien, por algún bizarro motivo, tiene ganas de usar el código, está en una de mis páginas secretas, liberado bajo la licencia BSD.

¿Será este el comienzo de una nueva era? ¿Una donde empiece a liberar código?… sólo el tiempo lo dirá.

Lo lamento… en serio… no merezco ningún tipo de respeto. Deberían revocarme la membresía del club…

Estoy en un estado de pecado: Me aburro y no tengo ningún proyecto personal para trabajar.

Me siento sucio.

¿Qué listas de correo, foros, canales de chat y demás suelen visitar para discutir de programación?

Tanto general como de lenguajes y tecnologías particulares.

Pero esa no es razón para molestar al usuario. Además, si tu propósito es ahorrar tiempo, ¿por qué gastarlo obligándolo a hacer cosas innecesarias?

El tipo de interfaz no importa

No importa si es una línea de comandos, ventanas múltiples, juegos, si usa el teclado, el mouse, un joystick, o cualquier otra cosa; el usuario es el que importa, no tu programa.

A lo mejor a vos te tome media hora más agregar el código para auto-configurar el programa al instalarse, pero ahorrar un minuto a cien usuarios es todavía más tiempo.

Una regla importante

The Art of Unix Programming, de Eric Raymond, nos cuenta la historia de Unix, y las características de sus programas, interfaces, y qué es lo que lo hace bueno —y malo— para programar. De ésto robo una regla relacionada a la interfaz:

La Regla de Silencio: Si un programa no tiene nada sorprendente que decir, no debe decir nada.

No me avises que abriste el archivo; no me digas que todo fué bien —o, al menos, no me molestes si lo hacés. Una caja de mensajes modal¹ diciendo “Archivo abierto correctamente [OK]” es una pérdida de tiempo y nada más. Si tenés que avisarme, al menos no interfieras. Por ejemplo, el diálogo de “Guardar Contraseña” de Firefox 3, que no interfiere con el flujo.

Cuando dudes, copia

A todos nos gusta ser únicos y originales, pero si diseñamos nuestro programa de manera que el usuario sienta que ya lo usó antes, no va a sentirse intimidado diciendo que es difícil de usar.

Si ya hay un programa que hace lo que vos querés, considerá robar su apariencia (Firefox, con ciertas excepciones, es igual a Internet Explorer). Claro, hay excepciones; DarkRoom, por ejemplo prácticamente elimina la interfaz, sacando del medio cualquier tipo de botón y menú, y sólo las opciones de abrir, guardar, y crear un nuevo archivo… pero DarkRoom tiene una razón para hacerlo.