Barrapunto

En java y C# hay atributos públicos, otra cosa es que no se suelan usar porque se considera mala práctica; pero están ahí. En Python y PHP no sé, aunque imagino que también.

En todo caso, ¿por qué no usar atributos públicos va en contra del concepto de tipo abstracto de datos? Que yo sepa, los tipos abstractos de datos se definen precisamente mediante sus operaciones, y las restricciones que tengan/produzcan (precondiciones, postcondiciones, etc.). Los atributos están en una capa de abstracción más baja. Así que no sé muy bien lo que quieres decir con eso.

En Python no hay atributos privados

Jeje, tuvimos un debate sobre esto en mi trabajo hace poco. Se sale parcialmente del tema de este artículo, pero bueno.

El caso es que, ¡precisamente! Si un lenguaje ofrece una característica pero luego te dice que no la uses nunca porque es mala, ¿para qué la ofrece?

Además, el no poder usarla obliga a hacer cosas que, para mí, engorrinan siempre el código. Por ejemplo, pongamos la típica clase "punto geométrico" (en pseudo código):

class Punto:
    public x: integer
    public y: integer

Imaginemos que nuestra clase sólo admite puntos dento de las coordenadas de pantalla, por ejemplo. Así escrita, la única forma de asegurar que la clase tiene valores correctos es repasar todo el programa a ver qué mete ahí. Para evitarlo, te suelen recomendar algo como:

class Punto:

    private x: integer
    public get_x(): integer
        return x
    public set_x(nuevo_x: integer)
        (verificar nuevo_x...)
        this.x = nuevo_x

    (y lo mismo con y)

Esto tiene varios problemas:

- Añadimos dos líneas de código inútiles por cada atributo y una función que no hace mas que gastar memoria y posibles ciclos de CPU, según sea el lenguaje.

- Tenemos que poner privado algo que conceptualmente es público.

- Un tipo abstracto de datos se define como una lista de datos y operaciones; sin embargo, el interfaz público de la clase sólo tiene métodos. Es decir, se pierde correspondencia entre el concepto abstracto y su implementación en código, esto suele afectar muy mal a la documentación, sobre todo a la generada automáticamente (el interfaz público de una clase debería coincidir con el TAD)

Algunos lenguajes incorporan el concepto de "properties" para intentar afrontar esto, lo cual mejora quizá la parte de documentación, pero añade aún más líneas de código y artefactos raros.

En cambio, en lenguajes como Eiffel, esto se soluciona de un plumazo haciendo que los atributos públicos sean siempre de sólo lectura. Así podemos escribir sin peligro:

class Punto:

    public x: integer
    public set_x(nuevo_x: integer)
        (verificar nuevo_x...)
        this.x = nuevo_x

    (y lo mismo con y)

Y si queremos añadir algún atajo tipo "properties" para ahorrar líneas de código en el caso de que no hiciera falta validar nada, podíamos inventar una sintaxis tipo

class Punto:
    public x: integer [set]
    public y: integer [set]

La clave es romper la simetría get/set. Que por poner un atributo público no signifique que todo el mundo pueda cambiar su valor, salvo que se indique así expresamente.