Naming Collection Extensions zur besseren Übersicht

Question

Wir stellen einige der guten Sammelvorgänge für unsere Codebase vor, ohne eine neue externe Bibliotheksabhängigkeit hinzuzufügen. Wir fügen diese Methoden unserem Dienstprogrammpaket hinzu.

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

mit den damit verbundenen Schnittstellen

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

So sind die Fragen:

• Ist Filter einen guten Namen für die Klasse, um die Erweiterungen enthalten? Wenn nicht, ein besser?
• Ist Mutator < T, Y> richtig benannt?
• Soll ich lieber Karte-verwandeln und -Filter reduzieren?
• Gibt es irgendwelche wichtigen set-based Funktionen, die ich vergessen habe, in die Bibliotheksklasse aufzunehmen?

Edited hinzuzufügen: Ein wesentliches Argument Ich habe gegen Karte (und damit für verwandeln) ist, dass Karte aufgrund der vielen Anwendungen für java.util.Map signifikante semantische Last hat

Answer 1

Ich würde sie Karte und Filter nennen. Reduce hat eine etwas andere Bedeutung für mich und Transformation ist zu vage. Wie für den Klassennamen, Filter möglicherweise nicht die beste, aber ich habe keine bessere Empfehlung.

Ich weiß, dass Sie nicht für diese speziell gefragt wurden, aber einige der Unterschriften in den generischen Methoden verbessert werden kann:

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

Das ist nicht wirklich das, was Sie gefragt haben, aber es ist im Geiste Ihrer Frage. Für mich liest es besser zu sagen:

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

als

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

Ich würde Stick mit und Filter verwandeln.

Answer 3

Das sieht wirklich gut aus; Ich denke du bist hier definitiv auf dem richtigen Weg. Ja, ich finde Mutator ist ein guter Name. transform ist besser, weil es häufiger als Verb gelesen wird, und map hat eine "Substantiv" -Konnotation, die verwirrend sein könnte; und die einzige hauptsächliche mengenbasierte Funktion, von der ich denken könnte, dass sie sie brauchen könnte, wäre eine Neuordnungsfunktion.

Answer 4

in einer ähnlichen Bibliothek, die ich verwenden:

• Spezifikation anstelle von Prädikat: aSpecification.isSatisfiedBy(anObject);
• Mapper anstelle von Mutator
• Karte ist sammeln fo r Smalltalker (verwandeln in Ihrem Fall)
• fach ist für Smalltalker injizieren
• Filter ist wählen für Smalltalker

Answer 5

Es sollte Mutate sein Trans scheint (oder alternativ sollte Mutator Transformator sein,) der Konsistenz halber. Das scheint ziemlich klar über die Absicht:

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

Es ist auch ein bisschen ausführliche (aber konsequente und konventionell) spec:

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

oder

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

Answer 6

Sind Gibt es irgendwelche wichtigen Set-basierte Funktionen, die ich in vergessen habe in der Bibliotheksklasse enthalten?

Für übergeordnete Sammlungsfunktionen verwende ich den von Adrian Kuhn in seinem Artikel "Pimp My Foreach" beschriebenen Ansatz.

Einige davon haben Sie schon bekommen, aber dachte, ich würde sie es trotzdem werfen:

• AllSatisfy
• AnySatisfy
• Cardinality
• sammeln
• Graf
• CutPieces
• Detect
• Falten
• GroupedBy
• IndexOf
• Inject
• Ablehnen
• Select