Naming Collection Extensions для ясности

Question

Представляя некоторые преимущества операций сбора в нашу кодовую базу без добавления новой зависимости от внешней библиотеки, мы добавляем эти методы в наш пакет утилит.

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

С сопутствующими интерфейсами

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

Итак, вопросы:

• Является ли Filters хорошим названием для класса, содержащего расширения? Если нет, то лучше?
• Правильно ли назван Mutator ?
• Должен ли я предпочесть map to transform и уменьшить до filter ?
• Существуют ли какие-либо важные основанные на множестве функции, которые я забыл включить в класс библиотеки?

Отредактировано для добавления : существенный аргумент, который я имею против map (и, следовательно, в пользу transform ), заключается в том, что map имеет значительная семантическая нагрузка из-за множества использований java.util.Map

Answer 1

Существуют ли какие-либо важные наборы на основе функции, которые я забыл включить в библиотеку класс?

Для функций сбора данных более высокого порядка я использую подход, изложенный Адрианом Куном в его статье " Pimp My Foreach ".

Некоторые из них у вас уже есть, но я все равно решил выбросить их:

• AllSatisfy
• AnySatisfy
• Cardinality
• Сбор
• Count
• CutPieces
• Обнаружение
• Сложите
• GroupedBy
• IndexOf
• Вводят
• Отклонить
• Выберите

Answer 2

Я бы назвал их карта и фильтр . «Уменьшение» имеет для меня немного другое значение, а трансформация слишком расплывчата. Что касается названия класса, Фильтры могут быть не лучшими, но у меня нет лучшей рекомендации.

Я знаю, что вы не просили об этом конкретно, но некоторые сигнатуры в общих методах могут быть улучшены:

 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 3

в похожей библиотеке я использовал:

• Спецификация вместо Предикат : aSpecification.isSatisfiedBy(anObject);
• Mapper вместо Mutator
• карта - это собирать для маленьких говорящих ( преобразование в вашем случае)
• сгиб это впрыск для маленьких говорящих
• фильтр is выберите для небольших пользователей

Answer 4

Это выглядит действительно красиво; Я думаю, что вы определенно на правильном пути здесь. Да, я думаю, что Мутатор - хорошее имя; transform лучше, потому что он чаще читается как глагол, а map имеет значение «существительное», которое может сбивать с толку; и единственная основная основанная на множестве функция, которая, я думаю, вам может понадобиться, - это функция переупорядочения.

Answer 5

Может показаться, что Transform должен быть Mutate (или, альтернативно, Mutator должен быть Transformer) для согласованности. Это кажется довольно ясным о намерении:

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

Это также немного более многословно (но более последовательно и условно) для спецификации:

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

или

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

Answer 6

Это не совсем то, что вы спросили, но это в духе вашего вопроса. Для меня это звучит лучше сказать:

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

чем

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

Я бы придерживался transform и filter .