Аргументы метода Java должны использоваться для возврата нескольких значений?
Я внес изменения в несколько строк в вашем коде, попробуйте это и дайте мне знать
Для аутентификации я использовал упреждающий метод покоя, а для тела - метод param формы
Response response = given().auth().preemptive().basic("username", "password").
contentType("application/json").
header("Accept", "application/json").
param("grant_type", "client_credentials").
when().post("http://localhost:8000/abc/def").
then().extract().response();
9 ответов
Давным-давно я разговаривал с Ken Arnold (один член времени команды Java), это будет в первом Java Одной конференцией, вероятно, таким образом 1996. Он сказал, что они думали о добавлении нескольких возвращаемых значений, таким образом, Вы могли записать что-то как:
x, y = foo();
Рекомендуемый способ сделать его тогда, и теперь, состоит в том, чтобы сделать класс, который имеет несколько элементов данных, и возвратите это вместо этого.
На основе этого и других комментариев, сделанных людьми, которые работали над Java, я скажу, что намерение состоит в том, что Вы возвращаете экземпляр класса, а не изменяете аргументы, которые были переданы в.
Это - обычная практика (как требование программистами C изменить аргументы... в конечном счете они видят Java способ обычно делать его. Просто думайте о нем как о возврате структуры.:-)
(Редактирование на основе следующего комментария)
Я читаю файл и генерирую два массива, Строки типа и интервала от нее, выбирая один элемент для обоих от каждой строки. Я хочу возвратить их обоих любой функции, которая называет его который файл разделить этот путь.
Я думаю, если бы я понимаю Вас правильно, tht я, вероятно, сделал бы soemthing как это:
// could go with the Pair idea from another post, but I personally don't like that way
class Line
{
// would use appropriate names
private final int intVal;
private final String stringVal;
public Line(final int iVal, final String sVal)
{
intVal = iVal;
stringVal = sVal;
}
public int getIntVal()
{
return (intVal);
}
public String getStringVal()
{
return (stringVal);
}
// equals/hashCode/etc... as appropriate
}
и затем имейте свой метод как это:
public void foo(final File file, final List<Line> lines)
{
// add to the List.
}
и затем назовите его как это:
{
final List<Line> lines;
lines = new ArrayList<Line>();
foo(file, lines);
}
По-моему, если мы говорим об открытом методе, необходимо создать отдельный класс, представляющий возвращаемое значение. Когда у Вас есть отдельный класс:
- это служит абстракцией (т.е. a
Pointкласс вместо массива двух longs) - каждое поле имеет имя
- может быть сделан неизменным
- делает эволюцию API намного легче (т.е. что относительно того, чтобы возвратиться 3 вместо 2 значений, изменяя тип некоторого поля и т.д.)
Я всегда выбирал бы возврат нового экземпляра, вместо того, чтобы на самом деле изменить значение передал в. Это кажется намного более ясным мне и способствует неизменности.
С другой стороны, если это - внутренний метод, я предполагаю, что любое следующее могло бы использоваться:
- массив (
new Object[] { "str", longValue }) - список (
Arrays.asList(...)возвращает неизменный список), - класс пары/кортежа, такой как это
- статический внутренний класс, с общедоступными полями
Однако, я предпочел бы последнюю опцию, оборудованную подходящим конструктором. Это особенно верно при нахождении того же кортежа больше чем из одного места.
Мне действительно жаль, что не было a Pair<E,F> класс в JDK, главным образом поэтому. Существует Map<K,V>.Entry, но создание экземпляра всегда было большой болью.
Теперь я использую com.google.common.collect.Maps.immutableEntry когда мне нужен a Pair
Посмотрите этот RFE, запущенный назад в 1999:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4222792
Я не думаю, что намерение состояло в том, чтобы когда-либо позволять его на языке Java, если необходимо возвратить несколько значений, необходимо инкапсулировать их в объекте.
Используя языки как Scala однако можно возвратить кортежи, видеть:
http://www.artima.com/scalazine/articles/steps.html
Можно также использовать Дженерики в Java для возврата пары объектов, но это - об этом AFAIK.
Править: Кортежи
Только добавить еще немного на этом. Я ранее реализовал Пару в проектах из-за отсутствия в JDK. Ссылка на мою реализацию здесь:
http://pbin.oogly.co.uk/listings/viewlistingdetail/5003504425055b47d857490ff73ab9
Отметьте, нет хэш-кода или равняется на этом, которое должно, вероятно, быть добавлено.
Я также столкнулся с этим, пока проведение некоторого исследования в это подвергает сомнению, который обеспечивает функциональность кортежа:
Это позволяет Вам создавать Пару включая другие типы кортежей.
Вы не можете действительно возвратить несколько значений, но можно передать объекты в метод и иметь метод, видоизменяют те значения. Это совершенно законно. Обратите внимание, что Вы не можете передать объект в и иметь сам объект, становятся другим объектом. Это:
private void myFunc(Object a) {
a = new Object();
}
приведет ко временно и локально изменение значения a, но это не изменит значение вызывающей стороны, например, от:
Object test = new Object();
myFunc(test);
После myFunc возвраты, у Вас будет старый Объект а не новый.
Законный (и часто препятствовавшийся) что-то вроде этого:
private void changeDate(final Date date) {
date.setTime(1234567890L);
}
Я выбрал Date по причине. Это - класс, который широко согласовывают люди, никогда не должно было быть изменяемым. Метод выше изменит внутреннее значение любого Date возразите, что Вы передаете ему. Этот вид кода законен, когда очень ясно, что метод видоизменит или настроит или изменит то, что передается в.
Примечание: Обычно сказано, что метод должен сделать эту вещь:
- Возвратитесь пусто и видоизмените его входящие объекты (как
Collections.sort()), или - Возвратите некоторое вычисление и не видоизменяйте входящие объекты вообще (как
Collections.min()), или - Возвратите "представление" входящего объекта, но не изменяйте входящий объект (как
Collections.checkedList()илиCollections.singleton()) - Видоизмените один входящий объект и возвратите его (
Collectionsне имеет примера, ноStringBuilder.append()хороший пример).
Методы, которые видоизменяют входящие объекты и возвращают отдельное возвращаемое значение, часто делают слишком много вещей.
Существуют, конечно, методы, которые изменяют объект, переданный в в качестве параметра (см. java.io. Reader.read (байт [] буфер) как пример, но я не видел параметры, используемые в качестве альтернативы для возвращаемого значения, особенно с несколькими параметрами. Это может технически работать, но это нестандартно.
Это обычно не считают ужасно хорошей практикой, но существуют очень случайные случаи в JDK, где это сделано. Посмотрите на 'biasRet' параметр View.getNextVisualPositionFrom () и связанные методы, например: это - на самом деле одномерный массив, который заполняется "дополнительным возвращаемым значением".
Итак, почему делают это? Ну, только для сохранения Вас имеющий необходимость создать дополнительное определение класса для "случайного дополнительного возвращаемого значения". Это - грязный, неэлегантный, плохой дизайн, необъектно-ориентированный, и тому подобное. И мы все время от времени делали это...
Обычно, что сказал Eddie, но я добавлю еще один:
- Видоизмените один из входящих объектов и возвратите код состояния. Это должно обычно только использоваться для аргументов, которые являются явно буферами, как Reader.read (символ [] cbuf).
У меня был объект Result, который каскадно проходит через серию проверяющих методов void в качестве параметра метода. Каждый из этих проверяющих методов void будет изменять объект параметра результата, чтобы добавить результат проверки.
Но это невозможно проверить, потому что теперь я не могу заглушить метод void, чтобы он возвращал значение-заглушку для проверки в объекте Result.
Итак, с точки зрения тестирования кажется, что следует отдавать предпочтение возврату объекта, а не изменению параметра метода.