Когда использование ключевого слова C# ref является хорошей идеей?

В Руководстве по проектированию фреймворка (книга Кшиштофа Квалины и Брэда Абрамса) рекомендуется избегать параметров ref и out.

ИЗБЕГАЙТЕ использование параметров out или ref.

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

В Руководстве по проектированию фреймворка канонический метод Swap упоминается как допустимое исключение:

void Swap<T>(ref T obj1, ref T obj2)
{
    T temp = obj1;
    obj1 = obj2;
    obj2 = temp;
}

но в то же время комментарий отмечает

Swap всегда упоминается в этих дискуссиях, но я не писал код, который действительно нуждался бы в методе swap со времен колледжа. Если у вас нет веской причины, вообще избегайте out и ref.

Большинство Interlocked методов используют ref параметров для (I уверена, что вы согласны) веская причина.

Я стараюсь избегать этого в общедоступных API, но у него определенно есть применение. Изменяемые типы значений важны, особенно в таких вещах, как CF (где изменяемые структуры более распространены из-за требований платформы). Однако, возможно, чаще всего я использую его при рефакторинге частей сложного алгоритма в несколько методов, где объект состояния является излишним, и мне нужно передать несколько значений:

i.e.

var x = .....
var y = .....
// some local code...
var z = DoSomethingSpecific(ref x, ref y); // needs and updates x/y
// more local code...

и т. д. Где DoSomethingSpecific - это частный метод, который просто перемещен, чтобы сохранить ответственность за метод управляемой.

Каждый раз, когда вы хотите изменить значение типа value — это часто происходит в случаях, когда вы хотите эффективно обновить пару связанных значений (т. е. вместо того, чтобы возвращать структуру, содержащую два целых числа, вы передаете (ссылка int x, ссылка int y))

Возможно, когда у вас есть структура (которая является типом значения):

struct Foo
{
    int i;

    public void Test()
    {
        i++;
    }
}

static void update(ref Foo foo)
{
    foo.Test();
}

и

Foo b = new Foo();
update(ref b);

Здесь вы должны использовать два параметра с out, например:

static void update(Foo foo, out Foo outFoo) //Yes I know you could return one foo instead of a out but look below
{
    foo.Test();

    outFoo = foo;
}

отображая метод, имеющий более одного Foo, вы получите вдвое больше параметров с out по сравнению с ref. Альтернативой является возврат N-кортежа. У меня нет реального примера того, когда использовать этот материал.

Добавление: Различные методы .TryParse также могли бы избежать out, если бы вместо этого возвращали Nullable<T>, что по сути является кортежем boolean * T.

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

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

Гипотетически я предполагаю, что вы могли бы использовать много аргументов ref/out, если вы намеревались имитировать архитектуру старого процедурного программного обеспечения, например, старых игровых движков и так далее. Я просмотрел исходный код одной из них, думаю, это была Duke Nukem 3D, и она процедурная, с множеством подпрограмм, изменяющих переменные, и почти без функций. Очевидно, что вы вряд ли будете программировать подобное для реального производственного приложения, если у вас нет конкретной цели.

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

Пример:

 getTreeNodeValues(ref selectedValue, ref selectedText);

Редактировать:

Лучше использовать здесь - как прокомментировано.

 getTreeNodeValues(out selectedValue, out selectedText);

Я использую его для обработки объектов:

MyCar car = new MyCar { Name="TestCar"; Wieght=1000; }

UpdateWeight(ref car, 2000);

Еще один полезный пример в дополнение к swap‹>:

Prompter.getString("Name ? ", ref firstName);
Prompter.getString("Lastname ? ", ref lastName);
Prompter.getString("Birthday ? ", ref firstName);
Prompter.getInt("Id ? ", ref id);
Prompter.getChar("Id type: <n = national id, p = passport, d = driver licence, m = medicare> \n? ", ref c);



public static class Prompter
{
    public static void getKey(string msg, ref string key)
    {
        Console.Write(msg);
        ConsoleKeyInfo cki = Console.ReadKey();
        string k = cki.Key.ToString();
        if (k.Length == 1)
            key = k;
    }

    public static void getChar(string msg, ref char key)
    {
        Console.Write(msg);
        key = Console.ReadKey().KeyChar;
        Console.WriteLine();
    }

    public static void getString(string msg, ref string s)
    {
        Console.Write(msg);
        string input = Console.ReadLine();
        if (input.Length != 0)
            s = input;
    }

    public static void getInt(string msg, ref int i)
    {
        int result;
        string s;

        Console.Write(msg);
        s = Console.ReadLine();

        int.TryParse(s, out result);
        if (result != 0)
            i = result;       
    }

    // not implemented yet
    public static string getDate(string msg)
    {
        // I should use DateTime.ParseExact(dateString, format, provider);
        throw new NotImplementedException();
    }    


}

Используйте здесь, это не вариант