El programa usa una serie de capas que corresponden a distintos elementos como textos de armados, tipos de armado, etc. Esta separación es muy prolija y tiene la ventaja de que permite diferenciar muy bien a posteriori a qué función estructural pertenece cada elemento de dibujo.

Sin embargo, la profusión de capas hace poco manejable el dibujo final y es necesario reducirlas a un subconjunto más reducido que, normalmente, se corresponderá también a un criterio personal de dibujo.

Este post explica cómo manejo el cambio de capas a partir de los planos generados en el CypeCAD, y otro día comentaré el criterio de capas de suelo utilizar, ya que lo he estado utilizando varios años y la gente que lo ha probado lo ha adoptado como suyo .

Volviendo a la gestión de capas de CypeCAD, si bien el programa permite definir a qué capas se deben traducir los distintos elementos, la interfaz para hacerlo es bastante engorrosa, ya que exige recorrer una a una las numerosas capas que incluye por defecto y esta configuración no se puede guardar para poder utilizarla en otra máquina o recuperarla al actualizar la aplicación.

Para automatizar la resolución del problema de unificación y estandarización de capas, genero los planos usando las capas por defecto de CypeCAD y luego utilizo un script que he escrito en Python que traduce sus capas a otras personalizadas.

La traducción entre el nombre de capa original y el deseado se define en un archivo en formato de texto plano llamado capas.txt con una sintaxis muy sencilla:

CIM_COTAS|e.cotas
CIM_CUADRO_ARRANQUE|e.1.gordas
CIM_CUAD_VIG_ATA|e.1.gordas
CIM_CUAD_VIG_CEN|e.1.gordas
CIM_CUAD_ZAPATA|e.1.gordas
CIM_DIB_ARMADOS|e.armado.gordo

Las capas sin la correspondiente capa “traducida” tras la barra vertical no cambian su nombre, por lo que las nuevas capas que puedan ir incorporando en nuevas versiones de la aplicación se mantienen intactas.

Para la ejecución del script es necesaria la instalación del intérprete de Python, y el propio script ofrece información sobre los parámetros que acepta:

$python cambia_capas_cype.py

Quienes usen el programa AutoCAD de AutoDesk, pueden completar la estandarización de capas bien insertando el DXF en un dibjo nuevo iniciado con una plantilla en la que estén definidas las propiedades de las capas, o bien usando la función LAYTRANS. En un futuro es posible que amplie el script para definir las propiedades de las capas en el propio DXF procesado.

Descargar aplicación de cambio de capas para DXF de CypeCAD.

Introducción a la programación orientada a objetos

Este artículo es una introducción a la programación orientada a objetos (POO, o OOP por sus siglas en inglés), uno de los paradigmas de programación estructurada más importante hoy en día.

El artículo usa el lenguaje Python para los distintos ejemplos, y explica la implementación de la POO en ese lenguaje, aunque aborda conceptos generales que son fácilmente trasladables a otros lenguajes.

Los fragmentos de código se señalan usando un estilo de texto diferente (ancho fijo) y, cuando se utiliza el intérprete de python, se prefija cada línea con los símbolos ‘>>>’.

Esta introducción presupone conocimientos básicos de programación y del lenguaje python.

Formas de pensar: paradigmas de programación

Uno de los elementos básicos a la hora de realizar un programa es la modelización del problema que pretende resolver. Es preciso localizar las variables y los aspectos relevantes, así como comprender los pasos necesarios para obtener el resultado a partir de los datos iniciales, etc. Es decir, abstraer el problema, reduciendo sus detalles de forma que podamos trabajar con pocos elementos cada vez.

La algoritmia plantea la forma óptima de resolver problemas concretos, tales como la ordenación de una lista de elementos, la búsqueda de un elemento en un conjunto, la manipulación de conjuntos de datos, etc. Sin embargo, no proporcionan un marco general, un enfoque, que nos permita plantear y formular las soluciones a un problema de forma coherente.

Los paradigmas de programación llenan ese hueco, proporcionando guías tanto sobre cómo realizar la abstracción de los datos como sobre el control de la ejecución. Es decir, los paradigmas de programación son herramientas conceptuales para analizar, representar y abordar los problemas, presentando sistematizaciones alternativas o complementarias para pasar del espacio de los problemas al de las implementaciones de una solución.

Es muy recomendable y productivo comprender el enfoque de distintos paradigmas, puesto que presentan estrategias alternativas, incrementando nuestras herramientas disponibles y haciéndono reflexionar sobre muchas de las tareas que realizamos al crear un programa. Además, a menudo ocurre que unos problemas se formulan de forma muy clara si se los analiza según una perspectiva determinada, mientras que producen una gran complejidad vistos de otra manera.

Algunos paradigmas habituales

Algunas de las formas de pensar los problemas que ha llegado a sistematizarse como paradigmas de programación son:

• La programación modular: Los programas se forman por partes separadas llamadas módulos. Estos funcionan de forma independiente entre sí, o se relacionan a través de interfaces bien definidas.
• La programación procedural: Un programa se compone de procedimientos (subrutinas, métodos o funciones) que son fragmentos de código que pueden llamarse desde cualquier punto de la ejecución de un programa, incluídos otros procedimientos o él mismo. (ej. ALGOL)
• La programación estructurada: Se puede expresar cualquier programa utilizando únicamente tres estructuras de control: secuencial, condicional e iterativa. Los programas se componen de partes menores con un único punto de entrada, y se trata de aislarlos para evitar la complejidad que introducen los efectos colaterales. (ej. Pascal, C, Ada)
• La programación imperativa: Un programa se puede definir en términos de estado, y de instrucciones secuenciales que modifican dicho estado. (ej. C, BASIC)
• La programación declarativa: Es posible expresar un programa a través de condiciones, proposiciones o restricciones, a partir de los que se obtiene la solución mediante reglas internas de control. (ej. PROLOG)
• La programación funcional: Se puede expresar un programa como una secuencia de aplicación de funciones. Elude el concepto de estado del cómputo y no precisa de las estructuras de control de la programación estructurada. (ej. LISP, Haskell)
• La programación orientada a objetos: Los programas se definen en términos de “clases de objetos” que se comunican entre sí mediante el envío de mensajes. Es una evolución de los paradigmas de la programación procedural, estructurada y modular, y se implementa en lenguajes como Java, Smalltalk, Python o C++.

Programación multiparadigma

Los paradigmas de programación son idealizaciones, y, como tales, no siempre se presentan de forma totalmente ‘pura’, ni siempre resultan incompatibles entre sí. Cuando se entremezclan diversos paradigmas se produce lo que se conoce como programación multiparadigma.

El uso de distintos modelos, según se adapten mejor a las diversas partes de un problema o a nuestra forma de pensamiento, resulta también más natural y permite expresar de forma más clara y concisa nuestras ideas.

Algunos lenguajes, como Haskell o Prolog están diseñados para encajar perfectamente en la visión de un paradigma particular, mientras que otros, como python, se adaptan especialmente bien a la programación multiparadigma y dan gran libertad a la hora de resolver un problema, al no imponen un mismo patrón para todos los casos.

Tipos de datos

Una forma de almacenar y representar una fecha en un programa podría ser la siguiente:

d = 14
m = "Noviembre"
a = 2006
def dime_fecha(dia, mes, anho):
    return "%i de %s de %i del calendario gregoriano" % (dia, mes, anho)
print dime_fecha(d, m, a)

para obtener la siguiente salida:

"14 de Noviembre de 2006"

En este ejemplo, para representar y manipular lo que conceptualmente entendemos como una fecha, se utilizan las variables d, m y a como almacenes de datos, y un procedimiento o función, de nombre dime_fecha, para realizar la representación de la fecha almacenada.

Las variables permiten almacenar tipos de datos concretos como los enteros (d y a) o las cadenas de texto (m), y la función realiza su trabajo devolviendo otro tipo concreto, una cadena de texto.

Uno de los problemas de este enfoque es que no refleja demasiado bien el concepto fecha que usamos como modelo mental al implementarlo como un conjunto de tres variables no relacionadas entre sí (d, m y a). Es decir, las tres variables tienen una unidad conceptual en nuestra mente, que no se refleja en la forma de expresar el problema. De la misma manera, la función dime_fecha desconoce igualmente la relación entre sus parámetros, que podría ser totalmente arbitraria.

Esta situación, que puede parecer una cuestión de ‘estilo’, implica un riesgo de problemas de sincronización entre variables ‘relacionadas’, dispersión en distintas partes del código de manipulaciones que son relevantes al conjunto, pérdida del valor semántico de cada variable que puede dar lugar a errores al transformar el código…

Un ejemplo de desconexión semántica entre la implementación y el concepto es que d puede ser cualquier valor entero, mientras que un día tiene un valor situado entre 1 y 31, m es una cadena de texto dentro de un número limitado de opciones, o a no puede tomar valores negativos. Por supuesto que esto se podría solucionar con código que hiciese comprobaciones adicionales, pero en este caso queremos resaltar cómo un programa es un modelo aproximado a un problema y cómo sería preferible que la implementación pudiese representar de forma más ajustada el comportamiento del modelo elegido.

Una posible solución sería disponer de un tipo de datos que represente de forma más adecuada el concepto de fecha y que nos permita manipular fechas de la misma manera que manipulamos números enteros, números reales o cadenas de texto, independientemente de la implementación interna que los sustente.

Clases y objetos

Al enunciar algunos tipos de paradigmas hemos visto que la programación orientada a objetos define los programas en términos de “clases de objetos” que se comunican entre sí mediante el envío de mensajes. En este apartado aclararemos qué se entiende en ese contexto por clases y objetos.

Las clases surgen de la generalización de los tipos de datos y permiten una representación más directa de los conceptos necesarios para la modelización de un problema permitiendo definir nuevos tipos al usuario.

Las clases permiten agrupar en un nuevo tipo los datos y las funcionalidades asociadas a dichos datos, favoreciendo la separación entre los detalles de la implementación de las propiedades esenciales para su uso. A esta cualidad, de no mostrar más que la información relevante, ocultando el estado y los métodos internos de la clase, es conocida como “encapsulación”, y es un principio heredado de la programación modular.

Un aspecto importante en el uso de clases es que no se manipulan directamente (salvo en lo que se conoce como metaprogramación), sino que sirven para la definición nuevos tipos. Una clase define propiedades y comportamiento que se muestran en los entes llamados objetos (o instancias de una clase). La clase actúa como molde de un conjunto de objetos, de los que se dice que pertenecen a la clase.

Trasladando estos conceptos a los números enteros (tipo int), se puede decir que las variables que almacenan números enteros son objetos o instancias de la clase int o que pertenecen a la clase int.

En términos más abstractos, podemos pensar en las clases como definiciones y en los objetos como expresiones concretas de dichas definiciones.

Fisonomía de una clase

En python, el esquema para la definición de una clase es el siguiente:

class NombreClase:
  <instrucción_1>
  ...
  <instrucción_n>

en donde class es una palabra reservada que indica la declaración de una clase, NombreClase una etiqueta que da nombre a la clase y, los dos puntos, que señalan el inicio del bloque de instrucciones de la clase.

El cuerpo de instrucciones de la clase puede contener tanto asignaciones de datos como definiciones de funciones. Este bloque de instrucciones se encuentra en el nuevo espacio de nombres con el nombre de la clase, que se genera, a su vez, con la creación de cada objeto. En ambos casos, en el espacio de nombres de la clase y del objeto, es posible acceder a los elementos que lo integran usando el operador punto, como en el caso de los espacios de nombres de un módulo (e.j. math.pi, objeto.dato, objeto.funcion()).

Si la primera instrucción del cuerpo de la clase es una cadena de texto, ésta se usa como cadena de documentación de la clase.

Nuestro ejemplo podría reescribirse en términos de una clase así:

class Fecha:
    "Ejemplo de clase para representar fechas"
    dia = 14
    mes = "Noviembre"
    anho = 2006
    def dime_fecha(self):
        return "%i de %s de %i" % (Fecha.dia, Fecha.mes, Fecha.anho)

mi_fecha = Fecha()
print mi_fecha.dia, mi_fecha.mes, mi_fecha.anho
print mi_fecha.dime_fecha()

En el fragmento de código anterior definimos la clase Fecha y ella asignamos valores a las etiquetas dia, mes y anho (atributos de la clase), y definimos una función (un método de la clase), dime_fecha.

Fuera de la definición de la clase creamos (instanciamos) un objeto perteneciente a la clase Fecha. Esta instanciación se realiza utilizando la notación de llamada a función, y podemos entenderla como una llamada a una función que devuelve un objeto de la clase Fecha. El objeto obtenido es asignado a la etiqueta mi_fecha.

En la siguientes instrucciones mostramos por pantalla los valores de las propiedades dia, mes y anho y el resultado de la llamada al método dime_fecha, usando el operador punto para acceder a las propiedades y métodos del objeto mi_fecha, ya que, como hemos mencionado antes, forman parte del espacio de nombres del objeto.

La llamada al método dime_fecha no incluye ningún parámetro, pero podemos comprobar que, de forma contradictoria, la declaración del método indica uno, self. Este parámetro es añadido automáticamente por el intérprete en las llamadas a los métodos de una clase, y contiene una referencia al objeto que recibe la señal (el que recibe una llamada a un método). self permite acceder a las propiedades y métodos de un objeto concreto y aclararemos su significado y uso más adelante. Por ahora nos basta saber que es necesario incluir self como primer parámetro de los métodos definidos en una clase y que no es preciso incluir el parámetro implícito self al realizar llamadas a un método a través del objeto al que pertenece.

En realidad, en el ejemplo anterior, la llamada mi_fecha.dime_fecha() es una forma más cómoda de escribir (azúcar sintáctico) Fecha.dime_fecha(mi_fecha), lo que explica la presencia del parámetro.

Un paseo entre objetos

Hasta el momento hemos visto cómo las clases definen los datos (o estado) y comportamiento de los objetos a través de atributos (o propiedades) y métodos.

Ahora vamos a hacer un recorrido, utilizando una sesión interactiva del intérprete y las capacidades de introspección de python, para explicar el uso y el comportamiento de los objetos.

Veremos algunas características de los objetos:

1. Identidad. Los objetos se diferencian entre sí, de forma que dos objetos, creados a partir de la misma clase y con los mismos parámetros de inicialización, son entes distintos.
2. Definen su comportamiento (y operar sobre sus datos) a través de métodos, equivalentes a funciones.
3. Definen o reflejan su estado (datos) a través de propiedades o atributos, que pueden ser tipos concretos u otros objetos.

Pasamos a ver una sesión interactiva del intérprete:


>>> mi_fecha = Fecha()
>>> mi_fecha_2 = Fecha()
>>> mi_fecha is mi_fecha_2
False
>>> print mi_fecha
<__main __.Fecha instance at 0x00B184B8>
>>> print mi_fecha_2
<__main __.Fecha instance at 0x00B18328>


Vemos que tanto mi_fecha como mi_fecha_2 son instancias de la clase Fecha (en el módulo __main__) y cada una tiene su propio espacio de memoria independiente.


>>> print mi_fecha.dime_fecha()
14 de Noviembre de 2006
>>> print mi_fecha.dia
14
>>> print mi_fecha_2.dia
14
>>> Fecha.dia = 16
>>> print Fecha.dia
16
>>> print mi_fecha.dia
16
>>> print mi_fecha_2.dia
16
>>> mi_fecha.dia = 30
>>> print Fecha.dia
16
>>> print mi_fecha.dia
30
>>> print mi_fecha_2.dia
16


Este último experimento observamos cómo, pese a que mi_fecha y mi_fecha_2 son dos instancias distintas de la clase Fecha, ambas hacen referencia a través de su atributo dia al mismo valor de la clase Fecha.dia. Sin embargo, cuando se produce una asignación a ese atributo (a esa etiqueta, en realidad) en uno de los objetos vemos cómo, a partir de entonces, ese objeto dispone de un valor 'individual' asociado al atributo.

Ese comportamiento revela la existencia de atributos (o estado) compartidos por todas las instancias de una clase y de atributos (o estado) ligados a una instancia particular. Los primeros se sitúan en el espacio de nombres de la clase, y vemos cómo se pueden hacer asignaciones en la sesión interactiva anterior, o lecturas, en el método dime_fecha del ejemplo anterior. Los segundos se sitúan en el espacio de nombres de cada objeto, y ahí es donde resulta útil el parámetro self.

Antes de proseguir, podemos escudriñar qué símbolos son accesibles y qué contienen los espacios de nombres de la clase Fecha y de los objetos mi_fecha y mi_fecha_2. Usamos la función dir para lo primero, y el atributo __dict__ para lo segundo, ya que en python los espacios de nombres se implementan como diccionarios:


>>> dir(Fecha)
['__doc__', '__module__', 'anho', 'dia', 'dime_fecha', 'mes']
>>> dir(fecha3)
['__doc__', '__module__', 'anho', 'dia', 'dime_fecha', 'mes']
>>> dir(fecha4)
['__doc__', '__module__', 'anho', 'dia', 'dime_fecha', 'mes']


En los tres podemos acceder a los mismos símbolos. Sin embargo...


>>> Fecha.__dict__
{'__module__': '__main__', 'anho': 2006, 'dime_fecha': x00B176F0>, 'dia': 14, 'mes': 'Noviembre', '__doc__': 'Ejemplo de clase para representar fechas'}
>>> mi_fecha_2.__dict__
{}
>>> mi_fecha.__dict__
{'dia': 30}


El espacio de nombres de la clase es el que alberga los nombres de los atributos y métodos indicados en la declaración de la clase, además de los atributos especiales __doc__, que contiene la cadena de documentación y __module__, que contiene el nombre del módulo al que pertenece la clase. Esos símbolos son accesibles también para los objetos pertenecientes a la clase (tal como nos indicaba dir()).

Podemos ver también que el espacio de nombres del objeto mi_fecha_2 se encuentra vacío, mientras que el del objeto mi_fecha contiene el atributo día. Esto se debe a que anteriormente realizamos una asignación al atributo dia del objeto mi_fecha (dándole el valor 30). El espacio de nombres recoge esa versión particular del atributo, que no aparece en el otro objeto, puesto que accede al atributo de clase.

A los atributos compartidos por todos los objetos de una clase se los denomina atributos de clase, cuando se desea diferenciarlos de los atributos que pertenecen a cada instancia en particular.

Acceso individualizado a objetos: self

Ahora que hemos visto cómo usar atributos de clase para compartir datos entre todos los objetos de una misma clase, también nos interesa conocer cómo utilizar atributos comunes a una clase pero que puedan tomar valores distintos para cada uno de los objetos.

Retomamos ahora el misterioso parámetro self que vimos estaba presente como primer parámetro de todos los métodos de una clase. En su momento ya comentamos que self contiene una referencia al objeto que recibe la señal (el objeto cuyo método es llamado), por lo que podemos usar esa referencia para acceder al espacio de nombres del objeto, es decir, a sus atributos individuales.

>>> class F:
...     i = 5
...     def dime_i(self):
...             return F.i
...     def dime_mi_i(self):
...             return self.i
...
>>> a = F()
>>> a.dime_i()
5
>>> a.dime_mi_i()
5
>>> a.i = 6
>>> a.dime_i()
5
>>> a.dime_mi_i()
6
>>> a.i
6

En este ejemplo el método dime_i usa el atributo de clase y retorna su valor, 5, mientras que el método dime_mi_i usa una referencia al objeto y devuelve el valor 6, el asignado al atributo del objeto a. Así accedemos selectivamente al atributo de clase i o al atributo de instancia i.

Algo que puede aclarar algo más la naturaleza del parámetro self, es recordar que, cuando hacemos una llamada a un método un_metodo de un objeto un_objeto perteneciente a la clase UnaClase, el intérprete traduce la expresión un_objeto.un_metodo() como UnaClase.un_metodo(un_objeto).

El uso de self responde a la forma particular en que python implementa el soporte de objetos, aunque lenguajes como Java o C++ utilizan mecanismos similares con la palabra reservada this. En python self no es una palabra reservada y cualquier etiqueta usada como primer parámetro valdría igualmente, aunque se desaconseja totalmente el uso de otras etiquetas, por tratarse de una convención muy arraigada en el lenguaje que hace el código más legible, facilita el resaltado de sintaxis, etc.

El método de inicialización __init__

Hemos visto ya cómo definir y usar atributos de clase y de instancia. Pero en python no es necesaria la declaración de variables, por lo que cualquier atributo al que se realice una asignación en el código se convierte en un atributo de instancia:


>>> a = F()
>>> a.i = 6
>>> a.atr = 3
>>> print a.atr
3
>>> a.__dict__
{'i': 6, 'atr': 3}


Una funcionalidad muy conveniente que hemos visto en la declaración de atributos de clase es la de realizar su inicialización en el cuerpo de la clase. Para poder inicializar los atributos de una instancia existe un método especial que permite actuar sobre la inicialización del objeto. Dicho método se denomina __init__ (con dos guiones bajos al principio y al final) y admite cualquier número de parámetros, siendo el primero la referencia al objeto que es incializado (self, por convención), que nos permite realizar las asignaciones a atributos de la instancia. Este método se ejecuta siempre que se crea un nuevo objeto de la clase, tras la asignación de memoria y con los atributos de clase inicializados, y se corresponde parcialmente con el concepto de constructor de la clase existente en otros lenguajes.

Con la referencia que nos proporciona self podemos inicializar atributos de instancia, con valores predeterminados si lo deseamos, como en cualquier definición de función:

class Clase:
    def __init__(self, x=2):
        self.x = x
        self.a = x**2
        self.b = x**3
        self.c = 999
    def dime_datos(self):
        return "Con x=%i obtenemos: a=%i, b=%i, c=%i" % (self.x, self.a, self.b, self.c)
a1 = Clase(2)
a1.dime_datos()
a2 = Clase(3)
a2.dime_datos()

Salida:


Con x=2 obtenemos: a=4, b=8, c=999
Con x=3 obtenemos: a=9, b=27, c=999


Propiedades y Atributos

Aunque en la terminología general de la programación orientada a objetos atributo y propiedad se pueden utilizar como sinómimos, en python se particulariza el uso de propiedades para un tipo especial de atributos cuyo acceso se produce a través de llamadas a funciones.

class ClaseC(object):
    def __init__(self):
        self.__b = 0
    def __get_b(self):
        return self.__b
    def __set_b(self, valor):
        if valor > 10:
            self.__b = 0
        else:
            self.__b = valor
    b = property(__get_b, __set_b, 'Propiedad b')

c1 = ClaseC()
print c1.b
# b es 0
c1.b = 5
print c1.b
# b es 5
c2 = ClaseC()
print c2.b
# b es 0
c2.b = 12
print c2.b
#b es 0

En este ejemplo se define la propiedad b, cuyo comportamiento es: cuando se realiza una asignación, toma el valor entregado si es menor que 10, o 0 en caso contrario, y lo almacena en un atributo privado __b. Cuando se produce la lectura de b, devuelve el valor guardado en el atributo privado.

En Python, para poder usar propiedades en una clase es necesario hacerla derivar de la clase object de ahí que aparezca al lado del nombre de la clase ClaseC. En un apartado posterior se explicará en qué consiste la derivación de clases.

La signatura de la función property, que define una propiedad de la clase es la siguiente:
nombre_propiedad = property(get_f, set_f, del_f, doc)
donde get_f es la función llamada cuando se produce la lectura del atributo; set_f la función llamada cuando se produce una asignación al atributo; del_f la función llamada cuando se elimina el atributo, y doc es una cadena de documentación de la propiedad.

Las propiedades resultan muy útiles para realizar la validación de los valores asignados, la transformación o cálculo de valores devueltos y, además, dotan de gran flexibilidad a la hora de escribir el código, puesto que es posible empezar usando atributos y luego sustituirlo por una propiedad que realice funciones adicionales, a medida que el código lo requiera y simplemente cambiando el código de la clase, sin afectar al código cliente de la clase.

Herencia y derivación de clases

Vemos que el uso de clases hace más adecuada la representación de conceptos en nuestros programas. Además, es posible generar una clase nueva a partir de otra, de la que recibe su comportamiento y estado (métodos y atributos), adaptándolos o ampliándolos según sea necesario.

De una clase que representase el concepto de vehículo podríamos derivar otras para representar automóviles, bicicletas, barcos o aviones, donde cada uno de ellos mantiene atributos y métodos comunes (peso, color, velocidad máxima, número de pasajeros), mientras que otros son exclusivos (número de ruedas, número de hélices, número de reactores, altitud máxima de vuelo...).

En términos matemáticos podemos expresarlo diciendo que es posible establecer relaciones de pertenencia entre clases. Si tenemos una clase A y de ella derivamos una clase B, podemos decir que "B es una A", o que "B es una especialización de A".

En la terminología de la POO se dice que "B hereda de A", "B es una clase derivada de A", "A es la clase base de B", "A es superclase de B" o "A es clase madre de B".

Esto facilita la reutilización del código, puesto que se pueden implementar los comportamientos y datos básicos en una clase base y especializarlos en las clases derivadas.

En un programa hipotético que trabajase con formas geométricas, podríamos tener una clase base Forma y clases derivadas de ella como Triangulo, Cuadrado, Circulo... En la clase base podríamos definir un método dibuja que representa la figura en pantalla, y un método area y otro perímetro que calculan el área y el perímetro, respectivamente.

En el lenguaje python, para expresar que una clase deriva, desciende o es heredera de otra u otras clases se añade tras el nombre, en la declaración de la clase, una tupla con los nombres de las clases base.

El siguiente ejemplo crea una ClaseA y de ella deriva una ClaseB que inicializa un atributo adicional, cambia el comportamiento de un método y hereda los atributos de la clase madre:

class ClaseA:
    def __init__(self, x):
        self.a = x
        self.b = 2 * x
    def muestra(self):
        print "a=%i, b=%i" % (self.a, self.b)

class ClaseB(ClaseA):
    def __init__(self, x, y):
        ClaseA.__init__(self, x)
        self.c = 3 * (x + y) + self.b
    def muestra(self):
        print "a=%i, b=%i, c=%i" % (self.a, self.b, self.c)

print "Objeto A"
a = ClaseA(2)
print a.__dict__
a.muestra()

print "ObjetoB"
b = ClaseB(2, 3)
print b.__dict__
b.muestra()

Este código al ejecutarse devuelve:


Objeto A
{'a': 2, 'b': 4}
a=2, b=4
ObjetoB
{'a': 2, 'c': 19, 'b': 4}
a=2, b=4, c=19


La clase ClaseA muestra funcionalidades que ya hemos ido viendo en esta introducción (atributos de instancia a y b, método muestra). La clase ClaseB se declara como descendiente de la ClaseA, por lo que hereda sus métodos y atributos y modifica algo el comportamiento de la clase madre. Por una parte, en su método de inicialización llama al método de la clase madre con los parámetros deseados, y, posteriomente, añade un nuevo atributo de instancia que no existe en la clase madre. Por otro lado, redefine un método existente en ClaseA, cambiando la implementación.

Esta última técnica, en la que un mismo nombre se asocia a comportamientos distintos se conoce como polimorfismo, y se habla de que el método se ha sobrecargado, es decir, se le asignan distintos significados en función de su contexto. El polimorfismo también alude a la posibilidad de utilizar, en un contexto en el que se espera una clase dada, cualquier clase derivada.

La clase object

Desde la versión 2.2 de python, se ha establecido una clase base llamada object de la que se aconseja derivar todas las clases. Esto permite aprovechar una serie de características sólo existentes en las "nuevas clases" (como la definición de propiedades), que se describen en la documentación de python.

En el ejemplo sobre el uso de propiedades se introdujo la herencia sin explicarla, derivando la clase de object. Ahora debería estar más clara la razón .

Jerarquías de clases

La herencia permite establecer relaciones entre clases, y, estas relaciones de pertenencia pueden ser a varios niveles, y ramificarse en lo que se denominan jerarquías de clases.

Un ejemplo de clásico para visualizar las jerarquías de clases es el que podría servir para modelizar el conjunto de empleados de una empresa. En ella aparece una clase base Empleado, que dispone de los atributos nombre y departamento; de ella descienden las subclases Gestor (atributo adicional informes) y Trabajador (atributo adicional proyectos), y de esta última derivan las clases Comercial (atributo adicional participación) e Ingeniero (atributo original area).

Gráficamente podría representarse de la siguiente manera:

En el diagrama se puede ver en negrita los atributos que implementa cada clase, y en gris los que hereda de clases madre. El código (básico de inicialización) de las clases podría ser el siguiente:

class Empleado:
    def __init__(self, nombre, departamento="general"):
        self.nombre = nombre
        self.departamento = departamento

class Gestor(Empleado):
    def __init__(self, nombre):
        Empleado.__init__(self, nombre)
        self.informes = []

class Trabajador(Empleado):
    def __init__(self, nombre):
        Empleado.__init__(self, nombre)
        self.proyectos = []

class Comercial(Trabajador):
    def __init__(self, nombre, participacion=0.1):
        Trabajador.__init__(self, nombre)
        self.departamento = "ventas"
        self.participacion = participacion

class Ingeniero(Trabajador):
    def __init__(self, nombre, area="mecánica"):
        Trabajador.__init__(self, nombre)
        self.departamento = "ingeniería"
        self.area = area

Naturalmente, cada una de las clases tendría sus propios métodos que definirían comportamientos propios de cada clase o subclase, que no se han detallado en el ejemplo.

Una alternativa a la herencia es la composición, en el que una clase se compone de otras clases internas, y que puede ser una mejor alternativa en muchos casos.

Encapsulación y grados de privacidad

Uno de los principios que guían la POO, heredados de la programación modular, es el de encapsulación. Hemos visto cómo se puede agrupar comportamiento y datos gracias al uso de objetos, pero hasta el momento, tanto los atributos como los métodos que se definen en las clases correspondientes se convierten en métodos y atributos visibles para los usuarios de la clase (la API de la clase).

Se dice que un método o atributo es público si es accesible desde el exterior de la clase, mientras que se denomina privado en caso contrario.

Es deseable poder señalar qué métodos y atributos no deben utilizarse fuera de la clase para evitar exponer excesivamente los detalles de la implementación de una clase o un objeto.

Python utiliza para ello convenciones a la hora de nombrar métodos y atributos, de forma que se señale su carácter privado, para su exclusión del espacio de nombres, o para indicar una función especial, normalmente asociada a funcionalidades estándar del lenguaje.

_nombre

Los nombres que comienzan con un único guión bajo indican de forma débil un uso interno. Además, estos nombres no se incorporan en el espacio de nombres de un módulo al importarlo con "from ... import *".

__nombre

Los nombres que empiezan por dos guiones bajos indican su uso privado en la clase.

Por ejemplo, en la definición de clase siguiente:

class ClaseA:
    def __init__(self, a)
        self.__a = a
        self.x = self.__a**2 + 2
        self.y = self.__a**3 + 3

el atributo __a es de uso interno de la clase y no se exporta directamente. A continuación podemos ver cómo trata los atributos 'privados' python:


>>> a = ClaseA(2)
>>> dir(a)
['_ClaseA__a', '__doc__', '__init__', '__module__', 'x', 'y']
>>> a.__dict__
{'x':6, 'y':11, '_ClaseA__a':2}


Todavía es posible acceder a __a, pero el nombre es transformado a '_ClaseA__a', que lo señala como un atributo de uso privado.

__nombre__

Los nombres que empiezan y acaban con dos guiones bajos indican atributos "mágicos", de uso especial y que residen en espacios de nombres que puede manipular el usuario. Solamente deben usarse en la manera que se describe en la documentación de python y debe evitarse la creación de nuevos atributos de este tipo.

Algunos ejemplos de nombres "singulares" de este tipo son:
__init__, método de inicialización de objetos
__del__, método de destrucción de objetos
__doc__, cadena de documentación de módulos, clases...
__class__, nombre de la clase
__str__, método que devuelve una descripción de la clase como cadena de texto
__repr__, método que devuelve una representación de la clase como cadena de texto
__module__, módulo al que pertenece la clase
Se puede consultar la lista de atributos de este tipo y su descripción detallada en la documentación de python.

Resúmen final

La programación orientada a objetos enuncia la posibilidad de escribir un programa como un conjunto de clases de objetos capaces de almacenar su estado, y que interactúan entre sí a través del envío de mensajes.

Las técnicas más importantes utilizadas en la programación orientada a objetos son:

• Abstracción: Los objetos pueden realizar tareas, interactuar con otros objetos, o modificar e informar sobre su estado sin necesidad de comunicar cómo se realizan dichas acciones.
• Encapsulación (u ocultación de la información): los objetos impiden la modificación de su estado interno o la llamada a métodos internos por parte de otros objetos, y solamente se relacionan a través de una interfaz clara que define cómo se relacionan con otros objetos.
• Polimorfismo: comportamientos distintos pueden estar asociados al mismo nombre
• Herencia: los objetos se relacionan con otros estableciendo jerarquías, y es posible que unos objetos hereden las propiedades y métodos de otros objetos, extendiendo su comportamiento y/o especializándolo. Los objetos se agrupan así en clases que forman jerarquías.

Las clases definen el comportamiento y estado disponible que se concreta en los objetos.

Los objetos se caracterizan por:

• Tener identidad. Se diferencian entre sí.
• Definir su comportamiento a través de métodos.
• Definir o reflejar su estado a través de propiedades y atributos.

Gracias a la amable aportación de Óscar Carballal ahora es posible descargar una versión en PDF del artículo

El 24 de octubre, Alfredo Rodríguez Viescas, ‘Fredo’, envió la implementación inicial a la lista de correo de Pascaline y anteayer subí una versión corregida al repositorio del proyecto.

El programa phundimiento permite el cálculo de la presión de hundimiento de zapatas rectangulares tanto en condiciones drenadas como no drenadas, y para todos los casos que contempla la formulación del código técnico en su DB-SE-C, salvo el caso de zapatas circulares , y los casos en los que las cargas están inclinadas respecto a la vertical, o cuando se ha de tener en cuenta la presencia de taludes próximos.

En la versión del repositorio se ha desacoplado la interfaz de texto de las funciones que podrían formar parte de una librería de cálculos geotécnicos; se han renombrado las variables y funciones procurando que el código se autodocumente y no precise de aclaraciones en línea; se ha unificado el estilo siguiendo el PEP-8; se ha unificado la API; se ha tratado de que cada función realice tareas específicas y reciba únicamente los parámetros necesarios para ello; también se han separado las funciones que podrían llegar a ser útiles en una librería…

Los casos pendientes de resolución en la versión actual no presentan gran complejidad, puesto que se trata de incorporar un par de coeficientes adicionales o de señalizar el tipo de geometría de la zapata, pero todavía es necesario pensar cómo queremos modelar la API de programa.

Todavía es preciso abstraer más la interfaz de las funciones generales, para evitar la profusión de parámetros que únicamente responden a la casuística del problema. Seguramente, nos ayudará en esta tarea la generalización de las acciones y del terreno en clases que encapsulen la variedad existente, y permitan que las funciones principales tengan una API más uniforme. Es preferible que la lógica de selección del caso apropiado se encuentre en el propio código, por ejemplo usando el patrón estrategia, y no recaiga en la selección previa de la función adecuada por parte del usuario/a.

Idealmente, se trataría de pasar una zapata, un terreno y unas acciones, y de obtener de ellos la presión de hundimiento… así que no deberíamos exigir mucho más que eso…

Personalmente, ya contaba con una bajísima participación, puesto que es la norma en los proyectos en los que participo, pero a raíz de la lectura de algunas reflexiones al respecto, he pensado que estaría bien exponer aquí algunas de las informaciones que he ido encontrando en la red.

En un artículo de la serie AlertBox, Jakob Nielsen trata la participación en proyectos online y cómo es posible facilitar la colaboración en ellos.

Las conclusiones principales de ambos artículos son:

• La participación en los proyectos se estratifica de forma muy desigual:
  • El 90% de la gente son mirones. Siguen el proyecto pero no participan.
  • El 9% de la gente hacen aportaciones ocasionales.
  • El 1% de la gente es la que hace el grueso de aportaciones.
• Los problemas potenciales de la participación desigual son:
  • Falta de realimentación por parte de los usuarios.
  • Falta de representatividad de las aportaciones respecto a los intereses de la población general.
  • Tendencia de las posiciones extremas a adquirir mayor visibilidad.
  • El exceso de ruido respecto al contenido interesante, puede desmotivar la participación de las personas con menos disponibilidad de tiempo.
  • El contenido indexado responde a los intereses de las personas que participan y no al de la mayoría.
• Es necesario asumir este comportamiento desigual, pero es posible propiciar una mayor y mejor participación:
  • Haciendo que sea muy sencillo participar.
  • Convirtiendo la participación en un efecto secundario, de manera que participar exija esfuerzo nulo.
  • Favorece la edición sobre la creación. Es más sencilla la participación modificando o mejorando algo ya existente que creando desde cero.
  • Premiando a la gente que participa, pero no en exceso.
  • Promoviendo a la gente que hace aportaciones de calidad, por ejemplo, favoreciendo su reputación en el proyecto.
• Algunas recomendaciones para crear una comunidad son:
  • Blog, blog, blog (comunicación en la red)
  • Enviar mensajes relacionados con el tema del proyecto a la lista de correo.
  • Escribir mucha documentación y facilitar que la gente se una al proyecto.
  • Crear un repositorio de código
  • Conseguir ayuda de los primeros usuarios, implicándolos en el proyecto.
• Y recomendaciones parar sostener una comunidad:
  • Blog, blog, blog (comunicación en la red)
  • Enviar mensajes a gente que puede tener interés en participar.
  • Reconocer las aportaciones.
  • Responder con rapidez a las cuestiones de la lista de correo.
  • Mostrar la utilidad del proyecto, a los participantes y a las organizaciones que se puedan implicar.
  • Promocionar el proyecto incansablemente.

En resúmen… gran parte del esfuerzo para lograr una participación efectiva parece estar en una estrategia de comunicación efectiva.
Otro artículo que leí hace unos meses da otras claves interesantes y más concretas sobre cómo gestionar un proyecto de software libre, incluído cómo, cuándo y con qué hacer un lanzamiento de una nueva versión de un programa, la forma y el momento de publicitarlo, cómo establecer objetivos…

Introducción

En los proyectos de software, es común la continua realización de cambios al código y la documentación para hacer mejoras o corregir fallos. El uso de parches es un método muy eficaz para transmitir y mostrar dichos cambios, y en este curso se explica cómo trabajar con ellos.

NOTA:
En las rutas de archivos y en la línea de comandos se utiliza la convención Unix, con “$” como símbolo de la línea de comandos y “/” como separador de directorios dentro de una ruta, que equivalen al símbolo “>” y “\” de Windows. (p.e. “$ dir” -> “> dir” y “programa/a.txt” -> “programa\a.txt”)

Qué es un parche y para qué sirve

Un parche es un archivo que recoge los cambios necesarios para pasar de un archivo “original” y un archivo “modificado”.

Por ejemplo:

original/a.txt (original):
linea 0
linea A
linea B

modificaciones/b.txt (modificado):
linea 0
linea B
linea C
linea D

el parche que recoge los cambios que convierten a.txt en b.txt es:

--- original/a.txt 2006-08-10 13:51:46.000000000 +0200
+++ modificaciones/b.txt 2006-08-10 13:51:55.000000000 +0200
@@ -1,3 +1,4 @@
linea 0
-linea A
linea B
+linea C
+linea D

Más adelante explicaremos qué significa cada una de las partes de este parche.

Con un poco de práctica, el uso de parches hace más sencillo el intercambio y la revisión de modificaciones, además de dar una idea más acertada que la simple inspección visual de la magnitud de los cambios que se producen entre las diferentes versiones de un archivo.

También facilita la separación de los cambios en conjuntos coherentes y “ortogonales”. Un parche puede corregir una errata, otro añadir una nueva funcionalidad, otro arreglar un fallo concreto, etc… de forma que se puede decidir aplicarlos todos (uno tras otro), aplicar solamente alguno de ellos, descartar alguno por incorrecto, etc. La utilización de parches “pequeños” que actúen sobre problemas específicos es una buena práctica que dificulta la introducción de errores de forma inadvertida.

Herramientas para generar y aplicar parches

Algunas herramientas, como ‘diff’ y ‘patch’, permiten generar y aplicar parches de forma automática, de manera que se evita el tedio de localizar manualmente los cambios y trasladarlos de una versión a otra.

La instalación de ‘diff’ y ‘patch’ es trivial en cualquier sistema GNU/Linux con las herramientas habituales (apt, rpm, synaptics…). Los paquetes relevantes son ‘diffutils’ y ‘patch’, aunque es probable que ya se encuentren instalados por defecto.

En Windows se pueden descargar binarios [1][2] compilados para esa plataforma, que se usan desde la línea de comandos. Es conveniente incluir la ruta de estos programas en la ruta por defecto del sistema (variable PATH) para evitar tener que escribir continuamente la ruta completa cada vez que se usan.

El proyecto Mingw [3] incluye muchas de estas aplicaciones empaquetadas conjuntamente con otras del entrono de desarrollo de GNU/Linux.

[1] http://gnuwin32.sourceforge.net/packages/patch.htm
[2] http://gnuwin32.sourceforge.net/packages/diffutils.htm
[3] http://www.mingw.org/

Ahora que hemos visto cómo instalar en nuestro sistema las herramientas necesarias, veremos cómo utilizarlas y para qué sirven.

diff

La aplicación ‘diff’ muestra las diferencias entre el archivo “original” y el “modificado”. Admite opciones que permiten hacer más legible el registro de cambios, por ejemplo, incorporando algo de contexto a los cambios (la opción más habitual es -u (formato unificado), pero depende de las políticas de cada proyecto).

Para generar el parche anterior se ejecutó en la línea de comandos:

$ diff -u a.txt b.txt

que produce la siguiente salida:

--- original/a.txt 2006-08-10 13:51:46.000000000 +0200
+++ modificaciones/b.txt 2006-08-10 13:51:55.000000000 +0200
@@ -1,3 +1,4 @@
linea 0
-linea A
linea B
+linea C
+linea D

Si redirigirmos la salida a un archivo ya tenemos un parche con los cambios (cambios.diff):

$ diff -u original/a.txt modificaciones/b.txt > cambios.diff

Información contenida en un parche

Hemos visto que la herramienta diff incluye algunos datos que no se encontraban en los archivos que compara:

--- original/a.txt 2006-08-10 13:51:46.000000000 +0200
+++ modificaciones/b.txt 2006-08-10 13:51:55.000000000 +0200
@@ -1,3 +1,4 @@
linea 0
-linea A
linea B
+linea C
+linea D

Esa información adicional aporta metadatos sobre los cambios, útiles para conocer el contexto, la procedencia de los datos y la localiza
Las primeras dos líneas de la salida que produce diff indican la ruta relativa (desde donde se hace el parche) y el nombre de los archivos que se comparan, y otros datos como la fecha de modificación, hora…

Ha de advertirse que, para las obtención de diferencias entre archivos, es significativo el órden. No es idéntica la diferencia entre a.txt y b.txt que la diferencia entre b.txt y a.txt.

La tercera línea encabeza un conjunto de cambios e informa acerca del fragmento (en a.txt y b.txt) en el que se han encontrado cambios, y se muestran a continuación en el parche. En nuestro ejemplo se indica que las líneas afectadas son las líneas 1 a 3 del archivo a.txt y las líneas 1 a 4 del archivo b.txt. Pueden aparecer varios de estos fragmentos en un mismo parche, con su encabezado correspondiente.

Dentro de cada uno de estos fragmentos, y a continuación del encabezado, se prefijan con un ‘-’ las líneas eliminadas de a.txt (que no aparecen en b.txt) y se prefijan con un ‘+’ las líneas insertadas en b.txt (que no aparecen en a.txt).

-linea A < — se elimina (-) esta línea
+linea C < — se añade (+) esta línea
+linea D < — se añade (+) esta línea

Las líneas sin prefijo simplemente muestran parte del contexto de los cambios, para facilitar la lectura del parche. Estas líneas no representan cambios en los archivos, sino simplemente partes comunes que rodean las zonas de cambio.

Ya sabemos, pues, cómo se genera y qué significa el contenido de un parche.

Aplicación y reversión de cambios

Una vez guardada en un parche la información de los cambios parar transformar un archivo a.txt en otro b.txt, ¿qué hacemos con esa información?.

Puesto que en el parche se dispone de la información necesaria, es posible generar b.txt a partir de a.txt y el parche. Para ello se usa otra herramienta llamada ‘patch’ (es la que ha dado nombre a los parches=patches).

patch

La aplicación ‘patch’ aplica un conjunto de cambios generado por diff a un archivo para obtener el archivo modificado.

Simplemente se le debe enviar por la entrada estándar el archivo que contiene los cambios (el parche).

En nuestro ejemplo:

$ patch < cambios.diff

Con esta simple acción patch localiza a.txt (tiene en la cabecera la ruta) y aplica los cambios, dejando el archivo como b.txt. Hay que aclarar que el archivo a.txt no se renombra, sino que simplemente contiene lo mismo que contenía b.txt.

Hay que tener en cuenta que se debe aplicar el parche en el mismo nivel de directorio que se usó para generar el parche (es posible modificar esto con la opción -p, pero es más sencillo así). Normalmente se usa el directorio raíz del proyecto para generar y aplicar los parches y así no tener que consultar la posición del archivo y la ruta del parche.

Otra operación útil es la reversión de los cambios que produce un parche (es decir, volver de b.txt a a.txt deshaciendo los cambios indicados en el parche). Para ello simplemente se usa la opción -R de ‘patch’.

$ patch -R < cambios.diff

Trabajo con parches

En los proyectos de software libre es habitual la comunicación mediante listas de correo en las que se comenta y revisa el código entre las distintas personas que participan en el proyecto.

Se deben señalar algunas buenas prácticas para colaborar de esa manera:

• El asunto del correo debe corresponder al contenido del mensaje
• Cuando se quiera comentar el contenido de otro correo se debe responder al mismo en el cliente de correo (no crear un correo nuevo con el mismo tema) de forma que se pueda seguir el hilo en los clientes que soporten la visualización de conversaciones.
• El código se comenta en línea (pegando el código) aunque se adjuntan parches para cada uno de las cuestiones tratadas que sean conceptualmente distintas. Así, si se deciden integrar dichos cambios, se puede elegir cuáles son relevantes, cuáles necesitan más trabajo, o dejar algunos sin aplicar.

Otros recursos en la red

http://www.gnu.org/software/diffutils/manual/html_mono/diff.html
http://www.infres.enst.fr/~blanch/howto/DiffPatch.html
http://www.linuxjournal.com/article/1237

Copyright ©, Rafael Villar Burke, agosto 2006
Se permite la distribución, copia y modificación del texto, siempre y cuando se conserve el copyright y esta nota.

Para no abordar todos los frentes de una sola vez, y tras participar en algunos proyectos esporádicamente, comencé a programar una versión libre del “Prontuario informático del Hormigón”, que iría generando a su vez librerías y utilidades para otros proyectos posteriores.

Hasta el momento he avanzado bastante, con una interfaz gráfica hecha con PyGTK, cálculo de las propiedades reológicas y mecánicas del hormigón, propiedades geométricas de las secciones y alguna cosa más que no hace el Prontuario original… Pensaba publicar el resultado en cuanto tuviese algo un poco completo, para ver si se generaba una comunidad a su alrededor (siempre es más fácil esto con una aplicación completa que con un prototipo).

Pantallazos de la interfaz actual del programa tipo “Prontuario”

Algo que me sorprendió es que, en la excelente web dedicada al campo de las estructuras demecanica.com, hacían un llamamiento para crear conjuntamente un software libre, el proyecto Pascaline, para el cálculo, diseño, enseñanza de las estructuras de edificación. En ese momento decidí mandar un mensaje al foro del proyecto y un mail a Ramón Gesto (el hombre detrás del proyecto demecanica.com) para unir esfuerzos…

Pascaline, primera calculadora mecánica de la historia

Ahora voy a dedicar mis esfuerzos al proyecto Pascaline.

Esta puede ser la oportunidad para que unos cuantos nos juntemos e intentemos llevar algo adelante, ya que no se ha visto ningún fruto de este tipo ni desde las universidades u otras instituciones con carácter investigador o docente.

Antes del verano aprovechamos Ramón y yo para reunirnos en La Latina y charlar sobre las expectativas que cada uno depositaba en el proyecto y cómo lo veíamos. Creo que ambos quedamos ilusionados con lo que podía surgir y en este tiempo ya hemos creado una lista de correo a la que se han ido incorporando más personas, aunque hasta el momento solamente Ramón, Coya y yo hemos participado activamente. Esperemos que más gente se anime en breve.Algo que tendremos que ver es dónde alojamos el proyecto para la publicación de versiones, si en mi dominio, en sourceforge, o en el recién estrenado lugar para proyectos de software libre de google. Lo mismo pasa con el sistema de control de versiones, que preferiría que fuese Mercurial, aunque subversion probablemente tiene herramientas más integradas y fáciles de usar para principiantes en Windows, y parece que esa es la plataforma mayoritaria en el equipo.

Por ahora, y puesto que parece que soy el que más experiencia tiene en el campo de la programación, trataré de ir mandando código y documentación para que todo el mundo se vaya poniendo en marcha, aprendiendo a usar el entorno elegido (hasta ahora python) y poder ir elaborando una base sobre la que trabajar. Esta primera parte me temo que será la más complicada, hasta que nos acompasemos y se establezca una rutina.

Inicialmente nos hemos puesto a hacer un módulo de geotecnia y una interfaz en modo texto del mismo.

Ya iré comentando sobre los avances que vayamos haciendo…