Я бы обобщил это с помощью такого метода, как:
public int max(List list, ToIntFunction toInt) {
int max = toInt.applyAsInt(list.get(0));
for(T t : list) {
if(toInt.applyAsInt(t) > max) {
max = toInt.applyAsInt(t);
}
}
return max;
}
И затем каждый раз, когда вам нужно вызвать его (например, с помощью String
), вы можете сделать:
List list = Arrays.asList("Hello", "one", "four", "biggest");
ToIntFunction length = (str) -> str.length();
int biggest = max(list, length);
[ 119] Или передайте его напрямую через ссылку на метод:
int biggest = max(list, String::length);
, который вернет 7
Или Java 8+, который вы можете сделать:
public int max(List list, ToIntFunction toInt) {
return list.stream().mapToInt(toInt).max().orElse(Integer.MIN_VALUE);
}
, который будет удерживать вас от необходимости писать один и тот же цикл снова и снова
Документация для ToIntFunction
Я должен сказать, что я - поклонник "классической" модели. Я нахожу легче сформулировать мои утверждения по большей части, и я нахожу их легче читать также. Нет ничего в коде, который не необходим - нет "Это" и "Является", какие быстрые звуки, но не предоставляет само discoverability IMO.
, Который может произойти из-за знакомства так же как что-либо еще, но я думал, что будет просто стоить заверить Вас, что Вы не единственный, кто находит классическую модель совершенно разумной:)
Однако когда существует что-то, что легче выразить ограничения использования, имеет смысл использовать его. Это особенно верно, когда существует некоторое условие, которое может быть явно протестировано с ограничением, но где классическая модель просто использовала бы Assert.IsTrue(condition)
. Ключевой пункт - то, что ограничение, вероятно, будет в состоянии дать Вам больше информации, чем классическая для таких случаев.
Как таковой я думаю, что это - хорошая идея , учатся модель на основе ограничений, но я не пошел бы до преобразования никаких тестов, и я не буду использовать его, где Вы находите, что классическая модель более проста или более читаема.
Я не знаю, есть ли другие преимущества, кроме читабельности. Но это может быть большим преимуществом. Я обнаружил, что простой запуск каждого теста с Assert.That( ... )
вместо использования нескольких функций Assert облегчает визуальное сканирование утверждений в миллион раз, поскольку вам больше не нужно беспокоиться о названии функции, просто посмотрите на аргументы.
В NUnit 2.4 оба синтаксиса (класс и ограничение) используют точно такой же код внизу. Там нет преимущества за кулисами, так или иначе. Если бы у вас действительно не было лучшего использования времени, я бы не стал переписывать тесты.
Я лично предпочитаю стиль модели ограничений Assert.That
и использую его только сейчас. Я нахожу этот более новый стиль более читабельным и определила, что вероятность того, что «фактические» и «ожидаемые» аргументы перепутаются, гораздо меньше. (Как вы, безусловно, можете использовать Классическую модель Assert.AreEqual
и т. Д., Что я видел, как это делают многие люди.) Это, очевидно, приводит к неудачным тестам, которые сообщают о неверных результатах.
Например, без проверки ;-), что из этого является правильным?
Assert.AreEqual(actual, expected);
Assert.AreEqual(expected, actual);