Который является лучшим, возвращаемым значением или параметром?

I think one of the few scenarios where it would be useful would be when working with unmanaged memory, and you want to make it obvious that the "returned" value should be disposed of manually, rather than expecting it to be disposed of on its own.

Реальной разницы нет, выходные параметры в C # позволяют методу возвращать более одного значения, вот и все.

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

Использование параметра out заставит вас использовать две строки, такие как:

int n;
GetValue(n);

, а использование возвращаемого значения позволит вам сделать это в одной строке:

int n = GetValue();

Другое отличие (корректно только для типов значений и только если C # не делает встроенная функция) заключается в том, что использование возвращаемого значения обязательно сделает копию значения, когда функция, возвращаемая при использовании параметра OUT, не обязательно сделает это.

I would prefer the following instead of either of those in this simple example.

public int Value
{
    get;
    private set;
}

But, they are all very much the same. Usually, one would only use 'out' if they need to pass multiple values back from the method. If you want to send a value in and out of the method, one would choose 'ref'. My method is best, if you are only returning a value, but if you want to pass a parameter and get a value back one would likely choose your first choice.

Вы почти всегда должны использовать возвращаемое значение. Параметры « out » создают небольшие трения для большого количества API, композиционности и т. Д.

Наиболее примечательное исключение, которое приходит на ум, - это когда вы хотите вернуть несколько значений (.Net Framework не ' не может иметь кортежи до 4.0), например, с шаблоном TryParse .

You should generally prefer a return value over an out param. Out params are a neccissary evil if you find yourself writing code that needs to do 2 things. A good example of this is the Try pattern (such as Int32.TryParse).

Let's consider what the caller of your two methods would have to do. For the first example I can write this...

int foo = GetValue();

Notice that I can declare a variable and assign it via your method in one line. FOr the 2nd example it looks like this...

int foo;
GetValue(out foo);

I'm now forced to declare my variable up front and write my code over two lines.

update

A good place to look when asking these types of question is the .NET Framework Design Guidelines. If you have the book version then you can see the annotations by Anders Hejlsberg and others on this subject (page 184-185) but the online version is here...

http://msdn.microsoft.com/en-us/library/ms182131(VS.80).aspx

If you find yourself needing to return two things from an API then wrapping them up in a struct/class would be better than an out param.

Это предпочтение в основном

Я предпочитаю возвраты, и если у вас есть несколько возвращений, вы можете заключить их в Resto DTO

public class Result{
  public Person Person {get;set;}
  public int Sum {get;set;}
}

Вы можете иметь только одно возвращаемое значение, в то время как вы можете иметь несколько выходных параметров.

В этих случаях вам нужно учитывать только параметры вывода.

Однако, если вам нужно чтобы вернуть более одного параметра из вашего метода, вы, вероятно, захотите посмотреть, что вы возвращаете из ОО-подхода, и подумать, лучше ли вам возвращать объект или структуру с этими параметрами. Поэтому вы снова возвращаетесь к возвращаемому значению.

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

public int ReturnMultiple(int input, out int output1, out int output2)
{
    output1 = input + 1;
    output2 = input + 2;

    return input;
}

Таким образом, одно не по определению лучше другого. Но обычно вы хотите использовать простой возврат, если, например, у вас нет описанной выше ситуации.

РЕДАКТИРОВАТЬ: Одна из причин, по которой существует из , заключается в том, чтобы облегчить возврат нескольких значений из одного вызова метода:

public int ReturnMultiple(int input, out int output1, out int output2)
{
    output1 = input + 1;
    output2 = input + 2;

    return input;
}

Таким образом, одно не по определению лучше другого. Но обычно вы хотите использовать простой возврат, если, например, у вас нет описанной выше ситуации.

РЕДАКТИРОВАТЬ: Одна из причин, по которой существует из , заключается в том, чтобы облегчить возврат нескольких значений из одного вызова метода:

public int ReturnMultiple(int input, out int output1, out int output2)
{
    output1 = input + 1;
    output2 = input + 2;

    return input;
}

Таким образом, одно не по определению лучше другого. Но обычно вы хотите использовать простой возврат, если, например, у вас нет описанной выше ситуации.

РЕДАКТИРОВАТЬ: Это пример, демонстрирующий одну из причин существования ключевого слова. Вышеизложенное ни в коем случае нельзя считать наилучшей практикой.

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

Если вы используете return, то данные сначала записываются в стек методов, а затем в вызывающий метод. Хотя в случае out он напрямую записывается в стек вызывающих методов. Не уверен, есть ли еще различия.

As others have said: return value, not out param.

May I recommend to you the book "Framework Design Guidelines" (2nd ed)? Pages 184-185 cover the reasons for avoiding out params. The whole book will steer you in the right direction on all sorts of .NET coding issues.

Allied with Framework Design Guidelines is the use of the static analysis tool, FxCop. You'll find this on Microsoft's sites as a free download. Run this on your compiled code and see what it says. If it complains about hundreds and hundreds of things... don't panic! Look calmly and carefully at what it says about each and every case. Don't rush to fix things ASAP. Learn from what it is telling you. You will be put on the road to mastery.