Nombrar extensiones de colección para mayor claridad

Question

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.

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

Answer 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); 

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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); 

Answer 6

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