Mejor tipo de seguridad en colecciones Java

Question

En mi codificación java, a menudo termino con varios Map<String,Map<String,foo>> o Map<String,List<String>> y luego me cuesta recordar qué cadena es qué tecla. Comenta la declaración con //Map<capabiltyId,Map<groupId,foo>> o //Map<groupId,List<capabilityId>, pero no es la mejor solución. Si String no fuera final, haría nuevas clases CapabilityId extends String y GroupId extends String, pero no puedo. ¿Hay una mejor manera de hacer un seguimiento de qué cosa es la clave y tal vez hacer que el compilador lo haga cumplir?

Answer 1

En lugar de tener CapabilityId se extienden String, CapabilityId podría incluir un campo de String llamado "id"; entonces su Map podría definirse como Map<CapabilityId, Map<GroupId, Foo>>, y podría obtener los campos de ID individuales a través de getId() en sus clases de clave.

No estoy seguro de que haría esto yo mismo, pero si lo hiciera, esto es probablemente lo que haría.

podría limitar el desorden por tener una clase abstract GenericId con un campo id y getId() método, y tienen CapabilityId y GroupId hereda de ella.

Answer 2

cadenas Envuelva envoltura clases si quieren:

class GroupId implements Comparable { 
    private String groupId; 

    public GroupId (String groupId) { 
     this.groupId = groupId; 
    } 
    ... 
} 

Map<GroupId, List<CapabilityId>> m = ... 

Answer 3

crear una clase ID que puede subclase, y que consiste en un campo String y las implementaciones de equals() y hashCode() que utilizan ese campo.

Answer 4

En lugar de Map<String,List<String>> se debe utilizar Multimapa de Google Guava/Google Colección

http://google-collections.googlecode.com/svn/trunk/javadoc/index.html?com/google/common/collect/Multimap.html

Answer 5

Agregando a las otras respuestas:

envolverlo.

No es solo una solución a su problema sino una buena idea en general, es decir, evitar los parámetros simples de . Su código obtendrá legibilidad, cordura y facilidad de mantenimiento. Puede agregarle todo tipo de propiedades agradables, p. Ej. declararlo @Imutable. Como lo descubrió de esta manera, es mejor recordar y controlar. Eres propietario de la clase y puedes hacer lo que quieras con ella.

Answer 6

Lo pondría todo en una sola clase y haría uso de los nombres de campo/método/argumento.

public class GroupCapabilities { 
    private Map<String, Map<String, Group>> groupCapabilities; 

    public void addGroup(String capabilityId, Group group) { 
     Map<String, Group> groups = groupCapabilities.get(capabilityId); 
     if (groups = null) { 
      groups = new HashMap<String, Group>(); 
      groupCapabilities.put(capabilityId, group); 
     } 
     groups.put(group.getId(), group); 
    } 

    public Map<String, Group> getGroups(String capabilityId) { 
     return groupCapabilities.get(capabilityId); 
    } 

    public Group getGroup(String capabilityId, String groupId) { 
     Map<String, Group> groups = groupCapabilities.get(capabilityId); 
     return (groups != null) ? groups.get(groupId) : null; 
    } 

    // Etc.. 
} 

De esta manera, puede ver en los nombres método/argumento lo que espera/devuelve.

Answer 7

Hay un número de maneras de ir sobre este (algunos ya mencionado):

• Como @Roman, envuelva el tipo de propósito general en un tipo más específico, lo que da a escribir más fuerte. Fuerte tipeo bueno, IMO.
• Como @nanda, use un tipo de colección más específico. La biblioteca de Java es un poco pobre en esta área. Depende de cómo te sientas con respecto a las dependencias.
• Como @BalusC, mueve todo lo repulsivo a una clase asquerosa. Realmente no elimina el problema, pero sí lo contiene (como en Cazafantasmas).
• Map<String,Map<String,foo>> se parece mucho a que tiene una clave compuesta, es decir, una clave que consta de dos partes. Por lo tanto, introduzca una clase de clave compuesta inmutable, es decir, un objeto de valor que represente los objetos de valor de dos componentes.