ENCAPSULAMIENTO DE INFORMACIÓN SEGÚN FOWLER
IEEE Software: Data Access Routines
Este artículo discute las diferentes posibilidades de "esconder" información cuando implementamos un sistema de información.
Inicialmente recomienda la utilización de atributos públicos en el acceso a valores simples, aunque más por comodidad que por otra cosa. Yo, la verdad, no estoy del todo de acuerdo; aunque evidentemente es un "rollo" tener que estar codificando -aunque los IDEs ayudan- métodos "getter" y "setter", creo que es una buena práctica, y simple.
En el acceso a colecciones de valores, sí tiene mucha razón al explicar que, por ejemplo,
class Album {
private List tracks =new ArrayList();
public List getTracks() {
return tracks;
}
}
, no es una buena manera de encapsular datos, pues el usuario podría añadir y eliminar elementos de la lista sin conocimiento de la estructura.
Fowler establece tres maneras de leer valores, manteniendo la encapsulación:
1. Copiado
Devolver no la referencia, sino una copia.
2. Proxy de protección
Devolver un proxy que impide modificaciones sobre la estructura:
class Album {
private List tracks = new ArrayList();
public List getTracks() {
return Collections.unmodifiableList(tracks);
}
}
(en C++, se consigue con la palabra clave const).
3. Iterador
Un iterador que permite avanzar por la colección, sin tener realmente acceso a ella -aunque sí a los elementos-.
Construcción de Objetos
¿Constructores repletos de argumentos para disponer de objetos bien formados desde el principio, o constructor vacío o casi vacío, más métodos "setter"? Fowler no es definitivo en este apartado, aunque en general prefiere la primera opción. Yo me quedo con la utilización de constructores pequeños con aquellos argumentos que representan atributos inmutables, y la utilización de métodos setter para el resto. Cada cuál...
Este artículo discute las diferentes posibilidades de "esconder" información cuando implementamos un sistema de información.
Inicialmente recomienda la utilización de atributos públicos en el acceso a valores simples, aunque más por comodidad que por otra cosa. Yo, la verdad, no estoy del todo de acuerdo; aunque evidentemente es un "rollo" tener que estar codificando -aunque los IDEs ayudan- métodos "getter" y "setter", creo que es una buena práctica, y simple.
En el acceso a colecciones de valores, sí tiene mucha razón al explicar que, por ejemplo,
class Album {
private List tracks =new ArrayList();
public List getTracks() {
return tracks;
}
}
, no es una buena manera de encapsular datos, pues el usuario podría añadir y eliminar elementos de la lista sin conocimiento de la estructura.
Fowler establece tres maneras de leer valores, manteniendo la encapsulación:
1. Copiado
Devolver no la referencia, sino una copia.
2. Proxy de protección
Devolver un proxy que impide modificaciones sobre la estructura:
class Album {
private List tracks = new ArrayList();
public List getTracks() {
return Collections.unmodifiableList(tracks);
}
}
(en C++, se consigue con la palabra clave const).
3. Iterador
Un iterador que permite avanzar por la colección, sin tener realmente acceso a ella -aunque sí a los elementos-.
Construcción de Objetos
¿Constructores repletos de argumentos para disponer de objetos bien formados desde el principio, o constructor vacío o casi vacío, más métodos "setter"? Fowler no es definitivo en este apartado, aunque en general prefiere la primera opción. Yo me quedo con la utilización de constructores pequeños con aquellos argumentos que representan atributos inmutables, y la utilización de métodos setter para el resto. Cada cuál...
Comments