2009-05-27 3 views
5

Presentando algunos de los beneficios de las operaciones de recopilación en nuestra base de código sin agregar una nueva dependencia de biblioteca externa, estamos agregando estos métodos a nuestro paquete de utilidades.Nombrar extensiones de colección para mayor claridad

static public List<T> filter(List<T> source, Predicate<T> filter); 
static <Y,T> public List<Y> transform(List<T> source, Mutator<Y,T> filter); 
static public boolean exists(List<T> source, Predicate<T> filter); 
static public T findFirst(List<T> source, Predicate<T> filter); 
static public boolean trueForAll(List<T> source, Predicate<T> filter); 

Con las interfaces concomitantes

public interface Predicate<T> { public boolean apply(T item); } 
public interface Mutator<T,Y> { public Y apply(T item); } 

Así que las preguntas:

  • son los filtros de un buen nombre para la clase que contiene las extensiones? Si no, ¿mejor?
  • ¿El mutador < T, Y> recibe el nombre apropiado?
  • ¿Debo prefieren mapa a transformada y reducir a filtro?
  • ¿Hay alguna función importante basada en conjuntos que he olvidado incluir en la clase de la biblioteca?

Editado para agregar: Un argumento importante que tengo contra mapa (y por lo tanto a favor de transformar) es que mapa tiene carga semántica significativa debido a los muchos usos para java.util.Map

Respuesta

1

Yo los llamaría mapa y filtro. Reducir tiene un significado ligeramente diferente para mí, y la transformación es demasiado vaga. En cuanto al nombre de la clase, los Filtros pueden no ser los mejores, pero no tengo una mejor recomendación.

Sé que no estaba pidiendo esto específicamente, pero algunas de las firmas en los métodos genéricos se pueden mejorar:

static public <T> List<T> filter(List<T> source, Predicate<? super T> filter); 
static public <Y,T> List<Y> transform(List<T> source, Mutator<Y,? super T> filter); 
static public <T> boolean exists(List<T> source, Predicate<? super T> filter); 
static public <T> T findFirst(List<T> source, Predicate<? super T> filter); 
static public <T> boolean trueForAll(List<T> source, Predicate<? super T> filter); 
+0

Gracias, ya que estoy acostumbrado a pensar en los genéricos CLR en lugar de los genéricos JDK5, definitivamente es un buen punto. –

0

Esto no es realmente lo que preguntas, pero está en el espíritu de tu pregunta. Para mí, se lee mejor decir:

List<String> shortWords = filtered(allWords, short); 

que

List<String> shortWords = filter(allWords, short); 

me gustaría seguir con transformada y filtro.

+1

yo tendería a estar en desacuerdo; Creo que el verbo funciona un poco más claro que el adjetivo (porque describe con más precisión el hecho de que se está produciendo alguna acción). Sin embargo, es un desacuerdo menor. –

+0

Tiendo a pensar en métodos como acciones. el filtro parece más apropiado que filtrado. Lo importante es ser consistente sin embargo. – ebrown

+0

Puedo entender su razonamiento, McWafflestix & ebrown, pero me gusta nombrar una función de devolución de valor para que describa lo que se devuelve. Lo que se devuelve es la lista filtrada, no es el filtro. –

1

Esto se ve muy bien; Creo que definitivamente estás en el camino correcto aquí. Sí, creo que Mutator es un buen nombre; la transformación es mejor porque se lee más comúnmente como un verbo, y el mapa tiene una connotación "sustantiva" que puede ser confusa; y la única función importante basada en conjuntos que podría pensar que podría desear sería una función de reordenamiento.

+0

ya que Collections.sort está disponible, no pensé que necesitáramos un método de clasificación adicional. –

1

en una biblioteca similares utilicé:

  • Especificación en lugar de predicado: aSpecification.isSatisfiedBy(anObject);
  • Mapper en lugar de Mutator
  • mapa es recogen fo r Smalltalkers (transformar en su caso)
  • veces es inyectar para Smalltalkers
  • filtro se seleccione para Smalltalkers
+0

veces? ¿Cuál es la operación subyacente allí? –

+0

http://c2.com/cgi/wiki?FoldFunction – dfa

0

Parecería transformada debe ser mutado (o alternativamente mutador debe ser transformador,) por la coherencia. Esto parece bastante clara acerca de la intención:

static <Y,T> public List<Y> mutate (List<T> originalForm, Mutator<Y,T> mutator); 

También es un poco más de detalle (pero más consistente y convencional) a SPEC:

static public boolean isTrueForAll(List<T> source, Predicate<T> filter); 

o

static public boolean assertTrueForAll(List<T> source, Predicate<T> filter); 
+0

buen punto acerca de isTrueForAll vs. trueForAll ... (pero tengo que admitir que viene de esto de "lo que falta en las colecciones JDK1.5 que está presente en la perspectiva .Net BCL", por lo que mi expectativa de denominación tenía un prejuicio preexistente. .. –

2

Son hay alguna función importante de basada en conjuntos que he olvidado incluir en en la clase de la biblioteca?

Para las funciones de cobro de orden superior, utilizo el enfoque descrito por Adrian Kuhn en su artículo "Pimp My Foreach".

Algunos de éstos ya tienes, pero pensé en tirar de ellos hacia fuera allí de todos modos:

  • AllSatisfy
  • AnySatisfy
  • cardinalidad
  • Recoger
  • Conde
  • CutPieces
  • Detectar
  • Fold
  • GroupedBy
  • IndexOf
  • Inyectar
  • Rechazar
  • Seleccionar
Cuestiones relacionadas