Что случилось с выходными параметрами?

Выходными параметрами может быть запах кода, указывающий на то, что ваш метод слишком много работает . Если вам нужно вернуть более одного значения, метод, вероятно, выполняет несколько функций. Если данные тесно связаны, то, вероятно, будет полезен класс, содержащий оба значения.

Конечно, это не ВСЕГДА, но я обнаружил, что это обычно так.

Другими словами , Я думаю, вы правы, избегая их.

They have their place. Int32.TryParse method is a good example of an effective use of an out parameter.

bool result = Int32.TryParse(value, out number);
if (result)
{
    Console.WriteLine("Converted '{0}' to {1}.", value, number);         
}

I think they're useful for getting IDs of newly-inserted rows in the same SQL command, but i don't think i've used them for much else.

I too see very little use of out/ref parameters, although in SQL it sometimes is easier to pass a value back by a parameter than by a resultset (which would then require the use of a DataReader, etc.)

Though, as luck would have it, I just created one such rare function in C# today. It validated a table-like data structure and returned the number of rows and columns in it (which was tricky to calculate because the table could have rowspans/colspans like in HTML). In this case the calculation of both values was done at the same time. Separating it into two functions would have resulted in double the code, memory and CPU time requirements. Creating a custom type just for this one function to return also seems like an overkill to me.

So - there are times when they are the best thing, but mostly you can do just fine without them.

The OUTPUT clause in SQL Server 2005 onwards is a great step forward for getting any field values for rows affected by your DML statements. Ithink that there are a lot of situations where this does away with output parameters.

In VB6, ByRef parameters are good for passing ADO objects around.

other than those two specific cases that come to mind, I tend to avoid using them.

In SQL only...

Stored procedure output parameters are useful.

1. Say you need one value back. Do you "create #table, insert... exec, select @var = ". Or use an output parameter?

2. For client calls, an output parameter is far quicker than processing a recordset.

3. Using RETURN values is limited to signed integer.

4. Easier to re-use (eg a security check helper procedure)

5. When using both: recordsets = data, output parameters = status/messages/rowcount etc

6. Stored procedures recordset output can not be strongly typed like UDFs or client code

7. You can't always use a UDF (eg logging during security check above)

However, as long as you don't generally use the same parameter for input and output, then until SQL changes completely your options are limited. Saying that, I have one case where I use a paramter for in and out values, but I have a good reason.

Мои два цента:
Я согласен, что выходные параметры - это практика. VBA часто поддерживают люди, очень новички в программировании, и если кто-то, обслуживающий ваш код, не заметит, что параметром является ByRef, они могут внести серьезные логические ошибки. Также это имеет тенденцию нарушать парадигму Свойство / Функция / Подложка.
Другая причина, по которой использование параметров out является плохой практикой, заключается в том, что если вам действительно действительно нужно возвращать более одного значения, скорее всего, эти значения должны быть у вас в структуре данных, такой как класс или определяемый пользователем Тип.
Однако они могут решить некоторые проблемы. VB5 (и, следовательно, VBA для Office 97) не позволял функции возвращать массив. Это означало, что все, что возвращает или изменяет массив, должно происходить через параметр «out». В VB6 эта возможность была добавлена, но VB6 по-прежнему заставляет параметры массива быть по ссылке (для предотвращения чрезмерного копирования в памяти). Теперь вы можете вернуть значение из функции, изменяющей массив. Но это будет просто на волосок медленно (из-за акробатики, происходящей за кадром); это также может сбить с толку новичков, заставив их думать, что ввод массива не будет изменен (что будет верно только в том случае, если кто-то специально структурировал его таким образом). Итак, я обнаружил, что если у меня есть функция, которая изменяет массив, это уменьшает путаницу, просто используя подпрограмму вместо функции (и это тоже будет немного быстрее).
Другой возможный сценарий: если вы поддерживаете код и хотите добавить выходное значение без нарушения интерфейса, вы можете добавить дополнительный выходной параметр и быть уверенным, что не нарушите какой-либо старый код. Это не очень хорошая практика, но если кто-то хочет что-то исправить прямо сейчас , а у вас нет времени, чтобы сделать это «правильным способом» и все реструктурировать, это может быть удобным дополнением к вашему ящику для инструментов.
Однако, если вы разрабатываете что-то с нуля и вам нужно вернуть несколько значений, вам следует подумать:
1. Прерывание функции.
2. Возврат UDT.
3. Возврат класса

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

Ваше мнение мне кажется разумным.

Еще один недостаток выходных параметров - это дополнительный код, необходимый для передачи результатов от одной функции к другой. Вы должны объявить переменную (ы), вызвать функцию для получения их значений, а затем передать значения другой функции. Вы не можете просто вкладывать вызовы функций. Это заставляет код читать очень императивно, а не декларативно.

C++0x is getting tuples, an anonymous struct-like thing, whose members you access by index. C++ programmers will be able to pack multiple values into one of those and return it. Does C# have something like that? Can it return an array, perhaps, instead? But yeah output parameters are a bit awkward and unclear.