Mostrando entradas con la etiqueta programación. Mostrar todas las entradas
Mostrando entradas con la etiqueta programación. Mostrar todas las entradas

lunes, 15 de abril de 2019

Cuando unos leguajes tratan los arrays por referencia y otros por copia

¿Qué ocurre cuando asignamos un array a otro? En la mayor parte de los lenguajes, lo habitual es que la nueva variable sea un puntero (referencia) al primer array. Por ejemplo, en Python:

array2 = array1 = {'uno': 1, 'dos': 2}

print('array1 antes:', array1)
print('array2 antes:', array2)

array2['dos'] = 22
array1['tres'] = 3

print('array1 después:', array1)
print('array2 después:', array2)


La salida de este script sería la siguiente:

~ $ python3 testarray.py 

array1 antes: {'uno': 1, 'dos': 2}
array2 antes: {'uno': 1, 'dos': 2}
array1 después: {'uno': 1, 'dos': 22, 'tres': 3}
array2 después: {'uno': 1, 'dos': 22, 'tres': 3}


Como era previsible, al cambiar algo en array1 o en array2, el otro array se modifica, porque las dos variables son una referencia al mismo array. (En Python a este tipo de datos se le llama diccionario, pero podemos asumir que es equivalente al array asociativo de PHP)

Este sencillo ejemplo es muy adecuado para explicar a alguien lo que son las referencias. Se ve claramente que cambiar algo en una variable tiene efectos colaterales.

Sin embargo, podemos encontrarnos sorpresas en otros lenguajes. PHP, por ejemplo, copia el array en la nueva variable y a partir de ese momento, son dos referencias independientes. Mucho cuidado si nuestro array contiene muchos datos, se duplica el consumo de memoria:

<?php 
$array1 = $array2 = array("uno" => 1, "dos" => 2);

echo "array1 antes:"; var_dump($array1); echo "\n";
echo "array2 antes:"; var_dump($array2); echo "\n";

$array1["tres"] = 3;
$array2["dos"] = 22;

echo "array1 después:"; var_dump($array1); echo "\n";
echo "array2 después:"; var_dump($array2); echo "\n";


La salida de este script es la siguiente:

~ $ php testarray.php 

array1 antes:array(2) {["uno"]=> int(1), ["dos"]=> int(2)}
array2 antes:array(2) {["uno"]=> int(1), ["dos"]=> int(2)}

array1 después:array(3) {["uno"]=> int(1), ["dos"]=> int(2), ["tres"]=> int(3)}
array2 después:array(2) {["uno"]=>, int(1), ["dos"]=> int(22)}

¿Qué ha pasado en este caso? Las dos variables son independientes, los cambios en una no afectan a la otra. Cada una apunta a una región de memoria diferente. En PHP se puede conseguir el mismo comportamiento que en otros lenguajes, esto es, que asignar una variable a otra por referencia:

<?php 
$array1 = array("uno" => 1, "dos" => 2);
$array2 = &$array1;

echo "array1 antes:"; var_dump($array1); echo "\n";
echo "array2 antes:"; var_dump($array2); echo "\n";

$array1["tres"] = 3;
$array2["dos"] = 22;

echo "array1 después:"; var_dump($array1); echo "\n";
echo "array2 después:"; var_dump($array2); echo "\n";

En este caso el comportamiento es el mismo que en el primer script en Python.
La expresión $array2 = &$array1asigna por referencia la variable 1 a la variable 2.

¿Qué comportamiento es deseable o más conveniente en un lenguaje de programación? La aproximación de PHP puede parecer más ineficiente, pero si reflexionamos un momento, tiene algo a su favor: es consistente.

<?php
$a = $b = 4;
$a = 5;
var_dump($a); var_dump($b);

La salida es:

int(5)
int(4)

Cada variable es una copia.

En Python, los tipos de datos simples sí que se asignan por copia:

Python 3.6.7 (default, Oct 22 2018, 11:32:17) 
>>> a = b = 4
>>> a = 5
>>> a
5
>>> b
4
>>>

También se ve cómo son variables independientes. 

Todos los tipos de datos, simples y compuestos, se comportan igual PHP, sin embargo, en Python los tipos de datos compuestos (diccionarios, listas,... se asignan por referencia y los tipos de datos simples (enteros,...), se asignan por copia.

Esto no es bueno ni malo... pero hay que estar atento.

jueves, 7 de mayo de 2009

Desarrollando aplicaciones para dispositivos móviles: vuelta al pasado

Parecía que la idea de estandarizar los desarrollos y las plataformas ya estaba asentada, que todo el mundo tenía claro que el desarrollo "cross-platform" era preferible a tener que lidiar con distintos sistemas, dispositivos, APISs y demas.

Pero no. De un tiempo a esta parte, con la creciente implantación de los "smartphones", estamos volviendo atrás en este aspecto. En estos momentos ya tenemos unas cinco plataformas a las que atender si queremos desarrollar aplicaciones para móviles (seguro que me dejo alguna en el tintero):

Cada plataforma utiliza sus propias herramientas, APIs y lenguajes. Así no hay manera.

Parece que se pretende excluir a los desarrolladores "amateurs" del mercado de vendedores de aplicaciones o que estos se decanten por una plataforma en exclusiva.

Personalmente me sentía muy tentado por empezar a programar algunas cosillas para móviles, pero esta situación me desanima mucho. La única forma que me parece asumible es usar el mínimo común múltiplo, J2ME, y no estoy seguro de que todas las plataformas lo acepten, aparte del propio lío de "configurations" y "profiles" de J2ME.

martes, 8 de abril de 2008

Patrones de diseño para torpes - 3ª parte

El patrón "Singleton"


Uno de los patrones de diseño más conocidos es el patrón "Singleton". Con este patrón se garantiza que sólo hay una instancia activa de una determinada clase.

Supongamos que tenemos una base de datos y queremos mantener una única conexión activa. Otro caso puede ser una clase que se dedique a grabar registros o trazas en un fichero. Imaginemos un objeto que descarga ficheros por FTP.

En todos estos casos puede ser conveniente tener un único objeto que realice el trabajo y garantizar que no hay varias instancias, por ejemplo, para no saturar una base de datos con conexiones, o no tener accesos simultáneos al mismo fichero, etc.

En la documentación oficial de PHP se muestra un ejemplo de este patrón para este lenguaje.

Otros patrones de diseño


Por motivos profesionales, últimamente casi programo exclusivamente con PHP. En developerWorks hay un artículo muy interesante donde amplían otro artículo anterior en el que presentaban cinco patrones básicos.

Explican y ponen ejemplos en PHP para los patrones "Adapter", "Iterator", "Decorator", "Delegate" y "State". Es una lectura obligatoria para cualquier desarrollador de PHP.

viernes, 28 de marzo de 2008

La pesadilla de los programadores y diseñadores

Nos contaba hace un par de días Blanca Salvatierra en un artículo la existencia de una página web que instaba a los usuarios del navegador Internet Explorer 6 a actualizarse o cambiar de navegador.

Realmente es un dolor tener que desarrollar páginas web que se vean bien en todos los navegadores. Aunque la mayoría de los diseñadores y programadores ya se saben los "trucos" para conseguirlo, no deja de ser una gran pérdida de tiempo y esfuerzo.

A día de hoy, los lectores de Público.es utilizan cinco navegadores principalmente (porcentajes aproximados): Internet Explorer 7 (~ 30 % de los usuarios) , Internte Explorer 6 (~ 30%), Mozilla Firefox (~ 30%), Apple Safari (~ 2%) y Opera (~1%).

De estos cinco navegadores, el Internet Explorer 6 (abreviado como IE6) es el menos compatible, para que una página que se ve bien en el resto se vea en IE6 muchas veces hay que recurrir a trucos y "chapucillas".

¿Cómo puede ser ésto? Las páginas web actualmente se basan (principalmente) en tres "lenguajes" con funciones diferenciadas, todos ellos estandarizados por organizaciones de internacionales: HTML, CSS y JavaScript.
El lenguaje HTML es el que contiene el texto o contenido significativo de una página web, el CSS se encarga de formatear y dar estilo a este texto. Finalmente, con JavaScript podemos hacer que el usuario interaccione con una página web de diferentes formas.

El problema es que en teoría todos los navegadores soportan estos tres lenguajes, pero en la práctica, cada uno lo hace a su manera, y de todos ellos, el IE6 es el que más extraño se comporta.

Supongamos que tenemos el siguiente fragmento de HTML (simplificado):

Prueba con HTML





Título del documento





Listado de palabras



  • Palabra 1

  • Palabra 2

  • Palabra 3

  • Palabra 4

  • Palabra 5




Esto es un párrafo de texto, párrafo de texto,
párrafo de texto,párrafo de texto, párrafo de texto,
párrafo de texto, párrafo de texto.
Esto es otro párrafo de texto, párrafo de texto,
párrafo de texto, párrafo de texto, párrafo de texto,
párrafo de texto, párrafo de texto.



Esto es un texto en el pie de la página.





Este documento se vería así en los distintos navegadores (pulsar para ampliar):

Captura navegadores sin estilos

No hemos especificado ningún estilo, así que los navegadores formatean el texto como les parece, aunque el resultado es muy parecido en todos los casos.

Ahora establecemos que este HTML utilice el siguiente CSS que lo formateará. Este CSS es bastante ingenuo, ya que no tiene en cuenta las peculiaridades de los distintos navegadores. Lo que pretende es establecer una página centrada, con una cabecera gris, un cuerpo azul con dos columnas, verde y amarilla y un pie de página rojo:
#contenedor {
border: solid 1px black;
padding: 10px;
width: 750px;
margin: 0 auto;
}
#cabecera {
background-color: gray;
width: 730px;
}
#cuerpo {
background-color: blue;
width: 730px;
}
#pie {
background-color: red;
width: 730px;
}
#colizda {
width: 180px;
background-color: green;
float: left;
padding: 10px;
}
#coldcha {
width: 510px;
background-color: yellow;
float: left;
padding: 10px;
}

Las diferencias entre navegadores son notorias:





















ff-antes.pngMozilla Firefox
opera-antes.pngOpera
safari-antes.pngSafari
ie7-antes.pngExplorer 7
ie6-antes.pngExplorer 6

Hacemos algunos ajustes adicionales conseguimos al fin que en todos se vea igual:
body {
/* Para centrar en IE6 */
text-align: center;
}
p, ul {
margin: 0;
padding: 0;
}
ul {
list-style: none;
}
#contenedor {
margin: 0 auto;
width: 770px;
}
#contenido {
border: solid 1px black;
padding: 10px;
width: 750px;
/* Para expandir la capa hacia abajo en
Safari, Opera y Firefox */
float: left;
/* Para compensar el apaño de IE6 en body */
text-align: left;
}
#cabecera {
background-color: gray;
float: left;
width: 750px;
}
#cuerpo {
background-color: blue;
float: left;
width: 750px;
}
#pie {
background-color: red;
float: left;
width: 750px;
}

Y éste es el resultado:





















ff-despues.pngMozilla Firefox
opera-despues.pngOpera
safari-despues.pngSafari
ie7-despues.pngExplorer 7
ie6-despues.pngExplorer 6

Lo más chocante es que para que en IE6 se vea la página centrada tenemos que establecer una propiedad ilógica: que el texto en la etiqueta "body" esté centrado (text-align: center;)
Por otra parte, los dos Internet Explorer expanden y muestran la capa contenedora de las columnas (fondo azul), mientras que en los demás hay que hacerla visible explícitamente.

En general el comportamiento de IE7, Firefox, Opera y Safari es muy similar, los problemas siempre los suele dar el IE6.

Se comprende entonces que los diseñadores de páginas web estén hartos del Explorer 6 y su peculiar forma de interpretar los estándares.

Créditos: gracias a Daniel Solana Tacón, diseñador web de Público por ayudarme con estos CSS.

martes, 22 de enero de 2008

Los informáticos contamos empezando por 0

A veces tengo que llamar a un servicio técnico que funciona de la siguiente forma: llamo, digo quién soy, qué problema tengo y a continuación me validan una contraseña que nos han asignado. Por seguridad (no es muy recomendable decir la contraseña en voz alta rodeado de gente), en vez de pedirme la contraseña completa, me piden sólo algunas letras o cifras de la misma: "por favor, dígame las posiciones 1, 6 y 7 de su contraseña".

La primera vez que llamé no fui capaz de decirle las letras que me pedía hasta el tercer intento por lo menos. ¿Qué pasó?
Sencillo: estaba contando los caracteres como si estuviese programando, empezando por 0.

Normalmente, procederíamos así a la hora de contar (en la línea de arriba, la palabra, en la de abajo, la numeración o posiciones):
 C | o | n | t | r | a | s | e | ñ | a

 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10

Sin embargo, un programador contará así:
 C | o | n | t | r | a | s | e | ñ | a

 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

Casi todos los lenguajes de programación y sistemas siguen este esquema: empezar a contar desde cero. ¿Por qué se hace de esta forma tan poco intuitiva?
La razón que me parece más sencilla es la siguiente: el número 0 también contiene información.

Cuando utilizamos los números naturales para contar empezamos con el 1 porque el 0 no tiene significado: si no hay nada que contar, no contamos. Si hay algo que contar, empezamos por la unidad: "una manzana, dos manzanas, ..."

Sin embargo en los ordenadores cuando contamos en realidad lo que estamos es enumerando direcciones o posiciones.
Vamos a ver un sencillo ejemplo:

Supongamos que tenemos una ínfima memoria RAM de 8 bytes. Esto quiere decir que sólo disponemos de 8 "huecos", "casillas", posiciones o direcciones de memoria.
Podemos pensar en la memoria RAM como en un montón de buzones de correo apilados.

Si queremos acceder a una de estas direcciones para recuperar el contenido o escribir algo necesitamos saber su dirección. Como sabemos, los ordenadores sólo utilizan ceros y unos para contar, así que con tres bits seremos capaces de direccionar toda la memoria:
000 - 001 - 010 - 011 - 100 - 101 - 110 - 111

Estas ternas de números binarios son en el sistema decimal:
0 - 1 - 2 - 3 - 4 - 5 - 6 - 7

Así que tendremos el buzón 0, el buzón 1, el buzón 2, ... hasta el buzón 7. Total, 8 buzones.
Si nos hubiésemos empeñado en numerar los buzones desde el número 1 no nos hubiesen bastado 3 bits (*), puesto que el número 8 en binario es 1000 (**).

Los mayoría de los lenguajes de programación trata las cadenas de texto de la misma forma. Por ejemplo, el lenguaje PHP (con el cual están programados estos blogs) tiene una función o instrucción para extraer parte de una cadena de texto:
substr('Contraseña', 1, 5) nos proporciona 5 caracteres de la palabra 'Contraseña' a partir de la posición 1, esto es, "ontra".
Como ven, también cuentan desde 0.


Notas

(*) Existe una regla muy sencilla para saber cuántas posiciones podemos abarcar con n bits: 2^n.

  • Con 3 bits podemos contar 2^3 = 8 posiciones, esto es, del 0 al 7.

  • Con 4 bits podemos contar hasta 2^4=16 posiciones (del 0 al 15).


Un ordenador que funcione con 32 bits (los Pentium "clásicos", por ejemplo) podrá direccionar 2^32 = 4.294.967.296 direcciones, es decir, 4 Gigas de memoria. No compre más memoria que esta cantidad para su viejo Pentium. No podrá utilizarla.

(**) A los informáticos también se nos dan muy bien las potencias del número 2. Pregúntenle a un programador "¿cuanto es 2^10?". Seguro que le contesta con bastante rapidez ;-)

miércoles, 28 de noviembre de 2007

Patrones de diseño para torpes - 2ª parte

Seguimos la serie de artículos sobre patrones de diseño. Vamos a ver otro de los patrones más típicos.

El patrón "Observer"


Usted es el/la encargado/a de la hemeroteca de un laboratorio. Periódicamente se reciben revistas sobre diferentes temas y con una periodicidad variable: unas son semanales, otras quincenales y otras mensuales.

Una de sus funciones es hacer llegar las revistas a diferentes personas de diferentes departamentos. Por ejemplo, la revista "Genómica de las hormigas" debe llegar al laboratorio de genética, la revista "Cristalografía de minerales venusianos" va al departamento de cristalografía, etc.

Imagínese ahora que cada persona de cada departamento estuviese cada dos por tres llamándole para preguntarle si ha llegado su revista, o, peor aún, entrara en su despacho y revolviese su mesa y el archivo buscando su preciada revista.

Obviamente, las personas no trabajamos así, en este ejemplo, lo más lógico, cómodo y organizado es que Ud. mantenga una lista de las personas o departamentos y notifique a estos la llegada de las revistas. Cada departamento decide entonces qué hacer con la revista (fotocopiarla, escanearla, ..., incluso leerla)

Cuando desarrollamos programas hay distintos módulos o unidades funcionales que deben interaccionar entre ellos, pero esta interacción no siempre es tan limpia o aséptica como sería deseable. En ocasiones un módulo, clase, función (o lo que sea) llega a "meterse en el despacho" de otra unidad funcional.

Pongamos un ejemplo más "software". En el libro "Desing Patterns" que mencionábamos en el anterior artículo proponen dos ejemplos muy ilustrativos:

  • Una hoja de cálculo puede tener varias vistas (formas de presentar los datos) activas en un momento dado: un gráfico de barras, una rejilla de datos, un gráfico por sectores, ...
    Si los datos cambian, todas las vistas deben actualizarse. La forma más cómoda es tener un objeto "Datos" que informa a todos los objetos "Presentación" de los cambios que se producen. Estos objetos "Presentación" ya se ocuparán ellos de actualizarse.
    Lo bueno de este patrón es que los objetos "Presentación" no deben "meterse en el despacho" del objeto "Datos" para consultar si estos datos han cambiado o no.

  • El otro ejemplo que se propone es un reloj. Tenemos un objeto "Temporizador" que cada segundo notifica a todos los objetos que le observan (un "RelojDigital", un "RelojAnalógico", ...) de que algo ha cambiado.


Distinguimos entonces el objeto observado y los objetos observadores. El objeto observado debe mantener una relación de los objetos que le observan y una forma de notificarles. Por su parte, los objetos observadores, sean del tipo que sean, deben implementar alguna funcionalidad para actualizarse en función del nuevo estado del objeto observado.

En el artículo "Five common PHP design patterns" nos proponen algunos ejemplos en PHP muy interesantes. Vamos a adaptar un poco el ejemplo correspondiente al patrón observer y "traducirlo".

<?php

interface IntfzObservador {
function hayCambios($observado, $datos);
}

class NotificadorUsuarios implements IntfzObservador {
public function hayCambios($sender, $args) {
// Código para notificar: mensaje en consola,
// registro en un fichero 'log', etc.
echo("Se ha añadido '$args' a la lista de usuarios.n");
}
}

class GrabadorBBDDUsuarios implements IntfzObservador {
public function hayCambios($sender, $args) {
// Código para grabar en BBDD.
echo("Se ha grabado el usuario '$args' en la base de datos.n");
}
}

class AltaSistemaUsuarios implements IntfzObservador {
public function hayCambios($sender, $args) {
// Código para crear la cuenta de usuario.
echo("Se ha creado una cuenta para el usuario '$args'.n");
}
}

class ListaUsuarios {
private $observadores = array();
public function anadirUsuario($nombre) {
foreach($this->observadores as $obs)
$obs->hayCambios($this, $nombre);
}
public function anadirObservador($observador) {
$this->observadores[]= $observador;
}
}

/** Código de pruebas **/
$nu = new NotificadorUsuarios();
$gbu = new GrabadorBBDDUsuarios();
$asu = new AltaSistemaUsuarios();
$lu = new ListaUsuarios();
$lu->anadirObservador($nu);
$lu->anadirObservador($gbu);
$lu->anadirObservador($asu);
$lu->anadirUsuario("Juana");
$lu->anadirUsuario("Pedro");

?>

Las clases observadoras, independientemente de su naturaleza, deben tener un método común para ser notificadas por el observado. Esto puede garantizarse definiendo una interfaz (IntfzObservador en el ejemplo) y forzando a que estas clases observadoras implementen la interfaz.

El código es autoexplicativo. Tenemos dos observadores que "reaccionan" de diferente forma a los cambios en el observado. Uno de ellos de dedica a notificar los usuarios nuevos, otro los graba en una base de datos, otro los da de alta en el sistema, ...

Cada vez que se añade el objeto ListaUsuarios añade un usuario, notifica a sus observadores y éstos hacen sus tareas, sin interferir con este objeto observado.

Veamos la salida de este programa:

~ $ php test.php
Se ha añadido 'Juana' a la lista de usuarios.
Se ha grabado el usuario 'Juana' en la base de datos.
Se ha creado una cuenta para el usuario 'Juana'.
Se ha añadido 'Pedro' a la lista de usuarios.
Se ha grabado el usuario 'Pedro' en la base de datos.
Se ha creado una cuenta para el usuario 'Pedro'.
~ $

martes, 30 de octubre de 2007

Patrones de diseño para torpes - 1ª parte

Hoy hablamos de los famosos patrones de diseño o design patterns. Hay montones de libros y artículos sobre el tema, empezando por el famoso libro "Desing Patterns", de Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides.

El caso es que no me acabo de enterar muy bien (a ratos soy un poco lerdo) y me pierdo un poco, así que he decidido explicarme a mí mismo algunos patrones de diseño típicos.



Una de las cosas que no me gustan es que las explicaciones y ejemplos que se proponen en muchos libros o artículos están relacionadas con objetos "sofware". ¿No es acaso la programación orientada a objetos una ayuda para representar o modelizar sistemas u objetos "reales"?

Pues voy a tratar de explicar los patrones de diseño con ejemplos cotidianos, no "software", a ver qué tal me sale.

El patrón "Factory"


Este patrón de diseño es muy útil cuando tenemos que crear (=instanciar) distintos objetos que tienen algo en común (=comparten una interfaz). Ya me he liado con tecnicismos.

Imaginemos que vamos con nuestra cámara de fotos y el coche teledirijido de nuestr@ hij@ a una tienda de electricidad para comprar pilas. El enfoque "sencillo" (=aplicando un patrón de diseño) es decirle al vendedor: "quiero pilas para estos cacharros". El enfoque complicado (=instanciar cada objeto por separado) es decirl: "quiero pilas AAA (de 1,5 V) para la cámara, una pila de petaca de 9V para el mando y pilas AA para el cochecito".

Analicemos el objeto demandado en cuestión: las pilas. ¿Qué caracteriza a una pila? Su voltaje, su tamaño y poco más. Es decir, las pilas tienen una interfaz común, pero son diferentes unas de otras. Si tuviésemos que modelizarlas usando clases tendríamos la clase PilaAAA, PilaPetaca, PilaAA y alguna más.
mi_pilaAAA = new PilaAAA()
mi_pilaPetaca = new PilaPetaca()
mi_pilaAA = new PilaAA()

Cada uno de estos objetos instanciados deberíamos asociarlo a su receptor:
camara_fotos.setPila(mi_pilaAAA)
mando_distancia.setPila(mi_pilaPetaca)
cochecito.setPila(mi_pilaAA)

¿No sería más cómodo tener algo (=el dependiente) que se encargase de darnos las pilas con sólo decirle para qué las queremos?
dependiente = new Dependiente()
camara_fotos.setPila(dependiente.damePilas(this))
mando_distancia.setPila(dependiente.damePilas(this))
cochecito.setPila(dependiente.damePilas(this))

Parece un gran avance, ¿no? Cada objeto cliente (la cámara, el mando a distancia y el cochecito) se despreocupan de saber qué características tienen las pilas que usan. Simplemente le piden pilas al dependiente y listo.
Es tarea del dependiente saber qué tipo de pilas tiene que devolver, y la forma de hacerlo (=implementación) es transparente para el cliente. Hoy puede que el dependiente mire un catálogo, mañana puede que consulte una base de datos y pasado mañana a lo mejor solicita un fichero XML de aparatos y pilas, pero esto no es algo que deba saber el objeto cliente.

Bien, pues simplificando bastante, el patrón "Factory" es esto mismo. Un objeto especializado se encarga de instanciar objetos para clientes, y estos utilizan los métodos que proporciona la interfaz del objeto recibido, pero sin saber nada de las interioridades del objeto, ni siquiera qué tipo de objeto es (=a partir de qué clase está instanciado).

Veamos un ejemplo un poco más "software". Imaginemos que tenemos una clase sencilla en una aplicación de blogs que se dedica a "pintar" en pantalla el título, autor y fecha de publicación de algunos envíos.
Estos envíos pueden estar guardados en una base de datos o provenir de un RSS, por ejemplo.

A la clase cliente (la que "pinta" en pantalla") le da igual el origen de los datos, sólo quiere los datos. Voy a poner un poco de código --utilizaré Python, que me gusta bastante ;-) y me parece muy claro.
class EnviosRSS:
def __init__(self, url_rss):
# Hacemos algo para traer los datos de la url
self.post = lo_que_sea
def dameAutor(self):
return self.post.autor
def dameTitulo(self):
return self.post.titulo
def dameFecha(self):
return self.post.fecha

class EnviosBBDD:
def __init__(self):
# Hacemos algo para traer los datos de la base de datos
self.post = lo_que_sea
def dameAutor(self):
return self.post.autor
def dameTitulo(self):
return self.post.titulo
def dameFecha(self):
return self.post.fecha

class EnviosFactory:
def dameEnvios(self, url=''):
if url == '':
return EnviosBBDD()
else:
return EnviosRSS(url)

# código cliente
factory = EnviosFactory()
envios1 = factory.dameEnvios()
envios2 = factory.dameEnvios('http://davidasorey.net/index.php/feed/rss')
# pintamos los envios
print envios1.dameTitulo()
print envios1.dameAutor()
print envios1.dameFecha()
print envios2.dameTitulo()
print envios2.dameAutor()
print envios2.dameFecha()

Unas notas sobre la terminología "pythonera": los métodos se definen con def, las clases se instancian llamando al nombre de la clase, sin new. El constructor (algo parecido, realmente) es el método __init__. Por últimos, los métodos al definirse siempre deben llevar el self por delante. Realmente Python no es un lenguaje orientado a objetos puro, pero ni falta que le hace ;-)

Para finalizar, muy importante: esto no es una lección magistral. Es mi visión personal del patrón "Factory", que puede ser errónea e incompleta. Se admiten (se ruegan) sugerencias y comentarios.

miércoles, 3 de octubre de 2007

La pesadilla de los “encoding”

Estamos en el año 2007. Internet forma parte de las vidas de muchas personas. Pues, por increíble que parezca, algun@s todavía tenemos que lidiar con problemas cuyo origen se remonta a varias décadas atrás.

Antecedentes: en los años 60 se aprobó un código estándard para la codificación de caracteres alfanuméricos. Era una buena idea, puesto que hasta el momento, cada fabricante usaba más o menos el código que le daba la gana. Con este código, ASCII, se consiguió una cierta estandarización.

La idea era utilizar 7 bits (lo que nos da 2^7 = 128 códigos diferentes) para representar los caracteres y símbolos del lenguaje escrito. Por ejemplo, el 65 (0100 0001 en binario) representaba la letra A (en mayúscula), el 32 (0010 0000 en binario) representaba el espacio en blanco, etc.

Magnífica ocurrencia, si tu idioma es inglés. En seguida l@s europe@s nos dimos cuenta de que este sistema no era muy válido: muchos caracteres no tenían representación: eñes, cedillas (ç), vocales con diversos acentos (á, à, â, ä, ...)

La solución que se encontró fue rápida: ya que un byte tiene 8 bits y el ASCII sólo utiliza 7 (el octavo bit se destinó para control de errores), se decidió utilizar ese octavo bit para ampliar el rango de caracteres disponibles (2^8 = 256). Surgía la codificación ISO-8859.

También parecía una buena idea, pero no resultó ser tan idónea: algunos idiomas necesitaban una ñ, por ejemplo, pero otros necesitaban una ç. Algunos idiomas europeos sólo necesitaban un tipo de acentos, pero otros utilizaban más. El resultado de estas necesidades diferentes fue que no se llegó a una única codificación utilizando 8 bits. La codificación ISO-8859-1 (también llamada Latin-1) sirve para casi todos los idiomas de Europa Occidental, la ISO-8859-15 es una revisión de ésta que incluye el símbolo del euro (€). La codificación ISO-8859-16 (Latin-2) se adapta a idiomas de Europa Oriental.

Por otra parte, otros fabricantes decidieron hacer lo que les pareció con el 8º bit no utilizado. Añadieron nuevos símbolos o caracteres extraños al ASCII estándar. Surgen así diversos "codepages" parcialmente compatibles entre ellos (CP437, Windows-1252, ...) y con ISO-8859

Estas codificaciones extendidas supusieron una mejora, pero no fueron el remedio definitivo. Además de mantenerse ciertas incompatibilidades, no servían para codificar algunos idiomas no alfabéticos (idiomas fonéticos o ideográficos).

La siguiente idea fue Unicode: utilizar 2 byte completos (o más) para representar los caracteres o símbolos. Con 2 bytes (2^16) ya tenemos 65.536 posibilidades o símbolos diferentes. Unicode consigue representar y asignar un código único a prácticamente cualquier símbolo escrito en cualquier idioma humano. Además, mantiene la compatibilidad con ASCII y Latin-1: los 128 primeros caracteres de Unicode se corresponden con la codificación ASCII, y los 128 siguientes (hasta 256) se corresponden con Latin-1.

El problema de Unicode es la transmisión de los datos: es absurdo reservar siempre dos bytes para un carácter cuando la mayor parte de los caracteres Unicode que se pueden transmitir en un momento dado "caben" en un byte. Las diferentes formas de transmitir e interpretar los caracteres Unicode son los famosos UTF, siendo los más utilizados UTF-8 y UTF-16.

Seguiremos con el tema.

martes, 24 de julio de 2007

Gambas tutorial

Gambas is an IDE ("Integrated Development Environment") oriented towards RAD ("Rapid Applications Development"), like the popular propietary programs Microsoft Visual Basic or Borland Delphi.You may read the tutorial here: Gambas Tutorial.